Repository navigation
WSL exits unexpectedly when compiling software. #40458
Description
Windows Version
Microsoft Windows [Version 10.0.26200.8246]
WSL Version
2.6.3.0
Are you using WSL 1 or WSL 2?
- WSL 2
- WSL 1
Kernel Version
Linux version 6.6.87.2-microsoft-standard-WSL2 (root@439a258ad544) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025
Distro Version
Ubuntu 24.04.4
Other Software
Visual Studio 2022
Command Prompt
other wsl instance ( running top)
Repro Steps
Initial Configuration
- Install Ubuntu using the Visual Studio option to "Install WSL For Me" under the Project Menu
- Open a command line after the Installation completes sucessfully.
- sign into root on the VM using the command:
wsl -u root
- Install the Dependencies to build the Vulkan SDK for linux ( Documentation Here: https://vulkan.lunarg.com/doc/sdk/latest/linux/getting_started.html )
apt update
apt upgrade
apt install xz-utils
apt-get install libglm-dev cmake libxcb-dri3-0 libxcb-present0 libpciaccess0 \
libpng-dev libxcb-keysyms1-dev libxcb-dri3-dev libx11-dev g++ gcc \
libwayland-dev libxrandr-dev libxcb-randr0-dev libxcb-ewmh-dev \
git python-is-python3 bison libx11-xcb-dev liblz4-dev libzstd-dev \
ocaml-core ninja-build pkg-config libxml2-dev wayland-protocols python3-jsonschema \
clang-format qtbase5-dev qt6-base-dev
- Create the folder
/opt/vulkansdk/custom_built. - Change the group and file ownership of the folder created in step 5 to allow the non-root wsl user the ability to create/edit files in this path.
- exit out of this session.
- Use Visual Studio to download the Repository https://github.com/kphillisjr/VkSDKBuilder
- Issue the Configuration, and build commands on visual studio for wsl linux. The first build I am doing uses the default configuration for
linux-debug. - use the open command prompt to launch wsl.
- run the command
top
Note: Once the first crash happens it can be reproduced with the following sequence
- open wsl on command line
wsl - run the following sequence.
cd ~/.vs/VkSDKBuilder/out/build/linux-debug
ninja clean
ninja
Expected Behavior
For the build script to complete without crashing wsl.
Actual Behavior
Visual Studio 2022 behavior
The build goes for a while and then eventually stops with no indication that the build actually failed.
wsl directly
The build goes for a while, and then wsl crashes out to the windows command line without any indication that wsl had crashed.
Note 1: Both build methods appear to crash at about the same area.
Note 2: I noticed that a process called VmmemWSL suddenly has a massive increase in disk usage.
Note 3: This bug happened on two different Windows 11 Computers with all updates applied.
Activity
github-actions commentedon May 7, 2026
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:
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 networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce 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 [email protected] 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'.
kphillisjr commentedon May 8, 2026
Here are the request logs. I reproduced the issue twice. The second time I made sure to catch the following error...
WslLogs-2026-05-07_19-22-16.tar.gz
WslLogs-2026-05-07_19-34-23.tar.gz
github-actions commentedon May 8, 2026
Diagnostic information
chemwolf6922 commentedon May 8, 2026
Hi Kenney Phillis Jr. (@kphillisjr) , The dmesg shows an OOM kill. Could you please try increase the amount of memory WSL is allowed to use in .wslconfig or reduce the build parallelism of ninja with the
ninja -j <n>option? Thanks.tophyr commentedon May 8, 2026
This is definitely an OOM, but Feng Wang (@chemwolf6922) it's an error in the WSL Hypervisor layer. It is trivially reproducible:
This is fairly serious: I can DoS the entire WSL system from a misbehaving userspace program.
Recovery is running
wsl --shutdown, and then waiting a sec and restarting. Seems to come back up fine, but the fact that I can break it from within the guest is a big problem.chemwolf6922 commentedon May 8, 2026
Hi Chris Sarbora (@tophyr) , I tried this but could not repro on my machine (the oom-killer correctly saved the system). Could you please share the dmesg while repro this? Thanks.
kphillisjr's dmesg shows a absurdly high oom_score_adj for systemd. Making it the first target for oom-killer.
tophyr commentedon May 8, 2026
oomkillerdoes save the Linux system... what's weird is that WSL itself dies about two minutes later. Note in my trace above that at23:01:37thewsl -ecommand blocked for 32 seconds, before the loop resumed at23:02:09showing a nearly-empty Linux RAM usage.I haven't been able to find any Event Viewer logs that indicate what's happening to WSL in the intervening 81 seconds that ends up in "Catastrophic failure" state. I'd be happy to collect more info for you.
kphillisjr commentedon May 8, 2026
I am actually able to reliably produce the crash on two different computers. I believe that the process VmmemWSL is what is crashing on my system. The only reason I believe this is that this process maxes out my Disk I/O before the WSL instance crashes when I watch the system with task manager running.
Additional System Information
System 1:
System 2:
Configuration System 1
Crashes occur regulary when the file
%userprofile%\.wslconfigis configured for 2GB of Memory. I am able to stop the crashing by updating the file contents to:From:
Configuration System 2
This system lacks the configuration file in system 1.
chemwolf6922 commentedon May 8, 2026
Hi Kenney Phillis Jr. (@kphillisjr) , the crash is caused by the OOM. 2G ram is not near enough for your use case (at least at the default ninja build parallelism). OOM on Linux will cause connection failures like this. In your case, the wsl core port closed due to a failure to allocate a ring buffer in the kernel.
The VmmemWSL is just a view port on Windows to show the overall wsl VM resource usage. It does not actually do anything.
The interesting thing here is why does WSL stuck at that "Catastrophic Failure" state. I'll trying to look in to that.
chemwolf6922 commentedon May 8, 2026
Hi Chris Sarbora (@tophyr), Could you please share the wsl log following instructions here capturing the repro? Thanks. https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-detailed-logs
tophyr commentedon May 8, 2026
Feng Wang (@chemwolf6922) I'll open a new issue; it sounds like my case is different than Kenney Phillis Jr. (@kphillisjr)'s.
chemwolf6922 commentedon May 8, 2026
Kenney Phillis Jr. (@kphillisjr) , The stuck at Catastrophic Failure issue could have been fixed in this PR: #14455. Could you please try out the 2.7.3 pre-release version https://github.com/microsoft/WSL/releases/tag/2.7.3 with the same settings (memory limited to 2GB) to see if wsl still stuck after the compilation failure? Thanks.
I'm also experimenting with reserving memory for critical wsl processes to avoid them break under heavy memory load: https://github.com/microsoft/WSL/tree/user/chemwolf6922/protect-wsl-core-processes-with-memory-cgroup. I'll update here if that goes anywhere.
kphillisjr commentedon May 8, 2026
I am able to get wsl to crash with 8GB available on WSL 2.7.3 with the same script and a few more packages installed... namely...
WslLogs-2026-05-08_13-21-11.tar.gz
NOTE: This is when attempting to build the release build from a clean development tree meaning that I perform the following steps after the packages are installed...
Projectand thendelete cache and reconfigure.github-actions commentedon May 8, 2026
Diagnostic information
chemwolf6922 commentedon May 9, 2026
Hi Kenney Phillis Jr. (@kphillisjr) , I created a build with the memory reservation change: https://github.com/chemwolf6922/build-wsl/actions/runs/25588991182/artifacts/6892119985. It's based on this commit: da600f6.
If possible, could you please try out this build to see if wsl still errors out after the build fails? Thanks. If you see timeout errors instead of catastrophic failure, please wait for several minutes for the compiler processes to die out. And see if wsl is eventually recovered.
Please note this is not a stable build. Thus it may contain other bugs. It's recommended to change back to a release / pre-release version after the test.
kphillisjr commentedon May 12, 2026
The build for commit da600f6 did not have the whole wsl subsystem crash on my system. I am including the log for the build below...
WslLogs-2026-05-12_14-23-24.tar.gz
github-actions commentedon May 12, 2026
Diagnostic information
falghamdi125 commentedon Jun 5, 2026
Since your second system only has 2 GB of RAM for WSL, you can help prevent out of memory errors by allocating more swap space for WSL.
%UserProfile%\.wslconfig:Windows by default allocates swap as 25% of your WSL memory. So in you case, it's only 512gb which is insufficient. Remember large swap files can help prevent WSL from running out of memory. However, if WSL relies heavily on swap, performance may slow down because disk I/O is expensive. it can also increase disk wear over time.
edsonms-sato commentedon Aug 6, 2026
I fixed on my side by using the following settings.json with this wsl configuration (I have 32GB RAM):
[wsl2]
memory=16GB ( only if you have 32gb of RAM. If you have more RAM, increase this)
swap=8GB
localhostForwarding=true
And then I figured out VSCode indexing was consuming a lot of memory which I managed to fix with this settings.json:
{
"chat.disableAIFeatures": true,
"dev.containers.dockerPath": "podman",
"dev.containers.mountWaylandSocket": false
"search.exclude": {
"/node_modules": true,
"/bower_components": true,
"/*.code-search": true,
"/.git": true,
"/dist": true,
"/build": true
},
"files.watcherExclude": {
"/node_modules/": true,
"/dist/": true,
"/build/": true,
"/.git/objects/": true,
"/.git/subtree-cache/": true,
"/.hg/store/": true
},
}