crash issue

[aldxc]

Windows Version

Microsoft Windows [版本 10.0.26100.4946]

WSL Version

2.7.10

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu22.04

Other Software

No response

Repro Steps

When using WSL, I set .wslconfig with processors=8 and memory=12GB. Then, inside a Docker container running a Linux distribution, I tried to compile LLVM using make -j with no explicit job limit. During this process, because make -j runs without any restriction, it exhausted all allocated memory and swap. At that point, WSL became completely unresponsive—no interactive commands (including wsl --shutdown) worked, and the only way to recover was to restart the whole WSL instance (or reboot Windows). Simultaneously, I observed an extremely high disk read rate, which basically saturated my disk I/O bandwidth. From my research, I understand that when resources are exhausted, WSL enters a severe thrashing state, causing massive disk I/O activity.

Expected Behavior

WSL is unresponsive, and even wsl --shutdown does not terminate it. The only recovery method is to forcibly end the process via Task Manager. Concurrently, I observe massive disk read activity that consumes nearly all available I/O bandwidth.

Actual Behavior

WSL is unresponsive, and even wsl --shutdown does not terminate it. The only recovery method is to forcibly end the process via Task Manager. Concurrently, I observe massive disk read activity that consumes nearly all available I/O bandwidth.

Diagnostic Logs

I noticed the collected_logs_tools script. If you need logs, I can reproduce the issue and collect them.

[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'.

[aldxc]

WslLogs-2026-09-05_00-02-35.tar.gz

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

.wslconfig found
Detected appx version: 2.7.10.0
Found no WSL traces in the logs

[aldxc]

I ran the collect-wsl-logs.ps1 tool as instructed, and it reported: "The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running."

However, I did reproduce the issue while the tool was running. The reason the log contains no traces is that when the problem occurs, WSL becomes completely unresponsive at the kernel/VM level — it cannot accept any commands (including wsl --shutdown), and the only recovery method is to forcibly kill the WSL process via Task Manager.

Since the WSL instance is frozen, the log collection tool (which runs from the Windows side and queries the WSL instance) cannot establish any communication with it, resulting in an empty log file.

In other words, the inability to collect logs is itself a symptom of the problem. The system is so severely thrashing that even diagnostic tools cannot reach the instance.

Reproduction steps:

.wslconfig: memory=4GB, processors=8

Inside a Docker container (Ubuntu 22.04) running on WSL

Compile LLVM using make -j with no explicit job limit

The process exhausts all allocated memory and swap, triggers massive disk I/O, and leaves the entire WSL instance unresponsive

Please let me know if there are alternative ways to capture diagnostic information before the freeze occurs (e.g., ETW traces, performance counters, or crash dumps), and I'll be happy to reproduce it again with those methods enabled.

[chemwolf6922]

Hi aldxc .
The latest pre-release version (2.9.8+) of WSL added cgroup resource reservation for the critical wsl processes. It should keep the critical operations responsive in your situation.

However, that doesn't mean -j will yield usable experience. Other processes could still be killed by the OOM killer and result in system degradation. And the compilation is likely to be very slow or fail due to OOM.

[aldxc]

Hello Feng Wang,
I noticed cgroups mentioned in some forums, which can control resource allocation well. I can use parameters like make -j2 to limit concurrency, but is there a better way to solve this problem? Because even with make -j2, this situation still occurs when resources are insufficient. You mentioned the pre-release version, but for now I still prefer the stable version.I hope you can give me some other good suggestions.
Thank you for your reply.

[chemwolf6922]

Hi aldxc .
The best practice here is still choosing the correct -jN paramter for your system and payload. An OOM could cause the compilation to fail or stuck with or without the pre-released wsl.

[aldxc]

Hello Feng Wang,
So, I'm planning to use version 2.7.10, set up cgroup on my own to keep WSL stable, and then handle the task configuration afterwards. What's your take on this?