Analyzing WSL Linux Crashes and Dumps with WinDbg

“WSL dump” can refer to several very different artifacts. A Linux process core records one process and its memory at a point in time. A Linux kernel KDUMP records kernel state after a kernel panic, if a compatible crash-dump path is configured. A VmmemWSL dump is a Windows process dump created from the host-side WSL virtual-machine process. These files answer different questions and are opened with different debugger assumptions.

Start by identifying the failing layer. If one Linux application crashes but the distro still works, capture that process. If the guest kernel panics and reboots, investigate whether a Linux KDUMP exists. If WSL itself hangs, Microsoft’s WSL troubleshooting guide describes creating a dump of VmmemWSL from Task Manager. Do not rename one artifact and assume it is another: an ELF core is not a Windows minidump, and a host process dump is not automatically a Linux guest kernel dump.

The Windows debugger workflow below must be run on Windows. Its Linux-core support requires a sufficiently recent WinDbg, and WSL-specific artifacts cannot be collected or opened on this macOS authoring host.

Capture a Linux process core when one program fails

Microsoft documents a process-level path using GDB inside Linux: find the target process, attach, run generate-core-file, and then open the resulting ELF core in WinDbg. This is useful when the application is still alive but stuck or in a state that must be preserved. A normal crash may also produce a core according to the distro’s core pattern and limits, but those settings vary; do not assume an unexplained core file will appear.

pgrep -af 'my-service --config'
gdb -p 9382

At the GDB prompt, record the thread list and stacks, generate the artifact, then detach or quit deliberately:

(gdb) info threads
(gdb) thread apply all bt full
(gdb) generate-core-file /tmp/my-service.core
(gdb) detach
(gdb) quit

Replace the example PID only after confirming the command line. Attaching can pause a production process while GDB inspects it, so use a maintenance window or a test reproduction when latency and availability matter. Core generation can require substantial free space. Preserve the executable, matching debug symbols, build ID, distro release, and the exact command line; a core without the corresponding binary and symbols can show registers and raw memory but may not provide useful source-level names.

The WSL environment also needs permission to attach to the process, and a process launched under another user may require the appropriate Linux privileges. For a reproducible application crash, prefer reproducing in a disposable distribution and keep the application build identical. Do not change ulimit, core_pattern, package versions, and the workload all at once; that makes it difficult to tell whether the dump path or the original defect changed.

Open an ELF core in WinDbg with matching symbols

Microsoft’s current Linux crash-dump documentation says Linux dump viewing requires WinDbg version 1.2402.24001.0 or later. It supports ELF process cores and DWARF symbols, with a stated limitation that DWARF 5 is not supported. Check the installed debugger version before treating an unsupported file or missing source view as evidence of a broken WSL dump.

Open the .core file in WinDbg, then configure symbols and sources for the exact application build. The documentation’s WSL example uses a Windows path to the source and symbol tree, because the same user directory can be reached from Windows through the WSL filesystem share:

.sympath C:\Users\Example\src\my-service\build\symbols
.srcpath C:\Users\Example\src\my-service
.reload

If symbols are published to a supported DebugInfoD server, Microsoft documents a DebugInfoD* symbol-path form. Use the exact symbol server and access policy for the application, then verify the debugger actually loaded the expected build IDs. A readable function name is not enough if the symbols came from a different binary revision.

For Linux core files, Windows-specific extensions that expect Windows process structures do not apply. Start with the dump-format and process-state commands supported by WinDbg for ELF, inspect the crashing thread and its stack, and correlate addresses with the matching symbols. If a visualizer produces confusing output, check the loaded NatVis scripts; Microsoft documents unloading the default STL visualizer and loading the Linux-oriented gstl.natvis file. Avoid copying Windows kernel-debugging commands into a Linux user-core session merely because they have similar names.

Treat kernel KDUMPs as a separate capture path

A Linux kernel KDUMP is created by Linux crash-dump infrastructure, not by gdb -p and not by exporting a WSL distribution. Microsoft’s Linux crash-dump guidance describes enabling Kdump and notes that its debugger support accepts ZLIB-compressed KDUMP files; LZO and Snappy-compressed KDUMPs are not supported by that workflow. It also shows Linux-specific extensions such as !vmcoreinfo and !kdumpdescs for kernel dumps.

Do not promise that every WSL kernel or Windows installation has Kdump ready. Kdump requires a functioning capture kernel and appropriate kernel configuration, memory reservation, initramfs, storage, and distro tooling. WSL’s managed kernel and VM lifecycle impose additional constraints. Confirm that the exact WSL kernel exposes the required facilities and that the dump target remains available at crash time before designing an incident runbook around it. A systemctl status kdump check is meaningful only if the distro actually uses systemd and the unit exists; it is not a universal WSL test.

When a KDUMP exists, preserve the exact kernel image, debug symbols, release/build ID, compression type, and VMCOREINFO along with the dump. A symbol mismatch can make stack frames misleading even if WinDbg opens the file successfully. If the file uses an unsupported compression codec, convert it only with a tool and procedure that preserve the artifact; do not edit the original capture in place.

Capture a WSL platform hang without confusing it for a Linux core

Microsoft’s WSL troubleshooting guide describes creating a dump by opening Task Manager, selecting the VmmemWSL process, and choosing Create memory dump file. This captures the host-side process state for a WSL hang investigation. It is not a per-process ELF core from a distro, and it is not the same as a kernel KDUMP produced from inside Linux. Preserve the dump alongside the matching WSL logs and the reproduction timeline so the platform team can correlate the state.

The ETW trace and memory dump answer complementary questions. A trace can show which WSL components and transitions occurred over time; a process dump preserves in-memory state at the capture instant. Collect a trace around one bounded reproduction first when the system remains responsive. If a dump is needed, follow Microsoft’s current troubleshooting instructions and capture the WSL package version, Windows build, distribution state, networking mode, and exact trigger.

Treat all dumps as high-volume diagnostic data. They can contain environment variables, command arguments, file contents, tokens, and other process memory. Store them in an access-controlled location, define a short retention period, and remove them when no longer required. Redact identifiers from tickets where possible, but never alter the original evidence before its hash and capture metadata have been recorded.

A repeatable postmortem checklist

For each incident, answer these questions before opening a debugger: which process or layer failed; what artifact format was captured; which exact WSL and Windows versions were running; which binary, kernel, and symbols match the artifact; and what changed immediately before the failure? Copy the original file to a read-only evidence location, record its size and SHA-256, and analyze a working copy.

Test each collection path on a disposable WSL installation. For process cores, prove that GDB can attach, all-thread stacks are captured, the file opens in WinDbg, and the expected build symbols resolve. For kernel KDUMPs, confirm the target kernel actually supports the configured path and that the compression is supported. For a VmmemWSL dump, rehearse the host capture workflow without crashing Windows and ensure the resulting file is clearly labeled as a Windows process artifact.

If a hang cannot be reproduced or the only available artifact is a WSL ETW trace, preserve that fact instead of inventing a core dump. The right diagnostic artifact narrows the failure layer; an artifact with the wrong format or symbols can add noise. By keeping Linux process cores, Linux kernel dumps, and host-side WSL dumps separate, an incident report can state exactly what the evidence proves and what remains unknown.

Related:

Sources: