Back to Details

dump-collect

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

.NET Crash Dump Collection

.NET崩溃转储文件收集

This skill configures and collects crash dumps for modern .NET applications (CoreCLR and NativeAOT) on Linux, macOS, and Windows — including containers.
本技能用于在Linux、macOS和Windows（包括容器环境）中为现代.NET应用（CoreCLR和NativeAOT）配置并收集崩溃转储文件。

Stop Signals

停止信号

🚨 Read before starting any workflow.
  • Stop after dumps are enabled or collected. Do not open, analyze, or triage dump files.
  • If the user already has a dump file, this skill does not cover analysis. Let them know analysis is out of scope.
  • Do not install analysis tools (dotnet-dump analyze, windbg). Only install collection tools (dotnet-dump collect). Using 
    lldb
    for on-demand dump capture on macOS is allowed — it ships with Xcode command-line tools and is not being used for analysis.
  • Do not trace root cause of crashes. Report the dump file location and move on.
  • Do not modify application code. Configuration is environment-only (env vars, OS settings, container specs).
🚨 开始任何工作流前请阅读以下内容。
  • 在转储启用或收集完成后停止操作。 不要打开、分析或分类转储文件。
  • 如果用户已拥有转储文件，本技能不包含分析内容，请告知用户分析不在本技能范围内。
  • 不要安装分析工具（如dotnet-dump analyze、windbg）。仅安装收集工具（dotnet-dump collect）。允许在macOS上使用
    lldb
    进行按需转储捕获——它随Xcode命令行工具一同发布，且此处不用于分析用途。
  • 不要追踪崩溃的根本原因。只需报告转储文件的位置即可。
  • 不要修改应用代码。仅可进行环境配置（如环境变量、系统设置、容器规格）。

Step 1 — Identify the Scenario

步骤1 — 确定场景

Ask or determine:
  1. Goal: Enable automatic crash dumps, or capture a dump from a running process right now?
  2. Platform: Linux, macOS, or Windows? Running in a container (Docker/Kubernetes)?
  3. Runtime: CoreCLR or NativeAOT?
询问或确定以下信息：
  1. 目标：是启用自动崩溃转储，还是立即从运行中的进程捕获转储文件？
  2. 平台：Linux、macOS还是Windows？是否运行在容器（Docker/Kubernetes）中？
  3. 运行时：CoreCLR还是NativeAOT？

Detecting CoreCLR vs NativeAOT

区分CoreCLR与NativeAOT

From a binary file (Linux/macOS):
bash
undefined
从二进制文件判断（Linux/macOS）：
bash
undefined

CoreCLR — has IL metadata / managed entry point

CoreCLR — 包含IL元数据/托管入口点

strings <binary> | grep -q "CorExeMain" && echo "CoreCLR"
strings <binary> | grep -q "CorExeMain" && echo "CoreCLR"

NativeAOT — has Redhawk runtime symbols

NativeAOT — 包含Redhawk运行时符号

strings <binary> | grep -q "Rhp" && echo "NativeAOT"
strings <binary> | grep -q "Rhp" && echo "NativeAOT"

On macOS/Linux, also try:

在macOS/Linux上，也可尝试：

nm <binary> 2>/dev/null | grep -qi "Rhp" && echo "NativeAOT"

**From a binary file (Windows):**
```powershell
nm <binary> 2>/dev/null | grep -qi "Rhp" && echo "NativeAOT"

**从二进制文件判断（Windows）：**
```powershell

CoreCLR — has a CLI header (IL entry point)

CoreCLR — 包含CLI头（IL入口点）

dumpbin /clrheader <binary.exe> | Select-String "CLI Header" -Quiet
dumpbin /clrheader <binary.exe> | Select-String "CLI Header" -Quiet

NativeAOT — no CLI header, has Redhawk symbols

NativeAOT — 无CLI头，包含Redhawk符号

dumpbin /symbols <binary.exe> | Select-String "Rhp" -Quiet

**From a running process (Linux):**
```bash
dumpbin /symbols <binary.exe> | Select-String "Rhp" -Quiet

**从运行中的进程判断（Linux）：**
```bash

Resolve the binary, then use the same file checks

解析二进制文件路径，然后使用上述文件检查方法

BINARY=$(readlink /proc/<pid>/exe) strings "$BINARY" | grep -q "CorExeMain" && echo "CoreCLR" || echo "NativeAOT"

**From a running process (macOS):**
```bash
BINARY=$(readlink /proc/<pid>/exe) strings "$BINARY" | grep -q "CorExeMain" && echo "CoreCLR" || echo "NativeAOT"

**从运行中的进程判断（macOS）：**
```bash

Resolve the binary path from the running process

从运行中的进程解析二进制文件路径

BINARY=$(ps -o comm= -p <pid>) strings "$BINARY" | grep -q "CorExeMain" && echo "CoreCLR" || echo "NativeAOT"

**From a running process (Windows PowerShell):**
```powershell
BINARY=$(ps -o comm= -p <pid>) strings "$BINARY" | grep -q "CorExeMain" && echo "CoreCLR" || echo "NativeAOT"

**从运行中的进程判断（Windows PowerShell）：**
```powershell

CoreCLR — loads coreclr.dll

CoreCLR — 加载coreclr.dll

(Get-Process -Id <pid>).Modules.ModuleName -contains "coreclr.dll"
(Get-Process -Id <pid>).Modules.ModuleName -contains "coreclr.dll"

.NET Framework — loads clr.dll (this skill does not apply)

.NET Framework — 加载clr.dll（本技能不适用）

(Get-Process -Id <pid>).Modules.ModuleName -contains "clr.dll"

> **If the app is .NET Framework (`clr.dll`), stop.** This skill covers modern .NET (CoreCLR and NativeAOT) only.
>
> **If neither CoreCLR nor NativeAOT is detected, stop.** This skill only applies to .NET applications — do not proceed.
(Get-Process -Id <pid>).Modules.ModuleName -contains "clr.dll"

> **如果应用是.NET Framework（加载clr.dll），请停止操作。** 本技能仅适用于现代.NET（CoreCLR和NativeAOT）。
>
> **如果未检测到CoreCLR或NativeAOT，请停止操作。** 本技能仅适用于.NET应用——请勿继续。

Step 2 — Load the Appropriate Reference

步骤2 — 加载对应的参考文档

Based on the scenario identified in Step 1, read the relevant reference file:
ScenarioReference
CoreCLR app (any platform)
references/coreclr-dumps.md
NativeAOT app (any platform)
references/nativeaot-dumps.md
Any app in Docker or Kubernetes
references/container-dumps.md
(then also load the runtime-specific reference)
根据步骤1确定的场景，读取对应的参考文档：
场景参考文档
CoreCLR应用（任意平台）
references/coreclr-dumps.md
NativeAOT应用（任意平台）
references/nativeaot-dumps.md
Docker或Kubernetes中的任意应用
references/container-dumps.md
（之后还需加载对应运行时的参考文档）

Step 3 — Execute

步骤3 — 执行操作

Follow the instructions in the loaded reference to configure or collect dumps. Always:
  1. Confirm the dump output directory exists and has write permissions before enabling collection.
  2. Report the dump file path back to the user after collection succeeds.
  3. Verify configuration took effect — for env vars, echo them; for OS settings, read them back.
  4. Remind the user to disable automatic dumps if they were enabled temporarily — remove or unset 
    DOTNET_DbgEnableMiniDump
    and related env vars to avoid accumulating dump files.
按照加载的参考文档中的说明配置或收集转储文件。请始终执行以下操作：
  1. 确认转储输出目录存在且具备写入权限，然后再启用收集功能。
  2. 在收集成功后向用户报告转储文件的路径。
  3. 验证配置已生效——对于环境变量，输出其值；对于系统设置，读取设置内容进行确认。
  4. 如果是临时启用自动转储，请提醒用户在使用后禁用——移除或取消设置
    DOTNET_DbgEnableMiniDump
    及相关环境变量，以避免转储文件堆积。