Debugger.Launch() 在挂起时无效，因 UI 线程已阻塞，代码无法执行到该语句；应通过 Windows 事件查看器查未处理异常日志，或用 procdump 捕获 .dmp 文件分析线程等待状态、锁持有情况及 Finalizer 阻塞问题。
为什么 Debugger.Launch() 在挂起时根本不起作用
因为应用已失去响应，UI 线程阻塞或死锁，Debugger.Launch() 依赖线程能执行到那行代码——而挂起时它压根没机会运行。别指望在 Application.Run() 后加这句能捕获“已卡住”的瞬间。
用 Windows 事件查看器定位挂起前的最后异常
很多“挂起”其实是未处理异常被静默吞掉（尤其在 WinForms 的 Application.ThreadException 或 WPF 的 Dispatcher.UnhandledException 中未订阅）。系统会把这类崩溃前的堆栈写入 Windows 日志：
- 打开
事件查看器 → Windows 日志 → 应用程序 - 筛选来源为
.NET Runtime或Application Error - 按时间倒序找最近几条，重点关注
Exception Info字段里的System.NullReferenceException、System.Threading.SynchronizationLockException等
用 procdump 捕获挂起进程的内存转储（.dmp）
这是最可靠的方式：不依赖代码修改，直接从外部抓取卡死时的完整线程状态和调用栈。
- 下载
procdump（来自 Sysinternals，免费） - 命令行执行：
procdump -ma -e 1 -h -t "MyApp.exe"
其中-h表示检测挂起（GUI 线程无响应），-t表示触发后自动退出，-e 1捕获未处理异常 - 生成的
MyApp.exe_240501_123456.dmp文件可用 Visual Studio（需安装 .NET Desktop Development 工作负载）直接打开 → 查看“调试 → 窗口 → 并行堆栈”或“线程”窗口
在 Visual Studio 中分析 dump 文件时重点看什么
打开 .dmp 后别急着看源码——先确认线程是否真卡在某个同步点上：
- 打开“并行堆栈”窗口，找状态为
Wait或Sleep且持续时间超长的线程 - 右键某线程 → “切换到线程”，再看其调用栈顶部是否含
Monitor.Enter、lock、Task.Wait()、GetAwaiter().GetResult() - 检查是否有线程在
WaitHandle.WaitOne()或AutoResetEvent.WaitOne()上无限等待——常见于跨线程资源释放遗漏 - 注意
Finalizer线程是否被阻塞：如果它卡在某个Dispose方法里，会导致所有待回收对象堆积，间接拖慢主线程
挂起问题的复杂性往往不在单个函数，而在多个线程对同一把锁/信号量的争夺顺序和释放时机——dump 里看到的“等待”只是表象，真正要逆向推的是谁持有了它、为什么没放。
