AWS ECS Docker微服务内存dump在DotMemory中仅显示<Unresolved>的解决方法

核心原因 #

gcore生成的是原生Linux进程Dump，而DotMemory需要依赖.NET CLR运行时的元数据、托管对象结构等信息才能解析，直接用gcore抓取的dump缺少这些关键数据，导致所有内容显示<Unresolved>。本地Windows任务管理器生成的dump包含完整CLR信息，因此能正常分析。

解决步骤 #

1. 用.NET官方工具替换gcore生成dump #

Linux环境下的.NET应用，必须使用dotnet-dump工具生成包含CLR信息的专用dump：

• 在容器内安装dotnet-dump：

  dotnet tool install --global dotnet-dump
  

• 查找目标服务的进程ID（PID）：

  ps aux | grep <你的微服务进程名>
  

• 生成符合要求的dump文件：

  dotnet-dump collect -p <目标PID> -o /tmp/service_dump.dmp
  

2. 匹配线上与本地的.NET版本 #

线上容器的.NET Runtime版本（如.NET 6/7/8）必须和本地DotMemory支持的版本完全一致，否则会因版本不兼容导致解析失败：

• 查看线上.NET版本：

  dotnet --version
  

• 本地安装对应版本的.NET SDK/Runtime，确保DotMemory能加载对应版本的调试组件。

3. 确保符号文件可访问 #

如果仍有内容无法解析，需保证应用的符号文件（.pdb）能被DotMemory读取：

• 部署容器时，将pdb文件与应用程序一同打包到镜像中（生产环境可选择单独存储pdb，分析时手动指定路径）。
• 加载dump后，在DotMemory的「符号设置」中添加pdb文件所在目录，强制加载符号。

4. 验证dump完整性 #

上传到S3前先在容器内确认dump有效：

• 用dotnet-dump analyze /tmp/service_dump.dmp在容器内执行简单分析，若能正常列出托管堆信息，说明dump生成正常。
• 上传前后校验MD5值，避免文件损坏：

  md5sum /tmp/service_dump.dmp
  

  下载后本地重新计算MD5，确认与容器内的结果一致。

5. 适配轻量容器镜像的依赖 #

如果容器基于Alpine等轻量镜像，需先安装dotnet-dump依赖的基础库：

apk add icu-libs

同时确保容器磁盘空间充足（dump文件大小通常接近进程占用内存，需预留至少2倍进程内存的空间）。

内容的提问来源于stack exchange，提问作者MrDemien