WSL stops responding and vmmem spikes CPU to 100% #9592
Comments
|
Thanks for reporting this @xboxfanj. Let's try to figure out which process is taking those resources. Can you please:
|
|
Hi @OneBlue I did just reproduce the issue on 1.1.2, but unfortunately, wsl.exe --debug-shell is currently just freezing whether I run it from PowerShell or cmd. wsl --shutdown also does not do anything. This time, I did not do any major file operations and was only running a few SSH sessions. |
|
Somewhat related issue today. WSL is still responsive, but vmmem is using 7,828 MB of RAM. This time, I was extracting images, which is a multi-gigabyte operation. It's been several hours and it still didn't go down. Earlier today, it was using a large amount of CPU, but that eventually cleared, while RAM is still being used even though it is not allocated in the second output here. During image dumping: Now: |
|
I am experiencing the same symptoms as @xboxfanj on my work computer. Running just a few angular watcher build tasks inside tmux in Ubuntu, wsl2 locks up usually at least once a day. Reproduced both in Ubuntu 22.04 and 20.04. As an additional data point, the problems started when I updated wsl2 and installed a second ubuntu instance. I did not save the information of what wsl2 version I had before the update. |
|
Same high CPU issue today, I am not running much in WSL, but noticed my fans making a lot of noise, checked Task Manager, Vmmem is above 80% CPU. Debug Shell won't load again and WSL is unresponsive. I do agree with @jussih. There was an update I took a few months ago to wsl after being prompted in the console and that does seem to have caused this issue. I also do not know which version I was on before, but if there is history in the registry or a log, I can check. |
|
I updated WSL to the pre-release version |
|
Got it again just now, but again I cannot launch the WSL debug shell to capture the processes @OneBlue |
|
Happened again today, I did not even touch it this time, it was just open in the background from yesterday. |
|
I just resumed my computer after rebooting. I heard my fans get loud. WSL is not running at all, but Vmmem is at 80% CPU. I still can't open the debug shell. |
|
I have not experienced any lockups since updating to 1.1.3.0 around 2 weeks ago. |
|
Today I experienced a full lockup for the first time with wsl 1.1.3.0. Upon entering the room after lunch break I discovered the idling computer blasting the fans at full speed. The lockup is identical to before - neither |
|
I am experiencing the same lockups, with all I have experienced this on two different distros (Debian and openSUSE). I first noticed it when enabling systemd support, but have reproduced the issue with and without it since. |
|
Had the lockup yesterday. Right now, Vmmem is at 23.7% CPU, fans are loud, but it is still responsive. This does not add up anywhere near 23.7% CPU. root@(none) [ ~ ]# ps aux --sort -pcpu |
|
Full lock up again |
|
I've also been regularly experiencing this for the past week or so. Have updated to the latest pre-release with no effect. Similar symptoms to above with shells not responding and WSL version: 1.1.3.0
Kernel version: 5.15.90.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2673 |
|
@rkm thank you for that command! Restarting every time was really annoying but I never found any commands that had the permissions they needed. |
|
It seems to be related to the network of WSL2 or reboot, I observed the following condition: whenever the computer sleeps, the network card is shut down and the WSL2 VM is shut down, and when it wakes up again, WSL2 reboots due to some applications accessing WSL2 (Jetbrains IDE, VSCode in my case), and It doesn't happen every time, but it has happened many times, using the |
Another evidence is that when I use the virtual NIC, change some network settings (restart WIFI while using the virtual NIC to bridge WIFI), it causes WSL2 to restart and the above problem occurs |
Seems to happen when I wake windows from hibernate. WSL then grows gradually less responsive until it is using 100% CPU and is completely unresponsive. |
|
Just had the lockup on 1.2.0. |
|
Had the lockup again on 1.2.3.0. It is definitely more likely after long hibernation (many hours). @OneBlue as I mentioned, I am not able to do anything in wsl when this issue occurs. |
|
Same issue again. @OneBlue how can we help you fix this? |
|
Same lockup on 1.2.5.0. |
|
Having the same symptoms as everyone else on my corporate laptop. I am also unable to run the taskkill command noted above due to an "Access is denied" error. I also concur that this seems to happen after I put the laptop to sleep and wake it up again. |
|
@Mutmansky are you running command prompt as an administrator? |
No, since it's a corporate managed laptop, I don't typically have admin rights. I can request temporary admin rights, if I need to install something new or whatever, but having to do so every time WSL hangs is not a great solution. |
|
Had the same issue PS as admin and |
|
Looks same as #6982 |
|
@craigloewen-msft @OneBlue @pmartincic please give us an update on at least one of these issues. I am not sure if the issues are exactly the same. Sometimes WSL stops responding immediately after resuming and sometimes it takes a while. |
|
Part of the problem is in clearing resources it seems. I just git cloned a kernel repo and 3 GB stayed in RAM. The same happens for large file operations. The same happens for CPUs after suspend. WSL should be able to release resources that are no longer needed, but it does not seem to be able to do so. |
|
Anyone know why this issue seems to only have occurred for some of us in the last few months? WSL2 was working fine for years before. The only common pattern I can ascertain from anecdotal reports from here, reddit etc, is that an IDE such as Jetbrains or VSCode is being used, and resuming from hibernate is involved. For my case, I'm using Jetbrains and frequently hibernating. I'm also on W10 22H2 |
|
@heron1 I don't have an IDE. Even if I don't do anything in WSL, after enough suspends, it seems to get into this state as long as it's open. |
|
I'm getting this issue too. My version info is as follows versions. |
|
The same problem, after hibernate wsl hangs with 100% cpu |
|
I have the same issue. WSL (vmmem) uses 100% CPU (27+ CPU cores at 100% each) after waking up from hibernation. I have had this issue for several years now.
|
|
Same problem here, wsl is using two full cores at 100% after laptop wakes. |
|
For me the issue seems to have gotten worse over time. I have been updating wsl regularly to the preview versions. On rarer occasions vmmem CPU utilization spikes during the day without hibernates. If |
|
Same problem here. As a temporary workaround, I can reduce the affinity of the process to only one core/cpu and at least my CPU and fan can relax a little bit untill I finally reboot. It has been two days in a row with the same issue, and rebooting. Very annoying. Reading the other comments, indeed, my machine was coming out of hibernation, and yes, I was running and IDE (Visual Studio). |
|
I've had this issue on two different machines now: vmmem CPU usage gradually increases until it hits 100% and becomes unresponsive. I hadn't noticed it being associated with sleeping, but I do leave WSL running while sleeping regularly so it might be related. |
|
Not sure if this is resolved - but I am facing the same issue since quite a while. |
|
I'll try and provide as much detail as I can, but I'm not sure how much of this is relevant. Sadly, I'm also affected by this... I see people getting 100% and I raise my own 153% via BTOP (And Task Manager too). In short--WSL2 is leaking CPU cycles and causing the system to become unresponsive if left unchecked. Details & Helpful info:I've tried reducing the number of cores & memory available and makes no difference at all. Using WSL2 Arch distro when this happens, but I note it used to happen a long long time ago also. I've ensured no container services are running inside WSL, and external to WSL as I would assume they get their own 'hard-to-find/spot' daemons in some circumstances and wanted to rule that out. BTOP inside WSL reports practically 0 resource usage across the board (CPU & Memory) so average Linux experience there. Note:I'm using an Arch distro among several others (Though others are rarely used), with all Linux distros (Except Docker's own side distro, the docker-desktop it registers) are on a NON-PRIMARY drive. All my Linux distros exist on my E: drive - I raise that this used to happen a long time ago but hasn't happened in ages. At the time it was different distro and an SSD at the time. I make no use of WSLg, and have it disabled in the config as you can see. I in my .zshrc I have a function that strips almost all Windows path info from the Linux environment, so I'm certain I'm not calling Windows native programs while inside of WSL. The only consistency between literally every single time it spins up for me is using Neovim/nvim. Versions & ConfigsNote:My WSL is set to start in wherever the current terminal is, often Windows ($env:USERPROFILE), which is the only time a cross-filesystem operation occurs. WindowsWindows WSL2 version info:WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.4169Linux/WSL (Arch)/etc/wsl.conf:[boot]
systemd=true
[automount]
enabled = true
options = "metadata"
mountFsTab = true
[interop]
enabled=true
appendWindowsPath=false
[boot]
command = sudo systemctl start [email protected]$env:USERPROFILE\.wslconfig:Hoping such a long standing issue starts getting taken seriously, as it seems Microsoft would prefer we actively move away from their platform as a whole. With tools that are a convenience slowly becoming more of a hindrance, it's a shame to see this happening really... Speaking to friends/colleagues about moving and the majority tend to agree the issues are becoming worse and worse as the software side of Microsoft becomes less important and the 'push stuff out quicker' & 'gather more data' part gets bigger/worse. With some having moved purely from my mentioning of the issues pointing out the fact it's been getting worse and worse, especially in the last couple years. |
Version
Microsoft Windows 10 Version 22H2 (OS Build 19045.2486)
WSL Version
Kernel Version
5.10.16
Distro Version
Ubuntu 20.04
Other Software
No response
Repro Steps
(I believe this happens regardless of if I am working with large files, but it may be more frequent in that case. I have had cases where I am not running anything and it still locks up).
I recently upgraded to WSL 1.1.0 per another GitHub issue and this did not resolve the issue.
Expected Behavior
I expect WSL to respond and not use a high percentage of CPU resources. In the rare case where WSL acts up, wsl --shutdown should stop it.
Actual Behavior
I leave WSL running all the time based on my workload. For years, this worked flawlessly. For the last few months, after a day to a few days up and some suspends and resumes, WSL stops respnding, uses 80+% CPU, wsl --shutdown doesn't work, and I cannot get it to work unless I reboot my PC.
Diagnostic Logs
WslLogs-2023-02-05_17-56-42.zip
The text was updated successfully, but these errors were encountered: