dump-collect — Claude Code skill: what it does, how to install
A skill that walks your agent through setting up automatic crash dumps for .NET apps and capturing a dump from a running process on Linux, macOS and Windows, containers included.
npx skills add dotnet/skills --skill dump-collect -a claude-codeWhat dump-collect does
The skill runs in three steps. It works out the goal first: turn dumps on for future crashes, or grab one from a process that is running right now. Then the platform and runtime, and finally it loads the matching reference — references/coreclr-dumps.md, references/nativeaot-dumps.md, or references/container-dumps.md for Docker and Kubernetes. The actual work follows that file.
CoreCLR versus NativeAOT gets decided from the binary itself: strings <binary> | grep "CorExeMain" on Linux and macOS, nm, dumpbin /clrheader on Windows, while a live process can be checked through its loaded modules. Configuration stays outside the app: env vars such as DOTNET_DbgEnableMiniDump, OS settings, container specs. Application code is left alone.
The scope is spelled out in the skill. It stops once dumps are enabled or collected. Analysis, dotnet-dump analyze, windbg, chasing the root cause of a crash — not covered. .NET Framework processes that load clr.dll are out too, since only CoreCLR and NativeAOT are in scope. Enabled dumps temporarily? Unset DOTNET_DbgEnableMiniDump afterwards or the files pile up.
What it helps with
- turn on automatic crash dumps for a CoreCLR service
- capture a dump from a hung process by
<pid> - wire dump collection into a Kubernetes pod spec
- tell a NativeAOT build from CoreCLR in a binary
Example prompts for the agent
- Enable automatic crash dumps for the .NET service in Docker and drop them in
/var/dumps - Grab a dump from process
<pid>on the prod box and give me the file path - Check whether this build is NativeAOT or CoreCLR, then set up dumps for it
How to install dump-collect
1Skills CLI (Vercel)
npx skills add dotnet/skills --skill dump-collect -a claude-code2Manually: put the files in place
~/.claude/skills/dump-collect/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/dump-collect/
1Skills CLI (Vercel)
npx skills add dotnet/skills --skill dump-collect -a codex2Manually: put the files in place
.agents/skills/dump-collect/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add dotnet/skills --skill dump-collect -a cursor2Manually: put the files in place
.cursor/skills/dump-collect/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install dotnet/skills dump-collect2Manually: put the files in place
.github/skills/dump-collect/SKILL.md1Skills CLI (Vercel)
npx skills add dotnet/skills --skill dump-collect -a gemini-cli2Platform CLI
gemini skills install https://github.com/dotnet/skills --path plugins/dotnet-diag/skills/dump-collectManually: put the files in place
.devin/skills/dump-collect/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add dotnet/skills --skill dump-collect -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about dump-collect
How do I install dump-collect in Claude Code?
Run npx skills add dotnet/skills --skill dump-collect -a claude-code. The skill lands in ~/.claude/skills/dump-collect/SKILL.md.
What does dump-collect do?
It gets your agent to enable automatic crash dumps for a CoreCLR or NativeAOT app, or to capture a dump from a process that is already running. Linux, macOS and Windows are covered, containers too.
Will the skill analyze the dump for me?
No. It stops after collection and reports where the file is. dotnet-dump analyze, windbg and root-cause hunting sit outside what it handles.
Source text
SKILL.md · MIT
--- name: dump-collect description: "Configure and collect crash dumps for modern .NET applications. USE FOR: enabling automatic crash dumps for CoreCLR or NativeAOT, capturing dumps from running .NET processes, setting up dump collection in Docker or Kubernetes, using dotnet-dump collect or createdump. DO NOT USE FOR: analyzing or debugging dumps, post-mortem investigation with lldb/windbg/dotnet-dump analyze, profiling or tracing, or for .NET Framework processes." license: MIT --- # .NET Crash Dump Collection This skill configures and collects crash dumps for modern .NET applications (CoreCLR and NativeAOT) on Linux, macOS, and Windows — including containers. ## 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). ## Step 1 — Identify the Scenario 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? ### Detecting CoreCLR vs NativeAOT **From a binary file (Linux/macOS):** ```bash # CoreCLR — has IL metadata / managed entry point strings <binary> | grep -q "CorExeMain" && echo "CoreCLR" # NativeAOT — has Redhawk runtime symbols strings <binary> | grep -q "Rhp" && echo "NativeAOT" # On macOS/Linux, also try: nm <binary> 2>/dev/null | grep -qi "Rhp" && echo "NativeAOT" ``` **From a binary file (Windows):** ```powershell # CoreCLR — has a CLI header (IL entry point) dumpbin /clrheader <binary.exe> | Select-String "CLI Header" -Quiet # NativeAOT — no CLI header, has Redhawk symbols dumpbin /symbols <binary.exe> | Select-String "Rhp" -Quiet ``` **From a running process (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 # 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 # CoreCLR — loads coreclr.dll (Get-Process -Id <pid>).Modules.ModuleName -contains "coreclr.dll" # .NET Framework — loads clr.dll (this skill does not apply) (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. ## Step 2 — Load the Appropriate Reference Based on the scenario identified in Step 1, read the relevant reference file: | Scenario | Reference | |----------|-----------| | 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) | ## Step 3 — Execute 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.
© dotnet · MIT · dotnet/skills