开发机运行正常到了客户电脑双击没反应或者打开软件没事一点“导出”窗口就消失。这时候“重装一下试试”很容易变成一轮轮碰运气。更有用的第一步是让下一次失败留下证据哪个版本、哪个线程、什么异常、从哪里抛出来。这篇以Windows .NET 8 WinForms为例整理一套不依赖第三方日志库的最小做法。它处理普通托管异常不连接 PLC、运动控制卡或相机设备控制软件的异常处置需要另外设计安全状态和通信超时策略。1. 先分清“打不开”和“运行中闪退”两种现象不要混在一起查。现象第一轮检查为什么双击后主窗口都没出现发布目录、运行时、进程位数、启动日志程序可能还没执行到窗体代码点击某个按钮后退出按钮事件的异常、输入文件、日志堆栈可以围绕确定操作缩小范围运行一段时间后退出后台任务、SDK 调用、资源使用变化、系统事件需要把退出时间与任务记录对齐进程还在窗口不响应死锁、UI 线程阻塞、同步等待这属于卡死不能只靠异常日志定位最先问现场人员四件事什么时候发生、最后点了什么、是否每次必现、用的是哪个发布版本。不要只收一张“程序不见了”的截图。2. 不要只在 Main 外面包一个 try/catchWinForms 窗体事件、普通线程和 Task 的异常传播方式不同。Application.ThreadException用于 WinForms 消息循环中交给它处理的 UI 线程异常。设置处理模式要在创建第一个窗口之前完成。AppDomain.CurrentDomain.UnhandledException收到未处理异常通知时程序可能即将终止。它适合尽力记录信息不能当作“阻止退出”的开关。自己启动的异步操作让调用方await并在相应业务边界处理错误。丢掉 Task 后再期待一个全局事件及时补救并不可靠。微软对 WinForms 异常模式 和 UnhandledException 有明确说明。全局记录只是最后一道诊断措施业务代码仍要处理可预期的失败。下面是入口接线示例。放在原Main中DemoForm替换成自己的主窗体类名ErrorLog在下一节给出。Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);Application.ThreadException(_,e){string?logErrorLog.Write(UI,e.Exception);MessageBox.Show($发生未处理异常。日志{log??写入失败},诊断演示);Application.Exit();// 仅适用于这里没有连接设备的演示程序。};AppDomain.CurrentDomain.UnhandledException(_,e){Exceptionexe.ExceptionObjectasException??newException(非 Exception 类型的未处理错误);ErrorLog.Write($Unhandled; terminating{e.IsTerminating},ex);};try{ApplicationConfiguration.Initialize();Application.Run(newDemoForm());}catch(Exceptionex){ErrorLog.Write(StartupOrRun,ex);Environment.ExitCode1;}保留入口的[STAThread]。这段使用现代 .NET WinForms 的ApplicationConfiguration.Initialize()不能原样贴进 .NET Framework 项目。演示里的退出动作也不能原样搬到正在控制设备的程序。关闭窗口不等于设备已经停止。是否禁止新任务、如何处理正在执行的动作、怎样进入设备安全状态应由业务状态机和设备协议负责全局异常回调不应临时拼凑控制动作。3. 日志至少要保留完整异常和运行环境只记录ex.Message经常只能得到“调用失败”之类的信息。这里记录ex.ToString()保留异常类型、消息、内部异常和可用的堆栈再补上时间、版本、运行时、进程位数及线程号。行号依赖符号文件是否可用不能保证每台现场机器都能显示。日志不要默认写到 exe 旁边。程序可能装在Program Files普通用户没有写权限。示例优先使用当前用户的LocalApplicationData失败后再尝试临时目录并把实际路径返回给调用方。新增ErrorLog.cs把命名空间改成自己的项目名称usingSystem.Reflection;usingSystem.Runtime.InteropServices;usingSystem.Text;namespaceCrashLogDemo;internalstaticclassErrorLog{privatestaticreadonlyobjectGatenew();internalstaticstringRootPath.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),CrashLogDemo,Logs);internalstaticstringFallbackRootPath.Combine(Path.GetTempPath(),CrashLogDemo,Logs);publicstaticstring?Write(stringsource,Exceptionex){// 退出前同步尝试写入不再依赖另一个后台任务。try{stringversionAssembly.GetEntryAssembly()?.GetName().Version?.ToString()??unknown;stringtext${DateTimeOffset.Now:O}source{source}\n$version{version}runtime{RuntimeInformation.FrameworkDescription}\n$arch{RuntimeInformation.ProcessArchitecture}$pid{Environment.ProcessId}tid{Environment.CurrentManagedThreadId}\nex.ToString()\n---\n;lock(Gate){foreach(stringrootinnew[]{Root,FallbackRoot}){try{Directory.CreateDirectory(root);stringpathPath.Combine(root,$error-{DateTime.Now:yyyyMMdd}-{Environment.ProcessId}.log);File.AppendAllText(path,text,newUTF8Encoding(false));returnpath;}catch(ExceptionioError)when(ioErrorisIOExceptionorUnauthorizedAccessException){// 尝试另一个目录不递归调用日志器。}}}}catch{// 记录器自身失败时不覆盖原始异常。}returnnull;}}这里的lock只负责同一进程内的写入串行化。文件名带进程 ID让同时运行的进程各写各的文件。日志器最外层的空catch只用于错误记录失败时的兜底业务代码不能照这个方式吞掉异常后继续报成功。调用方拿到null时应明确提示记录失败。它仍然是一个最小示例未做容量轮转和保留期清理两处路径都不可写时不会留下文件进程状态损坏、断电或被强制结束也不保证写入成功。长期运行项目应补上容量限制并评估成熟日志组件和进程转储方案。4. Task 失败要由启动它的业务负责例如导出操作不要写成try{_Task.Run(()thrownewIOException(模拟导出失败));}catch(Exceptionex){ErrorLog.Write(Export,ex);}这里的try没有等待 Task不能据此认为任务体的异常已经被处理。在 WinForms 按钮事件中可以这样组织privateasyncvoidexportButton_Click(object?sender,EventArgse){exportButton.Enabledfalse;try{// 故意制造一个托管异常验证异常处理链路。awaitTask.Run(()thrownewIOException(模拟导出失败));}catch(Exceptionex){string?logErrorLog.Write(Export,ex);MessageBox.Show($导出失败。日志{log??写入失败});}finally{exportButton.Enabledtrue;}}事件处理器可以使用async void普通业务方法优先返回Task。已有真正异步的 I/O API 时直接await它不需要额外包一层Task.Run。相关传播规则见微软的 异步异常处理说明。TaskScheduler.UnobservedTaskException不是实时报警通道未观察异常的任务满足垃圾回收条件后才可能触发这条路径。不要依靠它判断一次导出是否成功更不要为了触发事件在业务里强制 GC。5. 主窗口都没出现先核对发布目录如果 CLR 尚未成功启动前面的 C# 日志代码根本没有执行机会。先核对交付的是dotnet publish的完整输出再检查目标环境。微软的 dotnet publish 文档 说明了发布输出与依赖项。以项目名CrashLogDemo.csproj、Windows x64 为例# 框架依赖发布目标机器需要兼容的 .NET Windows Desktop Runtimedotnet publish.\CrashLogDemo.csproj-c Release-r win-x64--self-contained false-o.\publish-fdd# 自包含发布携带所需 .NET 运行时dotnet publish.\CrashLogDemo.csproj-c Release-r win-x64--self-contained true-o.\publish-scd默认文件夹发布时把输出目录作为一个整体交付。不要只抽出一个 exe也不要把旧版本目录里的 DLL 混进新版本目录。单文件发布属于另外一种配置不能用它的交付规则推断普通文件夹发布。自包含解决的是 .NET 运行时部署问题。相机或运动控制厂商的原生 DLL、驱动及它们需要的组件仍要按厂商说明准备。排查时尤其注意DllNotFoundException检查原生库及它的依赖不要只看被调用的那个 DLL 是否存在。BadImageFormatException进程与库的位数不匹配是一个检查方向也可能有其他原因不能看到名字就直接断定是 x86/x64 问题。FileNotFoundException、FileLoadException保留完整异常看清楚缺失或加载失败的具体文件。启动失败且没有应用日志按退出时间查看 Windows 事件查看器中的“Windows 日志 → 应用程序”寻找关联的错误记录不能保证每次退出都会出现相同事件。排查阶段先减少变量。不要同时改运行时、SDK、混淆设置和发布方式否则即使恢复运行也很难知道是哪一项修好了。6. 给现场一个能照着收集的信息清单与其让对方反复重启不如发一个固定格式问题发生时间带时区 软件版本 / 发布包名称 最后一次操作 是否每次必现 复现步骤 窗口退出后进程是否还在 最近是否更换电脑、系统或 SDK 应用日志实际路径 对应时间的系统错误记录如果存在日志收集应以定位问题所需的最少信息为准。异常文本可能带有文件路径、连接信息或业务数据交给他人前应检查并脱敏不要把客户订单、配方、密码和完整生产文件直接塞进错误日志。7. 示例验证了什么没验证什么配套最小工程以net8.0-windows为目标在 Windows 环境使用 .NET SDK 10.0.400 编译、.NET 8 运行时执行。Release 构建结果为0 警告、0 错误以下 7 项自动检查通过普通日志可写入。内部异常及测试环境中可用的行号被保留。运行时、进程 ID 和架构字段存在。32 次并发写入的测试记录完整。主日志路径不可写时尝试备用目录。两处路径都不可写时返回null记录器不再向外抛异常。Task 的异常可由调用方观察并记录。这些检查证明了示例的部分诊断能力没有验证真实设备 SDK、原生崩溃、UI 全局回调运行效果或现场安全停机。接入项目后还需要在不连接设备的测试模式下分别验证按钮异常、启动失败和任务失败再安排设备相关验收。一个有用的验收标准是另一位开发者只拿到发布版本、复现步骤和脱敏日志能不能找到失败的代码路径。能做到这一步后续排查就有了起点。你遇到的“闪退”更多是双击打不开、点按钮退出还是运行一段时间后退出可以在评论里说明现象和脱敏后的异常类型后续内容会继续覆盖 WinForms 卡顿、串口掉线和现场发布。相关内容.NET 8 读取硬件信息与 System.Management 引用问题、C# 上位机离线授权方案。