dump-collect

# .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 <binary> | grep -q "CorExeMain" && echo "CoreCLR" # NativeAOT — has Redhawk runtime symbols strings <binary> | grep -q "Rhp" && echo "NativeAOT" # On macOS/Linux, also tr...