dump-collect

Set the DOTNET_DbgEnableMiniDump=1 environment variable along with DOTNET_DbgMiniDumpType and DOTNET_DbgMiniDumpName before launching the app. CoreCLR writes a dump automatically when the process crashes, and the output directory must exist beforehand.

Use dotnet-dump collect -p <pid> for CoreCLR processes after installing the dotnet-dump tool. For NativeAOT processes, use gcore on Linux, lldb with process save-core on macOS, or procdump on Windows.

Check the binary with strings or nm: CoreCLR binaries contain CorExeMain while NativeAOT binaries contain Rhp symbols. For running Windows processes, CoreCLR loads coreclr.dll, which you can check via PowerShell process modules.

Yes, but the container needs the SYS_PTRACE capability and a writable mounted volume for dump output. Add cap_add SYS_PTRACE in Docker or the securityContext capabilities in Kubernetes pod specs, then configure the standard environment variables.

No, this skill only covers enabling and collecting dumps, not analysis. Post-mortem investigation with dotnet-dump analyze, lldb, or windbg is explicitly out of scope, as is .NET Framework process support.

NativeAOT only supports full dumps, so DOTNET_DbgMiniDumpType must be 4, and createdump must sit next to the binary or be referenced via DOTNET_DbgCreateDumpToolPath on .NET 11+. Alternatively, use OS-level core dumps with ulimit -c unlimited and a configured core_pattern.