.NET程序出现死锁时，最典型的表现是界面冻结或接口请求全部超时，但进程没有崩溃，CPU占用也不高。这种问题在开发环境很难复现，往往只在线上偶发。WinDbg作为微软官方的内核级调试器，配合SOS调试扩展，可以直接分析dump文件中的托管线程堆栈和锁信息，是排查这类问题最有效的工具之一。本文将完整介绍从环境准备到死锁定位的全过程。
一、准备工作：安装WinDbg与配置SOS扩展
首先需要安装WinDbg，可以选择经典的WinDbg Classic，也可以从微软商店安装新版WinDbg（界面更友好，支持命令历史搜索）。安装完成后还需要对应版本的调试符号，通常在符号路径中指向微软符号服务器即可：
0:000> .sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols 0:000> .reload
接下来是加载SOS扩展。SOS是随.NET运行时一起发布的调试扩展，用于查看托管堆、线程、同步块等信息。如果dump的目标机器与你的机器.NET版本一致，可以直接用.loadby sos clr加载。如果版本不一致，需要从目标机器上拷贝与运行时版本匹配的sos.dll，再用.load指定完整路径加载。
0:000> .loadby sos clr 0:000> !help
执行!help能列出所有SOS命令说明，说明扩展加载成功。这里有个常见的坑：如果程序运行的是.NET Framework 2.0或3.5，扩展名是mscorwks而不是clr，加载命令应写作.loadby sos mscorwks。而对于.NET Core和.NET 5以后的程序，同样使用clr，但需要确保dotnet运行时版本与调试机匹配，否则部分命令可能报错。
二、抓取dump文件的几种方式
分析的第一步是拿到一份dump文件。最常用的方式是使用任务管理器：右键进程，选择“创建转储文件”，生成的dmp文件会保存在临时目录。这种方式简单直接，但抓的是完整dump，体积较大，一个大内存进程的dump可能有几十GB，拷贝和分析都很慢。
更推荐的方式是使用procdump这个命令行工具，它可以按需抓取，比如在CPU超过阈值时触发，或在进程出现挂起窗口（hung window）时自动抓取：
procdump -ma MyProcess.exe D:\dumps\ procdump -h MyProcess.exe D:\dumps\hung.dmp
-ma表示抓完整dump，-h表示在窗口挂起时触发。对于死锁分析，一般建议抓完整dump，因为minidump不包含完整的堆内存，SOS的很多命令会失败。如果目标机器磁盘空间紧张，也可以在服务器本地用WinDbg attach到进程后用.dump /ma命令生成文件。
抓取时机很关键。死锁发生后越早抓越好，因为此时所有相关线程都停在原地，堆栈信息最完整。如果等到线程池耗尽之后很久再抓，可能混入大量因排队而阻塞的正常线程，增加分析干扰。
三、查看线程堆栈：从~* k到!clrstack
打开dump文件后，第一步是看所有线程的概况。命令~* k会列出每个线程的内核态堆栈，而SOS提供的!threads则专门显示托管线程的信息，包括线程ID、状态标记、是否为线程池线程等：
0:000> !threads ThreadCount: 25 UnstartedThread: 0 BackgroundThread: 20 0:0 1234 8e40 Worker 0000012345678900 1:1 2345 1a20 Worker 0000012345678a00 ...
找到可疑线程后，用~线程号s切换到该线程，然后执行!clrstack查看托管调用栈。加参数-p可以显示每帧方法的参数，这在定位具体是哪个对象作为锁时非常有用：
0:000> ~8s
0:008> !clrstack -p
OS Thread Id: 0x1a20 (8)
00007FF... System.Threading.Monitor.Wait(System.Object, Int32, Boolean)
obj = 0x0000012345678900
00007FF... Program.TransferMoney(Account, Account, Decimal)
from = 0x0000012345678910
to = 0x0000012345678920上面的堆栈清楚地显示，线程8正在TransferMoney方法中调用Monitor.Wait等待一个对象锁。如果看到多个线程都停在类似的位置，且互相持有对方需要的锁，死锁的轮廓就浮现出来了。另外!clrstack只显示托管帧，如果怀疑死锁发生在托管与非托管代码的交界处，可以用kb命令查看混合堆栈，或者用!dumpstack获取更完整的信息。
四、用!syncblk定位锁的持有关系
这是死锁分析最核心的一步。.NET中lock语句底层使用Monitor实现，锁信息记录在对象头的同步块索引中，SOS的!syncblk命令可以列出当前所有被持有的锁：
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
5 0000012345abcdef 3 1 00000123... 2345 1a20 0000012345678910 Account
9 0000012346abcdef 3 1 00000124... 1234 8e40 0000012345678920 Account解读这个输出：MonitorHeld为3表示有一个线程持有锁且有一个线程在等待（持有计数为1，等待会使计数加2）。Owning Thread Info列出了持有锁的线程ID。结合上一步的堆栈信息可以看出：线程1a20持有对象8910的锁却在等对象8920，而线程8e40持有8920却在等8910，这就是典型的两把锁交叉等待的死锁。
确定死锁对象后，可以用!do 对象地址查看对象详情，用!dumpheap -type Account在堆上搜索同类型对象，进一步确认业务含义。整个分析链条可以总结为：!threads找线程、!clrstack看堆栈、!syncblk找锁主、!do看对象，四步走完基本就能还原死锁现场。
五、常见死锁场景与预防建议
实际项目中最常见的死锁场景有三类。第一类是锁顺序不一致，比如两个线程分别以不同顺序获取两把锁，解决方法是统一加锁顺序，或者引入超时机制：Monitor.TryEnter(obj, TimeSpan.FromSeconds(5))，获取失败时记录日志并放弃重试，避免永久等待。
第二类是混合锁导致的死锁，比如一个线程先lock再调用异步方法等待，另一个线程在回调里又去拿同一把锁。在async/await代码中应避免使用lock包裹await，改用SemaphoreSlim.WaitAsync。第三类是WinForms或WPF中的UI死锁，典型如用Result或Wait()同步等待一个依赖UI上下文的Task，此时线程被阻塞而延续任务需要UI线程才能执行，形成循环等待。
// 危险：在UI线程同步等待会死锁
var result = GetDataAsync().Result;
// 正确：全链路异步
private async void Button_Click(object sender, EventArgs e)
{
var result = await GetDataAsync();
label1.Text = result;
}预防层面，还有几条经验值得遵守：能不用锁就不用锁，优先考虑不可变数据结构、并发集合（如ConcurrentDictionary）或Interlocked类；锁对象应该是私有的，避免外部代码意外参与锁竞争；锁的粒度尽量小，临界区内不要做IO、不要调用外部回调；最后，在代码评审时专门检查多把锁的获取顺序，很多线上死锁都源于不同模块各自加锁时顺序没有约定。掌握了WinDbg的分析方法，再配合这些编码规范，死锁问题基本可以在开发和线上两个阶段都被有效控制。