dotnet-dump是诊断.NET内存问题的跨平台命令行工具，支持通过进程PID采集mini/heap/full类型内存转储，Linux/macOS还可通过SIGUSR2信号在容器中触发，Windows可选Procdump替代。
如果您需要诊断.NET应用程序的内存问题，例如内存泄漏或高内存占用，dotnet-dump 是一个轻量级、跨平台的命令行工具，可用于在运行时捕获托管堆的完整内存转储。以下是为.NET应用创建内存转储的具体方法：
一、确认目标进程并安装dotnet-dump
dotnet-dump 工具需作为全局工具安装，并要求目标应用运行于 .NET Core 3.0 或更高版本（包括 .NET 5+）。该工具不依赖调试符号或源代码，可直接附加到正在运行的进程。
1、打开终端（Linux/macOS）或命令提示符/PowerShell（Windows）。
2、执行 dotnet tool install -g dotnet-dump 安装最新稳定版全局工具。
3、运行 dotnet-dump --version 验证安装成功并查看版本号。
4、使用 dotnet-dump ps 列出当前所有可附加的 .NET 进程及其 PID 和进程名称。
二、使用dotnet-dump collect创建实时转储
此方法通过直接附加到运行中的 .NET 进程，触发即时内存快照采集，适用于 Linux/macOS/Windows（需满足权限与运行时兼容性）。
1、从 dotnet-dump ps 输出中识别目标应用的 PID（例如 12345）。
2、执行 dotnet-dump collect -p 12345 启动采集；默认生成 core_YYYYMMDD_HHMMSS 格式的 .dmp 文件（Linux/macOS）或 .dmp/.dump 文件（Windows）。
3、如需指定输出路径，添加 -o /path/to/myapp.dmp 参数。
4、采集完成后，工具将显示文件绝对路径及大小，例如：Writing full to /tmp/myapp.dmp。
三、使用dotnet-dump collect配合 --type选项指定转储类型
dotnet-dump 支持三种转储类型，影响文件大小与分析能力：mini（仅本机上下文）、heap（含托管堆）、full（完整内存镜像）。默认为 heap，但可根据诊断需求显式指定。
1、采集最小化转储（快速、小体积，适合初步崩溃分析）：dotnet-dump collect -p 12345 --type mini。
2、采集完整托管堆转储（推荐用于内存泄漏分析）：dotnet-dump collect -p 12345 --type heap。
3、采集全内存转储（最大体积，包含非托管内存，需足够磁盘空间）：dotnet-dump collect -p 12345 --type full。
四、在无交互环境（如容器或服务）中触发转储
当应用以守护进程、systemd 服务或 Docker 容器方式运行时，无法直接执行交互命令，此时可通过发送 SIGUSR2 信号触发自动转储（仅限 Linux/macOS，且需 .NET 6+ 运行时）。
1、确保目标应用使用 DOTNET_DUMPSIGNAL=SIGUSR2 环境变量启动（例如在 Dockerfile 中添加 ENV DOTNET_DUMPSIGNAL=SIGUSR2）。
2、获取容器内进程 PID：docker exec -it <container-id> ps aux | grep dotnet。
3、向该 PID 发送信号：docker exec -it <container-id> kill -SIGUSR2 <pid>。
4、转储文件将自动生成于进程工作目录，文件名形如 coreclr_<pid>_<timestamp>.dmp。
五、使用procdump替代方案（Windows专用）
在 Windows 平台上，若 dotnet-dump 不可用或附加失败，可使用 Sysinternals Procdump 工具作为补充手段。它支持基于条件（如内存阈值）自动触发转储，且兼容更老版本的 .NET Framework 应用。
1、下载 procdump.exe 并置于系统 PATH 或当前目录。
2、对 PID 为 12345 的进程创建转储：procdump -ma 12345。
3、按内存使用率超过 800MB 时自动捕获：procdump -ma -m 800 12345。
4、生成文件默认命名为 PROCDUMP_PID_YYMMDD_HHMMSS.dmp，可使用 -o 指定输出路径。
