AutoGineer
Generated banner for Dump Collect
Generated logo for Dump Collect

Dump Collect

.NET (Microsoft)OfficialPublished by .NET (Microsoft)

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

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.
— the description by .NET (Microsoft)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides instructions for configuring and collecting crash dumps from modern .NET applications. It covers both automatic dump generation via environment variables and on-demand collection from running processes. The scope is strictly limited to the collection phase, ensuring the environment is prepared to capture diagnostic data when a crash occurs or when a snapshot is needed.

What it does

  • Enables automatic crash dump generation for CoreCLR and NativeAOT applications.
  • Provides commands to capture memory dumps from running .NET processes.
  • Configures dump collection settings for applications running in containerized environments.
  • Identifies whether an application is running on CoreCLR or NativeAOT.
  • Verifies that dump output directories are correctly configured and writable.

When to use it

  • When you need to capture a memory dump for a .NET application that is crashing.
  • When you need to take a snapshot of a running .NET process for diagnostic purposes.
  • When configuring a containerized .NET application to persist crash data.
  • When you need to determine the runtime type of a .NET binary or process.

Advantages

  • Supports multiple platforms including Linux, macOS, and Windows.
  • Provides specific guidance for containerized environments.
  • Offers flexible dump types ranging from minimal stack traces to full process memory.
  • Includes verification steps to ensure configuration is active.

Usage examples

“How do I enable automatic crash dumps for my CoreCLR application?”
The agent will guide you to set specific environment variables like DOTNET_DbgEnableMiniDump and DOTNET_DbgMiniDumpType before launching your application.
“How can I capture a dump from a running .NET process?”
The agent will instruct you to use the dotnet-dump collect command, specifying the process ID and desired dump type.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/dotnet/dump-collect/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip dump-collect.zip -d .agents/skills

Documentation by .NET (Microsoft)

.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):

# 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):

# 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):

# 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):

# 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):

# 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:

ScenarioReference
CoreCLR app (any platform)references/coreclr-dumps.md
NativeAOT app (any platform)references/nativeaot-dumps.md
Any app in Docker or Kubernetesreferences/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.

Files

references/nativeaot-dumps.md

NativeAOT Crash Dump Collection

NeedToolPlatforms
Automatic dump on crash (preferred)OS-level core dumps (ulimit, core_pattern, WER)All
Automatic dump on crash (alternative)createdump + DOTNET_DbgEnableMiniDump env varsAll
On-demand from running processgcore (Linux), lldb (macOS), procdump (Windows)Per-platform

NativeAOT applications are native executables. Since NativeAOT only supports full dumps, OS-level core dump mechanisms are the simplest approach — no extra tooling to copy or configure.

Note: NativeAOT only supports full dumps. DOTNET_DbgMiniDumpType must be set to 4 (Full).

OS-Level Core Dumps (Preferred)

Linux

Option A: Direct core dumps (simplest)

# Enable core dumps for the current shell session
ulimit -c unlimited

# Set the core dump output pattern (system-wide, requires root)
echo '/tmp/dumps/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern

# Make persistent across reboots — add to /etc/sysctl.conf:
# kernel.core_pattern = /tmp/dumps/core.%e.%p.%t

# Ensure dump directory exists
mkdir -p /tmp/dumps

Note: ulimit only applies to processes started in the current shell session. For an already-running process, use on-demand collection with gcore (see On-Demand Dump Collection below).

Format specifiers for core_pattern:

SpecMeaning
%pPID
%eExecutable name (first 15 chars)
%tUnix timestamp
%hHostname
%uUID

Option B: systemd-coredump (systemd systems)

Many Linux distributions pipe core dumps to systemd-coredump by default. Check:

cat /proc/sys/kernel/core_pattern
# If it shows: |/usr/lib/systemd/systemd-coredump ...
# Then systemd-coredump is already handling dumps.

Using coredumpctl:

# List collected dumps
coredumpctl list

# Show details of the most recent dump
coredumpctl info

# Export a dump to a file
coredumpctl dump -o /tmp/dumps/myapp.core

# Filter by executable name
coredumpctl list myapp
coredumpctl dump myapp -o /tmp/dumps/myapp.core

Configure systemd-coredump storage in /etc/systemd/coredump.conf:

[Coredump]
Storage=external
MaxUse=2G
ProcessSizeMax=8G
On-Demand Dump Collection
# Using gcore (from gdb package)
gcore -o /tmp/dumps/myapp <pid>

macOS

Automatic Crash Dumps
# Enable core dumps for the current shell session
ulimit -c unlimited

# Core dumps go to /cores/core.<pid>
# Ensure the directory exists and is writable
sudo mkdir -p /cores
sudo chmod 1777 /cores

# Verify the setting
ulimit -c  # Should print "unlimited"

Notes:

  • macOS also generates .crash reports in ~/Library/Logs/DiagnosticReports/ automatically — these are text-based crash logs, not full memory dumps.

  • On Apple Silicon, core dumps may require SIP (System Integrity Protection) adjustments for certain processes.

Retrieving Dumps from an Already-Crashed Process

If the app has already crashed and core dumps were enabled (ulimit -c unlimited was set):

# Check /cores/ for core dumps
ls -la /cores/core.*

# Check macOS crash reports (always generated, even without ulimit)
ls -la ~/Library/Logs/DiagnosticReports/*.crash
# Or on newer macOS:
ls -la ~/Library/Logs/DiagnosticReports/*.ips

If core dumps were not enabled before the crash, the core dump is lost. The .crash/.ips report in DiagnosticReports is the only artifact — it contains the stack trace and crash reason but not full memory.

On-Demand Dump Collection
# Using lldb (ships with Xcode command-line tools)
lldb -p <pid> -o "process save-core /tmp/dumps/myapp.core" -o "quit"

# Using gcore if gdb is installed (via Homebrew)
gcore -o /tmp/dumps/myapp <pid>

Windows

Automatic Crash Dumps (Windows Error Reporting)

WER is a Windows OS-level mechanism — it uses its own DumpType values (0=Custom, 1=Mini, 2=Full) which are separate from the DOTNET_DbgMiniDumpType environment variable. WER works for any process, including NativeAOT apps without createdump.

Configure via the registry. Run in an elevated PowerShell:

# Enable local dumps for a specific application
$appName = "myapp.exe"
$dumpPath = "C:\dumps"
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\$appName"

New-Item -Path $regPath -Force
New-ItemProperty -Path $regPath -Name "DumpFolder" -Value $dumpPath -PropertyType ExpandString -Force
New-ItemProperty -Path $regPath -Name "DumpCount" -Value 10 -PropertyType DWord -Force
New-ItemProperty -Path $regPath -Name "DumpType" -Value 2 -PropertyType DWord -Force
# DumpType: 0=Custom, 1=Mini, 2=Full

# Ensure dump directory exists
New-Item -Path $dumpPath -ItemType Directory -Force

To enable for ALL applications (not just one), use the parent key:

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
New-Item -Path $regPath -Force
New-ItemProperty -Path $regPath -Name "DumpFolder" -Value "C:\dumps" -PropertyType ExpandString -Force
New-ItemProperty -Path $regPath -Name "DumpType" -Value 2 -PropertyType DWord -Force
On-Demand Dump Collection

Using procdump (recommended — download from Sysinternals):

# Download procdump (one-time)
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Procdump.zip" -OutFile "$env:TEMP\Procdump.zip"
Expand-Archive "$env:TEMP\Procdump.zip" -DestinationPath "$env:TEMP\Procdump" -Force

# Capture a full dump
& "$env:TEMP\Procdump\procdump.exe" -ma <pid> C:\dumps\myapp.dmp

# Capture on crash (waits for an unhandled exception)
& "$env:TEMP\Procdump\procdump.exe" -ma -e -w <processname> C:\dumps\myapp.dmp

Using Task Manager:

  1. Open Task Manager → Details tab

  2. Right-click the process → "Create memory dump file"

  3. Note the output path shown in the dialog

Alternative: Using createdump with DOTNET_DbgEnableMiniDump

NativeAOT apps also support the DOTNET_DbgEnableMiniDump environment variables if createdump is available. This gives you the same env-var-based workflow as CoreCLR, but requires copying createdump to the right location.

If createdump is placed next to the application binary:

export DOTNET_DbgEnableMiniDump=1
export DOTNET_DbgMiniDumpType=4
export DOTNET_DbgMiniDumpName="/tmp/dumps/%e_%p_%t.dmp"
export DOTNET_EnableCrashReport=1

Note: The %e, %p, %h, %t format specifiers in DOTNET_DbgMiniDumpName require .NET 7+. On .NET 6, use a literal path instead.

Setup: Copy createdump from the .NET runtime into the same directory as your published NativeAOT binary:

# Linux
cp /usr/share/dotnet/shared/Microsoft.NETCore.App/<version>/createdump ./publish/

# macOS
cp /usr/local/share/dotnet/shared/Microsoft.NETCore.App/<version>/createdump ./publish/

# Windows (PowerShell)
Copy-Item "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\<version>\createdump.exe" .\publish\

If the .NET runtime is not installed (fully self-contained deployment), extract createdump from the runtime Docker image or NuGet package:

# Extract from Docker runtime image
docker run --rm -v "$(pwd)/publish:/out" mcr.microsoft.com/dotnet/runtime:10.0 \
  sh -c 'cp /usr/share/dotnet/shared/Microsoft.NETCore.App/*/createdump /out/'
.NET 11+: DOTNET_DbgCreateDumpToolPath

Starting with .NET 11, you can point to createdump at any location instead of requiring it next to the binary:

export DOTNET_DbgCreateDumpToolPath=/opt/tools/createdump
export DOTNET_DbgEnableMiniDump=1
export DOTNET_DbgMiniDumpType=4
export DOTNET_DbgMiniDumpName="/tmp/dumps/%e_%p_%t.dmp"

This is especially useful in containers where you can install createdump once in a shared location.

Verification

When using OS-level core dumps
# Linux — check core_pattern and ulimit
cat /proc/sys/kernel/core_pattern
ulimit -c

# macOS — check ulimit and /cores/
ulimit -c
ls -la /cores/

# Linux (systemd) — check for recent dumps
coredumpctl list --no-pager | tail -5
# Windows — check WER registry
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" -ErrorAction SilentlyContinue
Get-ChildItem "C:\dumps" -ErrorAction SilentlyContinue
When using createdump + DOTNET_DbgEnableMiniDump
# Verify env vars are set
env | grep DOTNET_Dbg
env | grep DOTNET_EnableCrashReport

# Verify createdump is next to the binary (or at DOTNET_DbgCreateDumpToolPath)
ls -la ./createdump        # co-located
# or: ls -la $DOTNET_DbgCreateDumpToolPath   # .NET 11+

# Verify dump directory exists
ls -la /tmp/dumps/

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
.NET (Microsoft)
Publisher
.NET (Microsoft) (Official)
Source
dotnet/skills · plugins/dotnet-diag/skills/dump-collect · commit 96c3d68
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by .NET (Microsoft) or .NET (Microsoft).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dump-collect.zip