WSL crash collector writes repeated 58–65 GiB dumps to %TEMP%\wsl-crashes, exhausting C:

[kidclone3]

Bug Description

While running WSL 2.7.10.0, WSL's crash collector wrote repeated, extremely large crash dumps to the Windows host temporary directory:

%LOCALAPPDATA%\Temp\wsl-crashes

The largest single dump was a real, non-sparse 58.24 GiB file. The directory contained 60.10 GiB across 10 dumps. After those dumps were deleted to recover C: space, two new dumps totaling 65.47 GiB appeared shortly afterward.

This can exhaust the host C: drive in one crash burst. Windows Storage classified the data as temporary files but its normal cleanup UI did not offer these dumps for removal.

The dump names implicated both an Electron binary launched from inside the distro and WSLg's Weston process. Example files observed:

wsl-crash-...-_home_<user>_Documents_code_hermes-agent_node_modules_electron_dist_electron-5.dmp  58.24 GiB
wsl-crash-...-_home_<user>_Documents_code_hermes-agent_node_modules_electron_dist_electron-5.dmp   1.15 GiB
wsl-crash-...-_usr_bin_weston-11.dmp                                                                0.31 GiB
wsl-crash-...-_usr_bin_weston-11.dmp                                                                0.31 GiB

The 58.24 GiB dump was created at approximately 2026-08-11 20:13:02 +07:00 and last written at 20:21:54 +07:00.

I removed the dumps because C: was nearly full. Consequently, I cannot attach the original dump files.

Steps to Reproduce

I do not have a deterministic minimal reproducer yet.

Observed workload:

1. Run an Electron-based test/application workload inside an Ubuntu WSL 2 distro with WSLg enabled.
2. Multiple Electron and WSLg/Weston process crashes occur.
3. Inspect %LOCALAPPDATA%\Temp\wsl-crashes.

Expected Behavior

A Linux-process crash may produce diagnostic output, but WSL should not allow repeated crash dumps of roughly 60 GiB each to silently exhaust the host system drive. At minimum, the collector should provide a bounded dump size and/or retention policy, or document a supported configuration for one.

Actual Behavior

• 10 crash dumps consumed 60.10 GiB.
• After cleanup, 2 additional crash dumps consumed 65.47 GiB.
• The largest observed individual dump was 58.24 GiB.
• The largest dump was verified as non-sparse, so the size represented real C: storage consumption.
• Windows Storage cleanup surfaced only about 3.4 GiB of other reclaimable files and did not offer wsl-crashes for cleanup.

Environment

WSL version:      2.7.10.0
Kernel version:   6.18.33.2-2
WSLg version:     1.0.73.2
MSRDC version:    1.2.6676
Windows version:  10.0.26200.8875
Edition:          Windows 10 Pro, 25H2
Distro:           Ubuntu (WSL 2)

Relevant configuration:

# %USERPROFILE%\.wslconfig
[wsl2]
networkingMode=mirrored
memory=48GB
vmIdleTimeout=-1

[experimental]
hostAddressLoopback=true
autoProxy=true

The affected distro routes core handling through WSL's collector:

/proc/sys/kernel/core_pattern
|/wsl-capture-crash %t %E %p %s

/proc/self/coredump_filter
00000033

Additional Context

The incident occurred before upgrading to WSL 2.7.11.0. I have not yet tested it on 2.7.11.0.

This may be distinct from kernel-panic reports such as #41195: I observed Linux-process dump artifacts for Electron and Weston, but I did not establish that the entire WSL VM kernel panicked.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[kidclone3]

Update: recurrence after initial cleanup

The problem recurred before upgrading.

• I verified %LOCALAPPDATA%\Temp\wsl-crashes was empty and C: had approximately 65.3 GiB free.
• Between approximately 22:27 and 22:52 (UTC+07:00), WSL created 7 new .dmp files totaling 64.04 GiB.
• The largest was an Electron dump of 62.97 GiB, created at 2026-08-11 22:43:06 +07:00 and last written at 22:50:30 +07:00. Its filename ended with electron-11.dmp.
• Additional concurrent dumps were for /usr/bin/weston.
• Host C: reached 0 GiB free. The dumps had to be deleted immediately to recover the system drive; C: returned to 64.02 GiB free afterward.

This confirms the behavior is repeatable in the same environment and can exhaust the host system drive in a single incident. The exact minimal workload is still under investigation.

[OneBlue]

Duy Bui (@kidclone3): Unfortunately you're seeing the expected behavior. Crash dump collection is enabled by default.

If you don't want those though you can disable via:

[wsl2]
maxCrashDumpCount=-1

in .wslconfig

[GuskiS]

How can this be expected behaviour? I'm seeing multiple 147GB files.