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.
Intro in this page language first. The official description stays in its original wording; we do not rewrite SKILL.md.
What it does
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.
When to use it
The official description does not include a separate “Use when”. Per the spec, agents activate this skill when the task matches keywords in that description.
How agents load it
Per Agent Skills progressive disclosure: name and description load at startup (~100 tokens); the full SKILL.md body loads when the skill activates; scripts/, references/, and assets/ load only as needed. This file's sections: .NET Crash Dump Collection; Stop Signals; Step 1 — Identify the Scenario; Detecting CoreCLR vs NativeAOT; CoreCLR — has IL metadata / managed entry point; NativeAOT — has Redhawk runtime symbols. It includes spec-recommended sections: step-by-step instructions.
File analysis
File analysis: besides SKILL.md, the body references references/coreclr-dumps.md, references/nativeaot-dumps.md, references/container-dumps.md. Those resources load on demand.
.NET Crash Dump CollectionStop SignalsStep 1 — Identify the ScenarioDetecting CoreCLR vs NativeAOTCoreCLR — has IL metadata / managed entry pointNativeAOT — has Redhawk runtime symbolsOn macOS/Linux, also try:CoreCLR — has a CLI header (IL entry point)NativeAOT — no CLI header, has Redhawk symbolsResolve the binary, then use the same file checksResolve the binary path from the running processCoreCLR — loads coreclr.dll
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
DiscoverThe client exposes names and descriptions to the agent.
ActivateYour request or the task context selects the skill and loads its instructions.
Load resourcesReferenced scripts, documentation and assets are used when needed.
Files referenced by the instructions · 3
references/coreclr-dumps.md
references/nativeaot-dumps.md
references/container-dumps.md
These paths are extracted from the text. Check the upstream package to verify the files exist.
Choose the target agent and installation scope, keep referenced package files, then verify the skill appears in the client's catalog.
This skill references supporting files. Retrieve the complete directory from the source; copying SKILL.md alone may leave missing dependencies.
Ask your Agent to install
Copy these instructions to a compatible agent and confirm the target directory matches your client.
Install the agent skill "dump-collect" into my project. The full SKILL.md and official description are at https://zicq.com/en/skills/skl-91d54855be07960e-Dump-Collect.html
Save it as .cursor/skills/dump-collect/SKILL.md or .claude/skills/dump-collect/SKILL.md and keep the frontmatter name and description exactly as-is.
This skill also ships scripts/, references/, or assets/ — fetch the whole folder from https://github.com/dotnet/skills instead of creating only a SKILL.md.
The CLI lets you choose the agent interactively. The default scope is the project; use -g for user scope. Confirm package availability with the discovery command, then use npx skills list to inspect installed skills.
---
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 | grep -q "CorExeMain" && echo "CoreCLR"
# NativeAOT — has Redhawk runtime symbols
strings | grep -q "Rhp" && echo "NativeAOT"
# On macOS/Linux, also try:
nm 2>/dev/null | grep -qi "Rhp" && echo "NativeAOT"
```
**From a binary file (Windows):**
```powershell
# CoreCLR — has a CLI header (IL entry point)
dumpbin /clrheader | Select-String "CLI Header" -Quiet
# NativeAOT — no CLI header, has Redhawk symbols
dumpbin /symbols | Select-String "Rhp" -Quiet
```
**From a running process (Linux):**
```bash
# Resolve the binary, then use the same file checks
BINARY=$(readlink /proc//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 )
strings "$BINARY" | grep -q "CorExeMain" && echo "CoreCLR" || echo "NativeAOT"
```
**From a running process (Windows PowerShell):**
```powershell
# CoreCLR — loads coreclr.dll
(Get-Process -Id ).Modules.ModuleName -contains "coreclr.dll"
# .NET Framework — loads clr.dll (this skill does not apply)
(Get-Process -Id ).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.