现代.NET 6+推荐用dotnet-dump分析内存dump，跨平台、无需VS，支持直接解析托管堆；.NET Framework或旧版需WinDbg+SOS，注意版本与架构匹配。
用 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 错误。
windows-auto
下载
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
- 下载对应运行时的调试符号包（如
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 同步上下文里）
gcroot 和 syncblk 的输出必须结合业务逻辑反复验证。 
