skill by
@dotnetConfigure 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.
Permissions
Files
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.
This skill configures and collects crash dumps for modern .NET applications (CoreCLR and NativeAOT) on Linux, macOS, and Windows — including containers.
🚨 Read before starting any workflow.
Install
It’s free, and every skill you add syncs into every AI tool on your computer, instantly.
Version history
lldb for on-demand dump capture on macOS is allowed — it ships with Xcode command-line tools and is not being used for analysis.Ask or determine:
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.
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) |
Follow the instructions in the loaded reference to configure or collect dumps. Always:
DOTNET_DbgEnableMiniDump and related env vars to avoid accumulating dump files.In these kits
More from @dotnet
Works with
Claude, Codex, Cursor & more