如何分析.NET Core进程转储中的非托管内存以定位内存泄漏

针对你提到的procdump文件，以下是具体的非托管内存分析步骤：

1. 用WinDbg + SOS扩展深度解析dump #

• 启动WinDbg并加载dump文件：windbg -z <你的dump文件路径>
• 加载对应.NET Core版本的SOS扩展：如果是默认路径，直接输入.load sos；如果路径特殊，用.load C:\path\to\sos.dll（需匹配应用的.NET Core runtime版本）
• 先区分内存类型：执行!eeheap -gc，输出会明确托管堆和非托管内存的占用情况，确认非托管内存的大致规模
• 分析非托管内存分布：运行!address -summary，这个命令会按内存区域类型（如私有堆、映射文件、栈等）统计占用，快速定位哪个区域是内存大户
• 深挖私有堆细节：如果!address显示私有堆占用最高，执行!heap -s列出所有原生堆的统计，找到容量最大的堆编号；接着用!heap -stat -h <堆编号>查看该堆的分配类型统计，找到占比最高的分配标记，结合代码或原生库的分配逻辑定位泄漏点

2. 排查常见非托管内存泄漏场景 #

• COM对象未释放：如果应用调用了COM组件，执行!comheap（需加载com扩展）查看COM堆的占用，或用!dumpobj检查托管对象中持有COM引用的字段，确认是否存在未释放的情况
• P/Invoke内存未回收：核对代码中所有P/Invoke调用，确保原生函数分配的内存（如malloc/new）都通过对应方法（free/delete）释放，尤其注意异步回调或异常分支中的释放逻辑
• 第三方原生库泄漏：用!dlls列出进程加载的所有原生DLL，结合!address的结果，重点关注占用内存高的DLL对应的模块，联系厂商获取调试信息或检查其文档中的内存管理说明

3. 辅助工具补充分析 #

• VMMap（实时场景）：如果能在客户现场复现问题，运行VMMap查看实时内存分布，对比dump文件的结果，确认内存增长的持续趋势和区域类型
• EventPipe + dotnet-trace：对于.NET Core 3.0及以上版本，可通过dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:0x8000000000000010:5命令收集原生内存分配事件，生成的trace文件可在PerfView中分析，追踪具体的分配调用栈

内容的提问来源于stack exchange，提问作者Jochen Kühner