C# WinDbg SOS命令 C#常用SOS调试命令有哪些

用 !dumpheap -stat 快速定位托管堆内存占用最多的类型，关注 Size 列（该类型所有实例累计字节数），结合 -type、-min 85000 精准筛选；再用 !gcroot 查引用链，明确谁强引用阻止回收；最后用 !clrstack 和 !pe 分析线程状态与异常上下文，三者串联才能准确定位内存问题根因。

怎么快速定位托管堆里谁占内存最多

直接用 !dumpheap -stat，它会按类型统计对象数量和总大小，排在最上面的往往就是泄漏元凶或高频分配类型。注意看 Size 列——不是单个对象大小，而是该类型所有实例的累计字节数。

• 如果怀疑某类（比如 System.String 或自定义的 OrderItem），加 -type OrderItem 精准过滤
• -min 85000 可筛出大对象堆（LOH）上的对象，常用于排查大数组、大字符串堆积
• 别只盯着数量多的类型——Byte[] 可能只有几百个实例，但每个几 MB，总量远超上万个小对象

对象查不到引用链？一定是没搞清 GC Root 的真实含义

!gcroot 不是“谁创建了它”，而是“谁正持有强引用阻止它被回收”。常见误区是看到 Finalizer Queue 就以为是终结器卡住——其实只是对象已标记待终结，真正阻塞回收的往往是它被某个静态集合、事件委托、缓存字典或未注销的 WPF 绑定强引用着。

• 运行前确保已执行 !dumpheap -stat 拿到目标对象地址（如 000002a4b5c6d830），再输 !gcroot 000002a4b5c6d830
• 输出中出现 DOMAIN(000002A4B5C6D830):HANDLE(Pinned) 表示被 Pinning（如非托管互操作中固定内存），这类引用不会随 GC 移动，也极难释放
• 若输出含 EEHeap 或大量 MT 地址，说明可能在 JIT 编译器或反射缓存里，需结合 !dumpmt 追查方法表

线程卡死或异常崩溃？先看托管栈和当前异常

!clrstack 和 !pe 是两个必须连用的命令：前者告诉你线程正在哪行托管代码执行（哪怕已崩溃），后者告诉你最后抛出的异常是什么、堆栈在哪断开。

Napkin AI

Napkin AI 可以将您的文本转换为图表、流程图、信息图、思维导图视觉效果，以便快速有效地分享您的想法。

下载

• !clrstack -a 加上 -a 参数可显示托管帧的局部变量值（对调试 NullReferenceException 极有用）
• !pe 输出里重点关注 Exception Object: 后的地址，接着用 !do 查看异常内部字段（如 InnerException、StackTraceString）
• 如果 !clrstack 显示大量线程停在 WaitHandle.WaitOne 或 Monitor.Enter，大概率是锁竞争或死锁，配合 !threads 看线程状态（Preemptive vs Cooperative）和锁持有者

加载 SOS 失败？90% 是架构/版本不匹配

.loadby sos clr 看似简单，但 WinDbg 会根据当前进程位数（x64/x86）和 .NET 版本自动选错 sos.dll。.NET Core/.NET 5+ 更要小心：sos.dll 已被 sosplugin.dll 替代，且必须与运行时版本严格对应。

• 32 位进程不能加载 64 位 SOS；反之亦然——用 .effmach 确认当前目标架构
• .NET Framework 应用优先用 .loadby sos clr；.NET Core/6+ 必须用 .load C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.0\sos.dll（路径按实际版本调整）
• 加载失败报 The call to LoadLibrary(sos) failed, Win32 error 0n126，基本是路径不存在或位数不匹配；报 Failed to load data access DLL，大概率是 mscordacwks.dll 版本不对，需从对应运行时目录复制同名 DLL 到 WinDbg 插件路径