需先用.loadby sos clr（.NET Framework）或.loadby sos coreclr（.NET Core/.NET 5+）加载匹配的SOS，再通过!pe、!dumpheap等命令分析异常与内存问题。
如何加载SOS.dll并确认.NET运行时版本
WinDbg里用SOS前，得先让调试器知道当前进程跑的是哪个.NET版本。64位系统上常见错误是加载了错位的SOS——比如用x86版WinDbg调试x64进程，或反过来。执行 .loadby sos clr（.NET Framework）或 .loadby sos coreclr（.NET Core/.NET 5+）最稳妥，它会自动从已加载的CLR模块匹配对应SOS。如果失败，检查 lm vm clr 或 lm vm coreclr 确认模块是否已加载；没加载说明还没触发JIT或进程卡在启动前，可先运行 !peb 看环境变量、或用 g 让程序跑起来再试。
常用SOS命令定位托管异常和内存问题
分析崩溃或卡死时，!pe（显示当前异常对象）和 !dumpheap -stat（统计托管堆类型分布）是最先该跑的两个命令。若发现某类实例数量异常高，用 !dumpheap -type <code>TypeName 列出所有实例地址，再挑几个用 !do <code>address 查看具体内容。注意：.NET Core中 !dumpheap -stat 默认不显示完整命名空间，加 -min 0 可避免漏掉小对象；而 !clrstack -a 能看到托管线程的完整调用栈和局部变量值，但需符号路径正确（.sympath 设置对），否则变量名显示为 <no data></no>。
为什么 !dumpobj 显示“Invalid object”或地址无效
这个错误基本意味着你传给 !dumpobj 的地址不是有效的托管对象指针。常见原因有：
- 地址来自非托管堆（比如C++分配的内存）
- 对象已被GC回收，但地址还留在某个变量里（悬垂指针）
- 用了错误的地址——比如把方法表地址（MT）当成了对象地址（Object）
- .NET Core中某些内部结构（如Span
）不直接对应托管堆对象，不能直接 !do
!eeheap -gc 查GC堆范围，再用 !dumpheap -min 0 -max 0xffffffff 扫一遍，看目标地址是否在任一segment内；或者用 !ip2md <code>instruction_ptr 反查方法，确认上下文是否合理。
分析多线程死锁和同步块争用
当怀疑线程挂起在锁上，先用 ~*e !clrstack 看所有线程托管栈，找阻塞在 Monitor.Enter、WaitHandle.WaitOne 或 Task.Wait 的线程。接着用 !syncblk 查同步块状态——重点关注 OWNING THREAD 列，它指向持有该锁的线程ID（如 12），然后回到线程列表里找 ~12s 切过去看它在干什么。注意：.NET Core 3.0+ 默认禁用同步块（SyncBlock）复用，!syncblk 输出可能为空，此时改用 !threads + !clrstack 组合分析等待链；另外 !dlk 命令（仅.NET Framework）能自动检测简单死锁，但对复杂场景（如Lock + Semaphore组合）不可靠，别全信。
