用 dotnet-dump 分析 .NET 6+ 应用的内存 dump
现代 .NET（.NET 6 及以上）推荐用
dotnet-dump工具分析内存 dump，它跨平台、无需安装 Visual Studio，且能直接读取
coreclr运行时的托管堆结构。
先确认已安装 SDK（含
dotnet-dump）：
dotnet tool list -g若未安装，执行：
dotnet tool install -g dotnet-dump生成 dump：在 Linux/macOS 上用
dotnet-dump collect -p <pid></pid>；Windows 上可用
dotnet-dump collect -p <pid> --type Full</pid>（
--type Heap更轻量，但不包含非托管内存） 分析 dump：
dotnet-dump analyze <dump-file>进入交互式命令行后，常用命令有：
clrstack -all（所有线程托管调用栈）、
dumpheap -stat（按类型统计对象数量和大小）、
dumpheap -min 85000（查大对象堆 LOH 上的对象） 注意：
dotnet-dump无法解析 .NET Framework 的 dump；对 .NET 5 及更早版本支持有限，建议升级运行时或改用 WinDbg + SOS
用 WinDbg + SOS 分析 .NET Framework 或旧版 .NET Core dump
当目标是 .NET Framework（如 4.8）或 .NET Core 2.x/3.x 时，
WinDbg Preview（Windows）配合
SOS扩展仍是主力方案。关键在于加载匹配的
sos.dll和
mscordacwks.dll——版本错配会导致
Failed to load data access DLL错误。 下载对应运行时的调试符号包（如
dotnet-runtime-5.0.17-win-x64-symbols.zip），解压后把
sos.dll放到 dump 所在目录 在 WinDbg 中执行：
.loadby sos coreclr（.NET Core/.NET 5+）或
.loadby sos clr（.NET Framework） 验证是否就绪：
!eeversion应输出运行时版本；
!dumpheap -stat无报错即成功 常见卡点：
0x80004005错误多因架构不匹配（x64 进程用了 x86 WinDbg），务必用对应位数的调试器
定位高内存占用对象和泄漏源头
仅看
dumpheap -stat排名靠前的类型不够——要确认这些对象是否本该被回收。重点检查三类线索：静态引用、事件订阅未注销、缓存未清理。 查某类型所有实例：
dumpheap -type System.String，再挑一个地址用
!gcroot <address>追踪根引用链（注意：结果中出现
Finalizer Queue或
Static Variables是强信号） 对比多个 dump：用
dumpheap -stat分别导出，用脚本比对增长最快的类型（如
Dictionary<string object></string>实例数翻倍，大概率缓存没限容） LOH（大对象堆）异常膨胀？执行
dumpheap -min 85000 -stat，若大量
byte[]或
string占据高位，检查序列化、文件读取、Base64 解码等场景是否产生短命大对象
分析线程阻塞与死锁
线程 dump 的核心是确认哪些线程处于
Wait、
Blocked或
Running状态，并识别同步原语（
Monitor、
AsyncLock、
ManualResetEvent）的持有/等待关系。 在
dotnet-dump analyze中：
clrstack -all查所有托管线程栈；结合
dumpheap -type System.Threading.ManualResetEvent和
!syncblk（WinDbg）看锁状态 关键线索：
Monitor.Wait栈帧持续存在，且
!syncblk显示某线程持有一个
Monitor但无其他线程在等待 → 可能是条件未满足导致假死；若多个线程都在
Monitor.Enter卡住，且
!syncblk显示同一对象被持有 → 检查是否遗漏
Monitor.Exit或发生异常跳过释放 异步上下文容易被忽略：若栈中出现
await后挂起（如
TaskAwaiter.UnsafeOnCompleted），但后续回调未触发，可能是
SynchronizationContext丢失或
ConfigureAwait(false)被误用导致死锁（尤其在 UI 或 ASP.NET 同步上下文里） 分析 dump 最耗时间的环节不是命令执行，而是把栈帧、对象引用、线程状态拼成一个合理的故事——特别是混合了托管/非托管代码、多线程协作、异步流和第三方库时，
gcroot和
syncblk的输出必须结合业务逻辑反复验证。
