Dump Collect
.NET (Microsoft)OfficialPublished by .NET (Microsoft)
- Skill
- Tool integration
- Software development
- MIT
- No issues found
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/dotnet/dump-collect/downloadUnzip 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
lldbfor 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:
Goal: Enable automatic crash dumps, or capture a dump from a running process right now?
Platform: Linux, macOS, or Windows? Running in a container (Docker/Kubernetes)?
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" -QuietFrom 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:
| 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:
Confirm the dump output directory exists and has write permissions before enabling collection.
Report the dump file path back to the user after collection succeeds.
Verify configuration took effect — for env vars, echo them; for OS settings, read them back.
Remind the user to disable automatic dumps if they were enabled temporarily — remove or unset
DOTNET_DbgEnableMiniDumpand related env vars to avoid accumulating dump files.
Files
- ATTRIBUTION.mdAdded by AutoGineer835 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md4.2 KiB
- references/container-dumps.md11.2 KiB
- references/coreclr-dumps.md2.9 KiB
- references/nativeaot-dumps.md8.6 KiB
references/container-dumps.md
Container Crash Dump Collection
| Need | Tool | Runtime | Requires |
|---|---|---|---|
| Automatic dump on crash (CoreCLR) | DOTNET_DbgEnableMiniDump env vars + createdump | CoreCLR | SYS_PTRACE, volume mount |
| Automatic dump on crash (NativeAOT, preferred) | --ulimit core=-1 + core_pattern | NativeAOT | SYS_PTRACE, volume mount |
| Automatic dump on crash (NativeAOT, alternative) | createdump + DOTNET_DbgEnableMiniDump env vars | NativeAOT | SYS_PTRACE, volume mount |
| On-demand from running container | dotnet-dump collect (CoreCLR), gcore (NativeAOT) | Per-runtime | SYS_PTRACE |
| Copy dump out of container | docker cp / kubectl cp | Both | — |
Collecting crash dumps from .NET applications running in Docker or Kubernetes containers requires additional configuration for capabilities, storage, and environment variables.
Note: The
%e,%p,%h,%tformat specifiers inDOTNET_DbgMiniDumpNamerequire .NET 7+. On .NET 6, use a literal path instead.Dump types for
DOTNET_DbgMiniDumpType: 1=Mini, 2=Heap, 3=Triage, 4=Full. Use 4 for maximum diagnostic value. NativeAOT and CoreCLR single-file apps only support full dumps (type 4).
Docker
Required Capability
The SYS_PTRACE capability is required for dotnet-dump collect, createdump, and gcore to attach to processes:
# docker run
docker run --cap-add=SYS_PTRACE -v /tmp/dumps:/dumps myapp
# docker compose# docker-compose.yml
services:
myapp:
image: myapp
cap_add:
- SYS_PTRACE
volumes:
- ./dumps:/dumps
environment:
# CoreCLR automatic crash dumps
DOTNET_DbgEnableMiniDump: "1"
DOTNET_DbgMiniDumpType: "4"
DOTNET_DbgMiniDumpName: "/dumps/%e_%p_%t.dmp"
DOTNET_EnableCrashReport: "1"CoreCLR in Docker
Add environment variables to enable automatic crash dumps. Either in docker run:
docker run --cap-add=SYS_PTRACE \
-v /tmp/dumps:/dumps \
-e DOTNET_DbgEnableMiniDump=1 \
-e DOTNET_DbgMiniDumpType=4 \
-e DOTNET_DbgMiniDumpName="/dumps/%e_%p_%t.dmp" \
-e DOTNET_EnableCrashReport=1 \
myappOr in the Dockerfile (baked into the image):
FROM mcr.microsoft.com/dotnet/aspnet:10.0
# Configure crash dump collection
ENV DOTNET_DbgEnableMiniDump=1
ENV DOTNET_DbgMiniDumpType=4
ENV DOTNET_DbgMiniDumpName="/dumps/%e_%p_%t.dmp"
ENV DOTNET_EnableCrashReport=1
# Create dump directory
RUN mkdir -p /dumps
COPY --from=build /app .
ENTRYPOINT ["dotnet", "myapp.dll"]NativeAOT in Docker
Since NativeAOT only supports full dumps, OS-level core dump mechanisms are the simplest approach — no extra tooling to copy or configure.
Preferred: OS-level core dumps:
docker run --cap-add=SYS_PTRACE \
--ulimit core=-1 \
-v /tmp/dumps:/dumps \
myappNote: You may also need to set the core pattern inside the container. If the host's core_pattern pipes to systemd-coredump, container core dumps may not be written where expected. Override at runtime:
docker run --cap-add=SYS_PTRACE \
--ulimit core=-1 \
--privileged \
-v /tmp/dumps:/dumps \
myapp sh -c 'echo "/dumps/core.%e.%p" > /proc/sys/kernel/core_pattern && exec ./myapp'⚠️ --privileged is needed to write to /proc/sys/kernel/core_pattern. For production, prefer configuring the core pattern on the host instead.
Alternative: Use createdump with DOTNET_DbgEnableMiniDump (same env vars as CoreCLR). Copy createdump next to the app binary in the image:
FROM mcr.microsoft.com/dotnet/runtime-deps:10.0
# Copy createdump from the runtime (match your .NET version)
COPY --from=mcr.microsoft.com/dotnet/runtime:10.0 /usr/share/dotnet/shared/Microsoft.NETCore.App/ /tmp/runtime/
RUN find /tmp/runtime -name createdump -exec cp {} /app/ \; && rm -rf /tmp/runtime/
# Configure crash dump collection
ENV DOTNET_DbgEnableMiniDump=1
ENV DOTNET_DbgMiniDumpType=4
ENV DOTNET_DbgMiniDumpName="/dumps/%e_%p_%t.dmp"
RUN mkdir -p /dumps
COPY --from=build /app .
ENTRYPOINT ["./myapp"]For .NET 11+, use DOTNET_DbgCreateDumpToolPath instead of co-locating:
ENV DOTNET_DbgCreateDumpToolPath=/opt/tools/createdump
ENV DOTNET_DbgEnableMiniDump=1
ENV DOTNET_DbgMiniDumpType=4
ENV DOTNET_DbgMiniDumpName="/dumps/%e_%p_%t.dmp"Run with:
docker run --cap-add=SYS_PTRACE \
-v /tmp/dumps:/dumps \
myappOn-Demand Collection in Docker
# Find the container and process
docker exec <container> dotnet-dump ps # CoreCLR
docker exec <container> sh -c 'ps aux | grep myapp' # NativeAOT
# Collect dump (CoreCLR)
docker exec <container> dotnet-dump collect -p <pid> --output /dumps/myapp.dmp
# Collect dump (NativeAOT — requires gdb/gcore in the image)
docker exec <container> gcore -o /dumps/myapp <pid>
# Copy dump out of container (alternative to volume mount)
docker cp <container>:/dumps/myapp.dmp ./myapp.dmpKubernetes
Pod Spec for CoreCLR
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: myapp
image: myapp:latest
securityContext:
capabilities:
add: ["SYS_PTRACE"]
env:
- name: DOTNET_DbgEnableMiniDump
value: "1"
- name: DOTNET_DbgMiniDumpType
value: "4"
- name: DOTNET_DbgMiniDumpName
value: "/dumps/%e_%p_%t.dmp"
- name: DOTNET_EnableCrashReport
value: "1"
volumeMounts:
- name: dumps
mountPath: /dumps
volumes:
- name: dumps
emptyDir:
sizeLimit: 5Gi # Adjust based on expected dump sizePod Spec for NativeAOT
Preferred: OS-level core dumps (simplest — no extra tooling needed):
apiVersion: v1
kind: Pod
metadata:
name: myapp-nativeaot
spec:
containers:
- name: myapp
image: myapp:latest
securityContext:
capabilities:
add: ["SYS_PTRACE"]
command: ["/bin/sh", "-c"]
args: ["ulimit -c unlimited && exec ./myapp"]
volumeMounts:
- name: dumps
mountPath: /dumps
volumes:
- name: dumps
emptyDir:
sizeLimit: 10GiAlternative: Use createdump (bundled in the image next to the app, or via DOTNET_DbgCreateDumpToolPath on .NET 11+):
apiVersion: v1
kind: Pod
metadata:
name: myapp-nativeaot
spec:
containers:
- name: myapp
image: myapp:latest
securityContext:
capabilities:
add: ["SYS_PTRACE"]
env:
- name: DOTNET_DbgEnableMiniDump
value: "1"
- name: DOTNET_DbgMiniDumpType
value: "4"
- name: DOTNET_DbgMiniDumpName
value: "/dumps/%e_%p_%t.dmp"
# .NET 11+ only — uncomment if createdump is not next to the binary:
# - name: DOTNET_DbgCreateDumpToolPath
# value: "/opt/tools/createdump"
volumeMounts:
- name: dumps
mountPath: /dumps
volumes:
- name: dumps
emptyDir:
sizeLimit: 5GiUsing a Persistent Volume for Dumps
For production, use a PersistentVolumeClaim instead of emptyDir so dumps survive pod restarts:
volumes:
- name: dumps
persistentVolumeClaim:
claimName: dump-storage
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dump-storage
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 20GiOn-Demand Collection in Kubernetes
# Find the pod and process
kubectl exec <pod> -- dotnet-dump ps # CoreCLR
kubectl exec <pod> -- sh -c 'ps aux | grep myapp' # NativeAOT
# Collect dump
kubectl exec <pod> -- dotnet-dump collect -p <pid> --output /dumps/myapp.dmp
# Copy dump out of the pod
kubectl cp <pod>:/dumps/myapp.dmp ./myapp.dmpDeployment-Level Configuration
To apply dump collection to all pods in a Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
template:
spec:
containers:
- name: myapp
image: myapp:latest
securityContext:
capabilities:
add: ["SYS_PTRACE"]
env:
- name: DOTNET_DbgEnableMiniDump
value: "1"
- name: DOTNET_DbgMiniDumpType
value: "4"
- name: DOTNET_DbgMiniDumpName
value: "/dumps/%e_%p_%t.dmp"
volumeMounts:
- name: dumps
mountPath: /dumps
volumes:
- name: dumps
emptyDir:
sizeLimit: 5GiVerification
Docker:
# Check env vars inside the container
docker exec <container> env | grep DOTNET_Dbg
# Check dump directory exists and is writable
docker exec <container> ls -la /dumps/
# Check createdump is available (NativeAOT)
docker exec <container> ls -la /app/createdump 2>/dev/null || echo "createdump not co-located"
# After a crash, check for dump files
docker exec <container> sh -c 'ls -la /dumps/*.dmp' 2>/dev/null
# Or from the host via volume mount:
ls -la /tmp/dumps/*.dmpKubernetes:
# Check env vars
kubectl exec <pod> -- env | grep DOTNET_Dbg
# Check dump directory
kubectl exec <pod> -- ls -la /dumps/
# After a crash, list dumps
kubectl exec <pod> -- sh -c 'ls -la /dumps/*.dmp' 2>/dev/null
# Copy dumps out for inspection
kubectl cp <pod>:/dumps/ ./dumps/Container Considerations
Non-Root Users
If your container runs as a non-root user, ensure the dump directory is writable:
RUN mkdir -p /dumps && chown -R app:app /dumps
USER appFor Kubernetes, use an init container or securityContext.fsGroup:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000 # matches the app user's groupWhen using runAsNonRoot: true, the dump directory must be writable by the non-root user. Use fsGroup to grant group write access to the mounted volume, or set permissions in the Dockerfile.
Alpine / musl-Based Images
createdump, dotnet-dump, and CoreCLR automatic crash dumps all work on the supported .NET Alpine images. No special configuration is needed beyond the standard setup described above.
SELinux / AppArmor
On hosts with SELinux or AppArmor, SYS_PTRACE alone may not be sufficient:
SELinux: The container may need
--security-opt label=disableor an appropriate SELinux policy allowing ptraceAppArmor: Use
--security-opt apparmor=unconfinedfor debugging, or create a custom profile that allows ptrace
⚠️ Disabling security modules is acceptable for debugging but should not be used in production.
Troubleshooting
| Problem | Cause | Fix |
|---|---|---|
dotnet-dump collect fails with "permission denied" | Missing SYS_PTRACE capability | Add SYS_PTRACE to securityContext / cap_add |
| Dump file not created on crash | Dump directory doesn't exist | Ensure /dumps directory exists in the image or init container |
| Core dump goes to wrong location | Host core_pattern overrides container | Configure core_pattern on the host or use --privileged |
| Dump file is 0 bytes | Disk space exhausted | Increase emptyDir.sizeLimit or PVC size |
createdump not found in container | Minimal runtime image | For CoreCLR: use dotnet-dump collect instead. For NativeAOT: copy createdump from the runtime image (see NativeAOT in Docker section) or use the full SDK image |
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).
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dump-collect.zip