开发机运行正常，到了客户电脑，双击没反应；或者打开软件没事，一点“导出”窗口就消失。
这时候，“重装一下试试”很容易变成一轮轮碰运气。更有用的第一步，是让下一次失败留下证据：哪个版本、哪个线程、什么异常、从哪里抛出来。
这篇以Windows + .NET 8 WinForms为例，整理一套不依赖第三方日志库的最小做法。它处理普通托管异常，不连接 PLC、运动控制卡或相机；设备控制软件的异常处置，需要另外设计安全状态和通信超时策略。
1. 先分清“打不开”和“运行中闪退”
两种现象不要混在一起查。
| 现象 | 第一轮检查 | 为什么 |
|---|---|---|
| 双击后主窗口都没出现 | 发布目录、运行时、进程位数、启动日志 | 程序可能还没执行到窗体代码 |
| 点击某个按钮后退出 | 按钮事件的异常、输入文件、日志堆栈 | 可以围绕确定操作缩小范围 |
| 运行一段时间后退出 | 后台任务、SDK 调用、资源使用变化、系统事件 | 需要把退出时间与任务记录对齐 |
| 进程还在，窗口不响应 | 死锁、UI 线程阻塞、同步等待 | 这属于卡死，不能只靠异常日志定位 |
最先问现场人员四件事：什么时候发生、最后点了什么、是否每次必现、用的是哪个发布版本。不要只收一张“程序不见了”的截图。
2. 不要只在 Main 外面包一个 try/catch
WinForms 窗体事件、普通线程和 Task 的异常传播方式不同。
Application.ThreadException：用于 WinForms 消息循环中交给它处理的 UI 线程异常。设置处理模式要在创建第一个窗口之前完成。AppDomain.CurrentDomain.UnhandledException：收到未处理异常通知时，程序可能即将终止。它适合尽力记录信息，不能当作“阻止退出”的开关。- 自己启动的异步操作：让调用方
await，并在相应业务边界处理错误。丢掉 Task 后，再期待一个全局事件及时补救，并不可靠。
微软对 WinForms 异常模式 和 UnhandledException 有明确说明。全局记录只是最后一道诊断措施，业务代码仍要处理可预期的失败。
下面是入口接线示例。放在原Main中，DemoForm替换成自己的主窗体类名；ErrorLog在下一节给出。
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);Application.ThreadException+=(_,e)=>{string?log=ErrorLog.Write("UI",e.Exception);MessageBox.Show($"发生未处理异常。日志：{log??"写入失败"}","诊断演示");Application.Exit();// 仅适用于这里没有连接设备的演示程序。};AppDomain.CurrentDomain.UnhandledException+=(_,e)=>{Exceptionex=e.ExceptionObjectasException??newException("非 Exception 类型的未处理错误");ErrorLog.Write($"Unhandled; terminating={e.IsTerminating}",ex);};try{ApplicationConfiguration.Initialize();Application.Run(newDemoForm());}catch(Exceptionex){ErrorLog.Write("StartupOrRun",ex);Environment.ExitCode=1;}保留入口的[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{privatestaticreadonlyobjectGate=new();internalstaticstringRoot=Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),"CrashLogDemo","Logs");internalstaticstringFallbackRoot=Path.Combine(Path.GetTempPath(),"CrashLogDemo","Logs");publicstaticstring?Write(stringsource,Exceptionex){// 退出前同步尝试写入，不再依赖另一个后台任务。try{stringversion=Assembly.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}\n"+ex.ToString()+"\n---\n";lock(Gate){foreach(stringrootinnew[]{Root,FallbackRoot}){try{Directory.CreateDirectory(root);stringpath=Path.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.Enabled=false;try{// 故意制造一个托管异常，验证异常处理链路。awaitTask.Run(()=>thrownewIOException("模拟导出失败"));}catch(Exceptionex){string?log=ErrorLog.Write("Export",ex);MessageBox.Show($"导出失败。日志：{log??"写入失败"}");}finally{exportButton.Enabled=true;}}事件处理器可以使用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# 上位机离线授权方案。