Dump Collect

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

Skill
Tool integration
Software development
MIT
No issues found

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

Download the skill as a ZIP:
https://autogineer.com/agent-skills/dotnet/dump-collect/download

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:

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

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_DbgEnableMiniDump and 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, %t format specifiers in DOTNET_DbgMiniDumpName require .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 \
  myapp

Or 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 \
  myapp

Note: 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 \
  myapp

On-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.dmp

Kubernetes

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 size

Pod 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: 10Gi

Alternative: 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: 5Gi

Using 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: 20Gi

On-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.dmp

Deployment-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: 5Gi

Verification

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/*.dmp

Kubernetes:

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

For Kubernetes, use an init container or securityContext.fsGroup:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  fsGroup: 1000    # matches the app user's group

When 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=disable or an appropriate SELinux policy allowing ptrace
AppArmor: Use --security-opt apparmor=unconfined for 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

2026-11-09

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