.NET 8 WinForms应用崩溃：已回收委托回调问题排查求助

核心问题解析 #

从Windows事件日志可以明确：崩溃是CLR通过System.Environment.FailFast主动终止进程，触发原因是已被垃圾回收的WNDPROC委托被WinAPI回调调用。

为什么全局异常处理没生效？ #

FailFast是CLR为避免严重内存安全问题（比如回调指向已回收内存）而执行的强制终止逻辑，不会触发普通的AppDomain.UnhandledException、Application.ThreadException事件，也无法被try-catch捕获，所以你的日志里不会有相关记录。

为什么Dump文件没生成？ #

可能有以下几个原因：

• 环境变量未在进程启动前生效：自包含部署的应用需要在启动前设置环境变量，事后设置无法被进程读取。
• 权限不足：指定的Dump路径（如系统目录、Program Files）没有写入权限，需选择用户有权限的目录（如文档、桌面）。
• .NET版本bug：.NET 8.0.1可能存在Dump生成的已知问题，建议升级到.NET 8的最新补丁版本。

具体排查与修复步骤 #

一、定位WNDPROC委托被GC的根源 #

这是WinAPI互操作的经典问题：当.NET委托作为回调传给WinAPI时，如果没有强引用保留，GC会在委托不再被.NET代码引用时回收它，后续WinAPI调用该回调就会触发FailFast。

1. 检查所有使用WNDPROC的代码：
   • 找出调用SetWindowLongPtr、SetWindowSubclass等需要传入WNDPROC回调的逻辑。
   • 确认每个传给WinAPI的WNDPROC委托都被类成员字段保留强引用，而非局部变量（局部变量会在方法执行完成后被标记为可回收）。
   • 重点排查动态创建的窗口/控件：比如临时创建窗口并设置回调，方法结束后委托被回收，窗口后续收到消息就会触发崩溃。
2. 临时验证手段：在设置回调的代码末尾添加GC.KeepAlive(委托实例)，但这只是临时 workaround，根本解决必须保留强引用。

二、解决Dump生成问题，获取崩溃现场 #

1. 用批处理确保环境变量生效：
   创建启动批处理，先设置环境变量再启动应用：

   set DOTNET_DbgEnableMiniDump=1
   set DOTNET_DbgMiniDumpType=2  // 全内存Dump，比类型4的MiniDump包含更多信息
   set DOTNET_DbgMiniDumpName=C:\Users\当前用户名\Documents\app_crash.dmp
   start program_name.exe
   

2. 手动生成Dump：
   • 若能复现问题，在崩溃前打开任务管理器，找到program_name.exe，右键→创建转储文件。
   • 或使用procdump工具：运行procdump -e -w program_name.exe C:\指定路径，进程崩溃时自动生成Dump。
3. 检查路径权限：确保Dump存储目录应用进程有写入权限，避免使用系统保护目录。

三、修复与验证 #

1. 修复委托引用问题：
   将WNDPROC委托存储在类成员字段中，确保窗口生命周期内不会被GC回收，示例代码：

   private WNDPROC _windowProc; // 类字段保留强引用
   
   public void SetupWindowCallback(IntPtr hwnd)
   {
       _windowProc = new WNDPROC(MyCustomWindowProc);
       SetWindowLongPtr(hwnd, GWLP_WNDPROC, Marshal.GetFunctionPointerForDelegate(_windowProc));
   }
   
   private IntPtr MyCustomWindowProc(IntPtr hwnd, uint msg, IntPtr wParam, IntPtr lParam)
   {
       // 自定义窗口消息处理逻辑
       return DefWindowProc(hwnd, msg, wParam, lParam);
   }
   

2. 验证修复效果：
   • 修复后模拟普通异常，确认全局异常处理能正常捕获并写入日志。
   • 手动触发Environment.FailFast("test")，验证Dump文件是否正常生成。

内容的提问来源于stack exchange，提问作者thebignoobwantstolearn