为什么 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 里看到的“等待”只是表象，真正要逆向推的是谁持有了它、为什么没放。
