All WSL commands hang (including wsl --shutdown) but WSL is constantly using 30-40% CPU

Version
Microsoft Windows [Version 10.0.22621.160]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 20.04
Other Software
No response
Repro Steps
This mostly seems to be happening when the device wakes from sleep - after a system restart, I can access the WSL distro as expected

Start a WSL distro (Ubuntu 20.04)
See it hang
Try to do a wsl --shutdown
See that hang as well

Expected Behavior

Start a WSL distro (Ubuntu 20.04)
The command line should open

Actual Behavior

Start a WSL distro (Ubuntu 20.04)
The terminal hangs completely (see screenshot above)

Diagnostic Logs
Feedback Hub logs: https://aka.ms/AAh9fcl

I have this issue as well. Killing the WSL process from taskmanager recovers, but it does it again. Especially (but not only) after it comes back from sleep.

Looks like something is wrong with your trace, could you please collect a trace using these instructions?
/logs

Could you also share the output of wsl.exe dmesg?
Thanks!

I'm not the original poster, but I'm having a similar issue: every wsl command hangs (including wsl --shutdown), this causes problems with Docker, but because of the issues with WSL I can't even reinstall Docker itself (I initially thought it was a Docker issue but everything seems to point back to WSL).
wsl.exe dmesg also hangs so I can't post its output.
I attached the logs from collect-wsl-logs.ps1:
WslLogs-2022-08-25_08-34-21.zip

Same here; this just started happening in the last few days; Please re-open this MSFT!

Same here. Need to terminate the process from task manager. This issue started after updated WSL to the Store version.

This should not have been closed.
Happens often when attempting to switch folders using VSCode. Hangs -- generally just reboot to get back to working again for a while.

Please reopen, this issue should not have been closed. This happens all the time, usually after waking the computer from sleep. Usually a simple wsl --shutdown worked after a ~30s wait, but today even this method failed as all wsl commands hang indefinitely.
This problem is really frustrating as it forces me to restart Docker and all containers, as well as my IDE, which with large projects can take some time.

Please reopen, this issue should not have been closed. This happens all the time, usually after waking the computer from sleep. Usually a simple wsl --shutdown worked after a ~30s wait, but today even this method failed as all wsl commands hang indefinitely. I need to go into task manager and shut down vmwp.exe, as otherwise the vmmem process persists even if I kill all wsl processes manually, and the wsl commands hang anyways.
This problem is really frustrating as it forces me to restart Docker and all containers, as well as my IDE, which with large projects can take some time.

I was literally about to comment the same thing! This issues has been driving me CRAZY!!!
My wsl version is:
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.42
MSRDC version: 1.2.3401
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.978

Please can we reopen and address this?

Please reopen, this issue should not have been closed. This happens all the time, usually after waking the computer from sleep. Usually a simple wsl --shutdown worked after a ~30s wait, but today even this method failed as all wsl commands hang indefinitely. I need to go into task manager and shut down vmwp.exe, as otherwise the vmmem process persists even if I kill all wsl processes manually, and the wsl commands hang anyways.
This problem is really frustrating as it forces me to restart Docker and all containers, as well as my IDE, which with large projects can take some time.

What's worse, if this happens and I forget to close my IDE before terminating WSL, when I reopen the project everything needs to be reindexed. While the entire restart process takes seconds to do and I could live with this inconvenience, indexing can take minutes, which is not inconvenient - it's infuriating. It is simply unacceptable that this issue persists and I'm absolutely blown away that this seems to be ignored on purpose.

Same issue here.  After coming back from sleep Vmmem brings CPU usage to 100%
wsl --shutdown hangs. Happened 3 times in a row, reboot helps.
Tried killing vmwp.exe but it crashed the OS.
WSL version: <IP_ADDRESS> Kernel version: <IP_ADDRESS> WSLg version: 1.0.42 MSRDC version: 1.2.3401 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.22000.978

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

ERROR: The process "wslservice.exe" not found

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

This worked for me. Thanks a lot! Previously I would do a hard reset.

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

ERROR: The process "wslservice.exe" not found

did you start powershell as admin?

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

ERROR: The process "wslservice.exe" not found

did you start powershell as admin?

yes

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

ERROR: The process "wslservice.exe" not found

This workaround doesn't work for me either but wsl --shutdown does (taking a minute or so to complete)

@benhillis

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-open it.
Thank you!
This is some kind of joke, right?

Facing same issues, Couldn't end process (vmmem) from task manager, it says access denied, also powershell command to taskkill also says process not found.

+1 this issue occurs for me on a new SP9 SQ3 on 22H2 22621.755 in debian bullseye on WSL2 with the systemctl flag enabled in wslconfig.
WSL hangs when I stop a docker container. I then need to restart wsl but wsl --shutdown hangs.
only rebooting or taskkill /f /im wslservice.exe seems to fix it.
Issue should not be closed @craigloewen-msft hello friend can you help us? If there's anything I can do to share more info on how to reproduce please let me know. Thanks and big shoutout to you folks working on WSL, it TOTALLY ROCKS <3

To all those affected here, as this is already closed.
I can't reproduce on my work laptop, but can reproduce on both my weak, 'personal' laptops.
Work machine has 64GB Ram and personal laptops have 16GB (Yeah, I know).
Worse when multiple instances of vscode are running under WSL. If everyone here has low-ish memory, this could be the culprit.

Hi folks, reopening this so it can be visible to the WSL team. It was closed automatically since we didn't get any feedback from the original author. Thanks for flagging us on it!

PLEASE FIX WHATEVER IS CAUSING THIS!!! There are literally DOZENS of threads online about this issue, including several on this GitHub repo! All was good in Win10, now WSL goes zombie after a sleep/hybernate and it is not even clear how to bring it back without rebooting the WHOLE SYSTEM.

Just for the record, this is still very much an issue on Windows 10 as well, as a matter of fact, it has been there since the release of WSL1.
The fact that this issue still isn't being addressed, well...                ...actually fits perfectly in line with all other problems with Microsoft products not being fixed.
This is not the fault of the WSL team though. It's probably due to most of Microsoft's developers working on how to force MS Edge to be the default browser and making sure you can't change that, or, developing an algorithm to reboot your PC at the worst time possible to install updates.
Anywho, keep up the good work guys! 😃

@fayora @niekvb Hey. The team here is doing a wonderful job IMO adding updates and addressing issues in WSL. They've been kind enough to re-open this issue and I'm sure they'll prioritize and get to this issue too when they have time. As developers ourselves I'm sure we can all relate!

@Macmee. The team has indeed been doing a wonderful job creating WSL, but this doesn't mean that the focus is always on solving the right issues. You can't deny that there are issues that have never been addressed. Or that, within Microsoft, there's a lot of people working on the most ridiculous stuff like putting games in MS Teams or the things mentioned above while still, after 7 years of Windows 10, my start menu crashed as soon as I type a single character, or that my €2000,- Surface device's network card crashes once every 10-30 minutes.
All those things together cause this frustration here, so consider this message to be not for the WSL team, but for MS.
As consumers of software, I'm sure we can all relate 😉
</rant>

@craigloewen-msft
What information can the community provide to assist in identifying the root cause?

To all those affected here, as this is already closed.
I can't reproduce on my work laptop, but can reproduce on both my weak, 'personal' laptops.
Work machine has 64GB Ram and personal laptops have 16GB (Yeah, I know).
Worse when multiple instances of vscode are running under WSL. If everyone here has low-ish memory, this could be the culprit.

I am having the issue regardless the availability of RAM, currently having this issue non-stop on a Lenovo T14s with 48GB of RAM and gen 12 i7-1280P CPU. I do not expect that being underpowered is the root of this issue...

I'm not the original poster, but I'm having a similar issue: every wsl command hangs (including wsl --shutdown), I can't even close it in Task manager most of the time since it causes that to hang too. My only option would be to restart my computer, which causes me to lose progress. Please fix soon, as this is causing me to lose work.

I've just had some success after completely removing WSL & Linux distros, and then installing everything from the windows store (instead of using command line). Been working for 2 days now, including going to standby five times.

@LouisPhilippe Can you confirm (or deny :D ) using Docker Desktop on that machine?

Please reopen, this issue should not have been closed. This happens all the time, usually after waking the computer from sleep. Usually a simple wsl --shutdown worked after a ~30s wait, but today even this method failed as all wsl commands hang indefinitely. I need to go into task manager and shut down vmwp.exe, as otherwise the vmmem process persists even if I kill all wsl processes manually, and the wsl commands hang anyways.
This problem is really frustrating as it forces me to restart Docker and all containers, as well as my IDE, which with large projects can take some time.

This happens to me on my Surface Pro X with an SQ2 cput and 16GB. Just like you said, it happens after returning from sleep.

I've just had some success after completely removing WSL & Linux distros, and then installing everything from the windows store (instead of using command line). Been working for 2 days now, including going to standby five times. Specifically installing ubuntu from the windows store instead of command line seems to be the main difference.

I've had the issue happen to me while on a machine that only ever had WSL installed through the windows store, so don't get your hopes up too much.

I've just had some success after completely removing WSL & Linux distros, and then installing everything from the windows store (instead of using command line). Been working for 2 days now, including going to standby five times. Specifically installing ubuntu from the windows store instead of command line seems to be the main difference.

I've had the issue happen to me while on a machine that only ever had WSL installed through the windows store, so don't get your hopes up too much.

I stand corrected indeed, disconnected from my docking station and everything again grinds to a halt...

@LouisPhilippe Can you confirm (or deny :D ) using Docker Desktop on that machine?

I was not (yet) using Docker Desktop, but as mentioned above the problem appeared again after disconnecting from my docking station...

I've just had some success after completely removing WSL & Linux distros, and then installing everything from the windows store (instead of using command line). Been working for 2 days now, including going to standby five times. Specifically installing ubuntu from the windows store instead of command line seems to be the main difference.

One workaround/change that's kept Ubuntu up and running for me fior a few days - under app settings for Ubuntu, setting "Let this app run in background" to Always

I'm having all my foreground services hang and can't control-c to sigint. Have to do wsl --shutdown to get a prompt again. But doing this blue screens sometimes just did it before. I've changed to accept auto updating WSL via windows updates and I updated WSL twice recently.

Related: https://stackoverflow.com/q/70567543/100836

Having the same issue. Quite annoying as it slows down all other workloads.

wsl --shutdown

Is the only way and have to setup prompts again. This caused me two blue screens so far though.

Stop closing this.

I still have the problem but I've realized Microsoft has no interest in actually making wsl usable. They just keep closing it.

If I go in to task manager and end it it fixes it.  But as it stands now wsl is an 8nteresting toy but not actually useful for anything.

A sigint seems to take minutes to close the process. I don't see high resource issue while its hanging. It was after a windows update recently

@craigloewen-msft could you please reopen? I'm the author of this issue but not running into it myself anymore. Looks like some folks are still experiencing this. I can't seem to reopen myself. Thanks!

For me the CPU usage for vmmem is more like 90% when this occurs. Seems to be related to something like network changes or docking station connect/disconnect or laptop sleep.

Same issue. Fixed by taskkill /f /im wslservice.exe
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.900

You just need to do
wsl --shutdown

Would be nice, if that would work, tho
It does not, however as was referenced by multiple people and I can confirm that as well.

The only thing that works if it happens was mentioned here: https://github.com/microsoft/WSL/issues/8529#issuecomment-1263463528

Unfortunately the workaround that requires admin is not helpful for users without admin privileges. Need to reboot.

Upgrading to the latest Windows (Version 10.0.22621 Build 22621) seemed to made the problem go away for me.

How to fix this issue?

I'm having a similar (the same?) Issue. WSL execution Stuck, but I have ~0 CPU usage, and cannot use wsl --shutdown. Please reopen and do not  automatically close after 7 days.

Similar issue, in my case this happens 100% of time when waking up the computer from sleep. The only solution which works is:
taskkill /f /im wslservice.exe .
Docker Desktop then prompts me to restart it.
It's really annoying as I have to reopen all my console windows and VS Code.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22623.1037
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

Happening quite often recently after starting to use IntelliJ Remote Development with WSL

taskkill /f /im wslservice.exe

helped

This started happening to me after upgrading WSL to the Microsoft Store version.
Interestingly, when the problem occurs, both of my distributions (Ubuntu and Debian) hang and CPU usage goes to 80-90%.
The only way to (temporarily) solve the problem is to open a PowerShell shell as administrator and use taskkill /f /im wslservice.exe.

Same issue here. Using WSL2...
wsl --shutdown hangs as does any other wsl command.
taskkill /f /im wslservice.exe results in ERROR: The process "wslservice.exe" not found.
How to properly force kill/restart WSL in this situation without rebooting?

I can confirm that this issue also haunts me. This occurs whenever my laptop goes to sleep.
Suspending the WSL does not help. Only killing it with taskkill /f /im wslservice.exe helps until the next system wake-up.
I'm using Docker, so I must restart a docker service.

Force LxssManager service to stop. Get the PID from Task Manager and execute the command below in PS (Admin).
wmic process where "processid=<PID>" delete

Could you also share the output of wsl.exe dmesg?
Thanks!

All commands hang, including wsl dmesg

I've been having the same issue;  in my case, I managed to solve it by running "wsl --shutdown"  (which hung), and then restarting docker desktop from the task tray.

Yep, all commands hang, including wsl dmesg. Please fix this once and for all, I have work unaccessible within wsl.

Since this issue is closed, it may not receive much attention from from the maintainers. If there is someone who can reproduce this issue and is willing to keep interacting with the ticket to keep it open, it might make sense to file a new issue (not sure if this is best advice but what else can we do?). You can reference this ticket in the new one...

@craigloewen-msft Could you please reopen this?

This looks like a follow-up of the same issue that is currently open.
https://github.com/microsoft/WSL/issues/9429

As a palliative solution. I managed by removing Docker Desktop and WSL installation in Windows Features, then installing all again. Of course don't forgot to make a backup of the .docker folder

I put my PC into sleep every night so here i am.

I also had this issue on Windows 11. Using the taskkill command helped.

Day or two ago the issue started.
each time laptop return from sleep WSL terminals are closed.
new terminals are not starting.
wsl --shutdown is not working.
taskkil work some times .. at some point i have to restart to fix the issue.
biggest issue is that i am using recommended very low sleep / hibernate timeouts to save battery as suggested by windows 11 itself both on battery and AC so .. each quick talk with someone lead to WSL kill and open everything again.

You probably have LxssManager service stuck at stopping state like me and only Windows restart helps.
What I did to make WSL2 and Docker usable on Windows 10 (latest) on a daily basis, since I cannot work without minikube cluster running in Docker, is I always stop containers in Docker before I put my laptop to sleep. I also use Ubuntu 18.04 for WSL2 purposes. I have .wslconfig set up to restrict both swap and memory to bare minimum I need to run a minikube cluster, because WSL2 will drain every single bit of RAM you allow it to. And I also use Ubuntu script to clear swap and ram that I trigger from time to time over bash to release excessive ram usage by vmmem process.
I know it's not a proper solution, but a workaround, but I cannot wait for something that doesn't exist, need to make a buck, after all. I have been testing this approach for around 2 weeks now and it hasn't failed on me so far and I never shut down my business laptop, it usually runs out of battery during weekend breaks, tho. So when I launch my laptop, I start docker container(-s), re-start minikube cluster on it, occasionally run Ubuntu clean up script and I'm good to go. Not a single WSL2 hang so far.
I have been trying to find a better/proper solution for like 2 days, no go. Everyone just says restart wsl or restart windows, as if that was a viable solution for software developers.

Experienced the same issue here with wsl --shutdown hanging and vmmemwsl with high CPU usage, all happening after a sleep of my laptop. A windows restart didn't help me.

Same problem, access denied when trying to kill the process. I went to Services-tab in task manager, and stopped the "WsLService", the service auto-restarts but the process VmmemWSL is gone.
All good until it just happens again...?

I have a system with a WSL 1 system I ssh into, and a WSL 2 VM. I switch to the latter by running cmd in the former, then wsl -d Debian under CMD.
The latter recently has started to hang, the same way as described here. How can I fix that without losing the sshd on the WSL 1 system?

I just updated Docker, might have been the issue since the release notes mentioned WSL restart issues being resolved. Haven't put this to the test yet though.

davidsr2r dixit:

I just updated Docker, might have been the issue

Not here, not using Docker.

It came back for me :/

Also having this issue:

High vmem CPU (80%) & Memory (40%) Usage
wsl --shutdown in admin powershell hangs
even wsl -l  hangs

I've been experiencing the same issue for a whle now. I keep checking different threads to see if there's an actual fix and not just killing wslservice.exe.
What do we need to do to even get some acknowledgement?
I don't think it's as simple as a low memory thing as one user suggested - 16GB isn't pushing limits but I wouldn't say it's low.
I've got 32GB of RAM, DDR4 and DDR5 laptops and I'm facing this issue, especially when waking from sleep.
This is a relatively recent issue (in the last year) as I was not experiencing this in 2021 and 2022 on Windows 10 and early releases of Windows 11.

Update: I found that that specifically in my case the issue was likely due to a poorly written USB floppydrive driver. I don't think this is the case for everyone, but I thought I should mention.

@robindegen Details please? We use vscode dev containers and having to reboot or even wsl --shutdown is killing us all slowly.

Same issue here, all wsl commands including wsl --shutdown hangs (that helped previously, ~1-2 months ago), however taskkill /f /im wslservice.exe was working without reboot.

We solved this issue by moving all dev machines and servers to real linux. Good bye M$

Also got this issue.
CPU Usage of the Vmmem.exe process shoots up to 90% usage, seemingly at random.
taskkill /f /im wslservice.exe works, but it's rather annoying to do this every time this issue occurs.
Hopefully there will be a fix one day soon, but I understand that identifying the source of this problem can be quite difficult and maybe this is an environment issue (Drivers, hardware, etc.).

@robindegen Details please? We use vscode dev containers and having to reboot or even wsl --shutdown is killing us all slowly.

Not much to say unfortunately. I have a usb floppy drive made from the finest chineseum and it was causing the problems for me. When I leave it unplugged I never have wsl issues anymore. When I have it plugged in, every so often the whole thing just locks up as described here.

It also gives me this problem. wsl --shutdown does not work, terminal remains stuck on black screen, no output
The only system is to reboot the operating system

Hey @f-liva as a workaround try this one.
For me the problem may be fixed after updating to Windows 11 Version 22H2. No VmmemWSL hangs since a week 🤞

Nothing changed launching that command

This error again appears - windows 10

Also happening here - lastest version of Windows 11, was fine up until about a week ago
Now every time I wake my PC from sleep WSL won't respond to any commands.
Have to do taskkill /f /im wslservice.exe and then restart everything and docker desktop.

Restarted machine, and... already wsl is hungin on every command, using 30% cpu constantly

For wsl2 try:
on CMD with admin access:
taskkill /F /FI "IMAGENAME -eq wsl.exe" taskkill /F /FI "IMAGENAME -eq wslhost.exe" taskkill /F /FI "IMAGENAME -eq wslservice.exe"

For wsl2 try:
on CMD with admin access:
` taskkill /F /FI "IMAGENAME -eq wsl.exe"
taskkill /F /FI "IMAGENAME -eq wslhost.exe"
taskkill /F /FI "IMAGENAME -eq wslservice.exe" `

This worked for me.
Running taskkill /f /im wslservice.exe would complete but not help with resizing the VHD, the optimize command would say the disk is still in use despite wsl --list --verbose saying Ubuntu wasn't running.

Facing same issues, Couldn't end process (vmmem) from task manager, it says access denied, also powershell command to taskkill also says process not found.

Same problem. It's running under a different user . Some kind of 036A94A8-1418-9295-A028AEFF305F
So I can't kill it even from Admin prompt / Admin Task Manager
taskkill /f /im wslservice.exe helped
$ wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2604

This issue still exists, it surprises me a issue affecting so many people is closed..

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

Thanks for the command, now we are running this command instead of rebooting all the time

https://github.com/microsoft/WSL/issues/9758

It's been months, I am facing same issue, when laptop goes sleep and come back then this issue start appearing

Update here - we have identified a couple of causes of the vmmem process geting into this state (which also causes the wslservice executable to stop responding). Unfortunately, these issues are in the Windows OS, so we're working through the process of backporting the fixes.

@benhillis  Can you confirm this is the same problem as #8696?

In my environment, both taskkill /f /im wslservice.exe and restarting didn't work for it. However, it's been resolved after I updated Windows10 to latest release.

Same here, was resolved yesterday with the latest windows update.

unfortunately couple days ago i was in eye of the storm :)
i got windows 11 updates (KB5023706) and reboot .. big mistake because it start breaking after each sleep again.
I hope it is just me and everyone else got it working :)

Hello! Could you please provide more logs to help us better diagnose your issue?
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 scipt will output the path of the log file once done.
Once completed please upload the output files to this Github issue.
Click here for more info on logging
Thank you!

I too am having the same problem, and here's my log. I am unable to run wsl.exe dmesg as running even that command makes WSL hang.
WslLogs-2023-03-17_11-05-04.zip

Having exactly this issue (WSL freezing, only Taskkill/Taskmanager + Lxss service restart helps) since getting new PC with Win 11 couple of months ago.
I found a workaround which works at least for me: if I keep both WSL1 and WSL2 shells open in terminal, this $#!@ does NOT happen. If I forget to do it, WSL hangs next time I leave the PC idle for couple of hours. (I use both WSL1 and 2).
Maybe this will help someone.

Although this solution worked for me only as a work around:
https://github.com/microsoft/WSL/issues/8529#issuecomment-1263463528
I left wsl.exe --system -e top running until the issue appears. Below is the screenshot in hope Microsoft can take an indication of what is happening before high CPU occurs.

I hope this helps Microsoft a bit more:

Big thanks to this workaround, it was really helped me stop rebooting my machine.

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

I hope the following helps Microsoft to permanently solve the issue.
I executed wsl.exe --system -e top and I left the window open until the issue occurs again.
This is now frozen but reveals some high cpu for these two:

/usr/bin/weston --backend=r+

/usr/bin/Xwayland :0 -r+

@ddonov workaround is the one I am still using. Big thanks to you @ddonov

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

unfortunately couple days ago i was in eye of the storm :) i got windows 11 updates (KB5023706) and reboot .. big mistake because it start breaking after each sleep again. I hope it is just me and everyone else got it working :)

Am also experiencing this and its really frustrating each time have to try kill from task manager or reboot

Saw this, seems related, worth a shot for the multitudes having this problem:
https://github.com/microsoft/WSL/issues/9745#issuecomment-1464656511

gemmell dixit:

Saw this, seems related, worth a shot for the multitudes having this problem:
https://github.com/microsoft/WSL/issues/9745#issuecomment-1464656511

Improbable. I’m using WSL 1 and 2 both, but the default one is WSL 1
and the problem also occurs when the WSL 2 environment has not yet
been used after reboot.
I have a scheduled task that starts sshd in the WSL 1 environment on
boot, and my normal modus operandi is to ssh into that, and when I
need the WSL 2 box, to…
$ cmd
C> wsl -d Debian
… switch to the other one. Until then it’s dormant. And this is
where I noticed the problem.
bye,
//mirabilos
FWIW, I'm quite impressed with mksh interactively. I thought it was much
much more bare bones.  I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Hi @benhillis any updates on this issue?

Related: https://stackoverflow.com/q/70567543/100836

Thank you very much, this solved the issue for me, at least temporarily. What I noticed is that the LxssManagerUser_xxxxxx service was not running, and stopping it after fixing it seems to reproduce it. If you're using Docker Desktop, do what the answer says and kill every docker process (including the service). Also run wsl --update to ensure you're on the latest WSL version. I'll reproduce the answer below by Renato Prado:

It looks like the hang LxssManager service is preventing wsl to restart, I found a way to stop LxssManager and then I was able to restart wsl normally.
First get the PID of svchost.exe running LxssManager, open the cmd as administrator and run:
tasklist /svc /fi "imagename eq svchost.exe" | findstr LxssManager
Grab the returned PID, then run task manager as administrator, in the details tab, search for the svchost.exe containing the PID, right click it and select 'end process tree'.
Now you should be able to restart wsl normally with 'wsl shutdown and wsl.

A permanent solution if you only care about Docker Desktop is switching to Windows Containers (Hyper-V); to switch from command line: & 'C:\Program Files\Docker\Docker\DockerCli.exe' -SwitchDaemon

FWIW, wslservice.exe never seems to have been running for me but trying to start wsl several times resulted in various wsl.exe and wslhost.exe processes running. Killing those processes and then running wsl --shutdown is--tentatively--what seems to have worked for me:
taskkill /f /im wsl.exe
taskkill /f /im wslhost.exe
wsl --shutdown

in case it matters:
>_ Get-ComputerInfo | select OsName, OsBuildNumber | Format-List

OsName        : Microsoft Windows 11 Pro
OsBuildNumber : 22621

WSL2 Hanging Solution .
Windows 10 Pro 22H2

Settings (Home).
Apps.
Search for 'SubSystem'.
Click the Penguin head. Click 'Advanced Options' hyperlink. A new page appears, Windows Subsystem For Linux.

Scroll down that page Click Terminate and the two Reset buttons, Repair and Reset.
Restart WSL2, directly, or from an app within the Ubuntu folder on the windows start menu.

I'm facing this issue on Windows 11 Pro as well.
Edition	Windows 11 Pro Insider Preview
Version	22H2
Experience	Windows Feature Experience Pack 1000.23440.1000.0

Related: stackoverflow.com/q/70567543/100836

Thank you very much zakimirza88, this solved the issue for me, at least temporarily. What I noticed is that the LxssManagerUser_xxxxxx service was not running, and stopping it after fixing it seems to reproduce it. If you're using Docker Desktop, do what the answer says and kill every docker process (including the service). Also run wsl --update to ensure you're on the latest WSL version. I'll reproduce the answer below by Renato Prado:

It looks like the hang LxssManager service is preventing wsl to restart, I found a way to stop LxssManager and then I was able to restart wsl normally.
First get the PID of svchost.exe running LxssManager, open the cmd as administrator and run:
tasklist /svc /fi "imagename eq svchost.exe" | findstr LxssManager
Grab the returned PID, then run task manager as administrator, in the details tab, search for the svchost.exe containing the PID, right click it and select 'end process tree'.
Now you should be able to restart wsl normally with 'wsl shutdown and wsl.

A permanent solution if you only care about Docker Desktop is switching to Windows Containers (Hyper-V); to switch from command line: & 'C:\Program Files\Docker\Docker\DockerCli.exe' -SwitchDaemon

The above worked for me

Not only do I have slow live reload servers because of the slow NTFS issue. But the process will eventually hang and WSL needs to shut down.

Mine does not wsl --shutdown this hangs forever.    Killed all wslhost.exe too, vmmem is still there.    Do not have an entry for WSL inside "apps and features".
MS please just fix --shutdown for when linux kernel goes memory crazy.

I was having this issue as well and the following worked for me.

From cmd run optionalfeatures.exe
This will open a window of optional windows features.  Scroll down to "Windows Subsystem for Linux" and uncheck it and then click "Ok".
Reboot
Open cmd again and run optionalfeatures.exe again
Scroll down and re-check "Windows Subsystem for Linux" and click "Ok"
Reboot again.  During this reboot a small/quick windows update will occur

I had to reinstall the Ubuntu distro but since then I have not had the hanging wsl issue.

I was having this issue as well and the following worked for me.

From cmd run optionalfeatures.exe
This will open a window of optional windows features.  Scroll down to "Windows Subsystem for Linux" and uncheck it and then click "Ok".
Reboot
Open cmd again and run optionalfeatures.exe again
Scroll down and re-check "Windows Subsystem for Linux" and click "Ok"
Reboot again.  During this reboot a small/quick windows update will occur

I had to reinstall the Ubuntu distro but since then I have not had the hanging wsl issue.

Man! This was a lifesaver. Except this nothing worked for me be it this thread or the other or SO. Thanks a lot!

Adding to the "me too", coming from hibernate, two docker containers where producing more CPU than usual.
docker-compose down
removed all the containers, but the CPU load on vmmem remained, and wsl --shutdown hangs forever.
In parallel. an Ubuntu Distro complete hung during apt install nodejs, cannot Ctrl-C it. Trying to open another Ubuntu Shell hangs the terminal window forever.
wsl dmesg hangs forever (though I am already in the hanging wsl --shutdown).
Was able to run collect-wsl-logs.ps1 but company policy forbids to upload here.

I was having this issue as well and the following worked for me.

From cmd run optionalfeatures.exe
This will open a window of optional windows features.  Scroll down to "Windows Subsystem for Linux" and uncheck it and then click "Ok".
Reboot
Open cmd again and run optionalfeatures.exe again
Scroll down and re-check "Windows Subsystem for Linux" and click "Ok"
Reboot again.  During this reboot a small/quick windows update will occur

I had to reinstall the Ubuntu distro but since then I have not had the hanging wsl issue.

Thank you very much! I didn't even have to reinstall the distro, it works fine! (but you do have to reboot twice).

I gave up on this - the issue has caused problems with every developer within my company.
I've taken the decision to move everyone to cloud-based dev environments.
Such a shame as WSL was so stable till earlier this year, we migrated from linux dev environments to windows + WSL + vscode - but it can't be relied upon recently for critical work. Even personally I was having to force quit WSL every couple of days.

Facing the same issue:
It's Windows, what we were expecting?

Surface Pro9 SQ3
This is still an issue. Having the same problem. You can see Vmmemwsl piling up Cpu and memory - once this reaches critical point, wsl2 stops responding or responds very slow. wsl --shutdown (after waiting a few minutes) will resolve this, but this not very  efficient, as people use this very every day tasks and devolvement.  It also makes no difference if you are using a stable version or Dev version of Windows 11.
If more information logs etc. is needed, I'm happy to assist.

Still

Same thing happening to me 1:1 for the last few weeks.
Do they have any word on this at all?

The issue is still apt, and still slows us down. When can this be fixed?

As all others, I have the same issue. It works for a seemingly random time, then suddenly hangs and consumes all CPU possible.  I haven't been able to spot a specific pattern.

I run into this often enough that I added a function to my PowerShell profile. So far, every time I've run this it has resolved the issue. I try to stop/exit Docker Desktop before running this.
# https://github.com/microsoft/WSL/issues/8529
function Stop-Wsl {
    param(
        [switch]$Force = $false
    )

    if (!$IsWindows) {
        Write-Warning 'WSL can only be stopped from Windows'
        return
    }

    if ($Force) {
        $currentPrincipal = [Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()
        if (-NOT $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
            throw 'Requires Administrator. To force WSL shutdown, need to run taskkill, which requires elevated permissions.'
        }

        taskkill /f /im wsl.exe
        taskkill /f /im wslhost.exe
        taskkill /f /im wslservice.exe
    }

    wsl --shutdown

    if ($Force) {
        taskkill /f /im wslservice.exe
    }
}

PS C:\Users\a> taskkill /f /im wsl.exe
ERROR: The process "wsl.exe" not found.
PS C:\Users\a> taskkill /f /im wslhost.exe
ERROR: The process "wslhost.exe" not found.
PS C:\Users\a> taskkill /f /im wslservice.exe
ERROR: The process "wslservice.exe" not found.
PS C:\Users\a> wsl --shutdown

Nothing works from command line...

I've taken the decision to move everyone to cloud-based dev environments.

That's exactly what these lobbyists want us to do!

I gave up on this - the issue has caused problems with every developer within my company.
I've taken the decision to move everyone to cloud-based dev environments. Such a shame as WSL was so stable till earlier this year, we migrated from linux dev environments to windows + WSL + vscode - but it can't be relied upon recently for critical work. Even personally I was having to force quit WSL every couple of days.

Why did you switch from Linux environments to windows?

wsl hanging is the worst thing that could happen to me.
Every process that I use is tied with wsl.
Everytime the wsl dies, I have to either restart it by wsl --shutdown or worse, restart my machine.
After the restart, I'm required to restart kubernetes service, docker daemon, port-forwards, setup terminal processes (listeners to the port-forwards), setup proxies, etc.
Not to mention, vscode refuses to re-connect after wsl is rebooted. Gotta close and open all the vscode projects too.
Speaking conservatively, I've been facing this issue 4-5 times a day. I won't be lying if I say that I've faced this issue more than 12 times in a day too. Which is bizarre.

Speaking conservatively, I've been facing this issue 4-5 times a day. I won't be lying if I say that I've faced this issue more than 12 times in a day too. Which is bizarre.

Interesting, in my case I seem to be able to avoid the problem by making sure that I keep at least one terminal window open.

I run into this often enough that I added a function to my PowerShell profile. So far, every time I've run this it has resolved the issue. I try to stop/exit Docker Desktop before running this.

Due to company policies, we're not allowed local admin rights on our Windows boxes.

This is the most annoying issue I encounter, it often freezes during rust/cargo/cross compilations and wsl --shutdown will eventually stop fixing it and require a reboot. This issue occurs with Docker and Podman using WSL, whether the compilation is within Docker/Podman or not

I also have the issue on Windows 11 21H2, using Kubernetes 1.27.3 through Rancher Desktop 1.9.1.
After waking up from sleep the vmmemWSL process takes a lot of CPU and cannot be killed.
wsl --shutdown just hangs.

I usally just restart the computer... I've been facing this for weeks.

C:\Users\me>wsl --version
Version WSL : <IP_ADDRESS>
Version du noyau : <IP_ADDRESS>
Version WSLg : 1.0.51
Version MSRDC : 1.2.3770
Version direct3D : 1.608.2-61064218
Version de DXCore : 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Version de Windows : 10.0.22000.2176

Guys I found a fix - delete windows and install Linux :)

I’ve been following this issue for more than half a year now since I first installed WSL and noticed these problems. The silence from Microsoft is deafening.
Regrettably, I have no other viable option other than WSL to do my work ( we cannot do remote Linux development for various security reasons)
we all have the drab, underpowered, stock windows Lenovo laptops that for some reasons are so popular with our IT (crowd) department, serving 10,000+ employees. But with WSL I finally felt that windows was a functional alternative for Linux and macOS… but of course that feeling did not last long.
Anyway, if I can have my way we will create a new IT solution in the future where windows will disappear all together, because this is frankly ridiculous.

Agreed
I moved to Windows from Apple back when WSL1 was a thing - WSL2 was so good, and the integration with VS Code meant most of the dev team moved to it.
We enjoyed using dev containers in WSL in VS code, but this issue has been as you say half a year with nothing from MS
WSL now crashes every few days, force stopping everything all the time, I've personally moved to a remote dev environment on Alpine and most of my dev team have been forced to move to linux laptops
MS were really doing some very exciting things in the software development space but this issue being ignored is quite shocking :(

WSL stuck because of lxssmanager
lxssmanager stuck at stopping
So how to shut stuck lxssmanager?
Answer here https://stackoverflow.com/a/70567544
First get the PID of svchost.exe running LxssManager, open the cmd as administrator and run:
tasklist /svc /fi "imagename eq svchost.exe" | findstr LxssManager
Grab the returned PID, then run task manager as administrator, in the details tab, search for the svchost.exe containing the PID, right click it and select 'end process tree'.
Now you should be able to restart wsl normally with 'wsl shutdown and wsl.

Any action @pmartincic @owenschupp @benhillis @craigloewen-msft ongoing ?

The workaround @andcha posted works for me.

WSL stuck because of lxssmanager lxssmanager stuck at stopping...

I actually ran into this myself this morning, Vmmem spinning at ~45% CPU. Unsure if it was already going on after waking from hibernation or not, but I definitely noticed it when the security suites started doing their regular scanning of my system.
Exiting my Visual Studio Code and WSL 2 showed that WSL never went from Running to Stopped.
I am lucky I have local admin rights, so I will try @andcha's suggestion. But today I had to end the WSL process via task manager.
I am really curious if this all happened after the systemd integration, which I use with my installed distribution. Heck, it's the only option I have in /etc/wsl.conf.

Also seeing this behavior. I find that it's much more likely to hang with high disk usage. During the hang, if you open a terminal and try to use the filesystem, e.g. ls, the command will also hang indefinitely. WSL commands will not work in this state.

That's a good point @blackadar - in my case I noticed this problem occuring due to SentinelOne, the corporate security suite on my laptop, doing a full system scan. Which was doing a lot of sustained disk IO in addition to the CPU usage.

So I just ran into this problem again after about7 hours since I started working. None of the aforementioned security applications was doing anything. I was using Visual Studio Code via WSL. I saw that the background node.js was utilising the CPU heavily once I noticed my Windows Terminal shells becoming slow to respond to keys. I quit out of all Code windows. Node.js was gone from top and no heavy CPU load was showing within WSL2. However, this did cause Vmmem to behave again. At the moment of this writing it is stuck at 98% CPU.
First off, @andcha's workaround did not work for me, none of the svchost entries was because of LxxManager.
At first my shells were sluggish in responding, now they do not respond at all anymore.
Trying to wsl --terminate Debian just hangs on the command prompt.
I did run the PowerShell collection script, hopefully it has some useful information.

WSL2 Debian (both 11 and 12) here gets stuck all the time intermittently, for minutes, even with an idle bash prompt. It comes back to life after that excruciating pause, but it's become unusable. It feels exactly like when the garbage collector of the C64 BASIC kicked in to tidy up some strings.
(As many others, I thought WSL2 was the panacea to the Win x Linux interop pains, and I was so grateful to MS for making this possible, but now, alas, the disease is back. Need to migrate away from the comfiness of a single-host Windows setup to a multi-node env. with proper Linux servers yet again. :-/ )

I found a combo of killing all the wsl services and then restarting LxssManager service managed to get it working.
In an admin powershell session:
taskkill /f /im wslservice.exe
taskkill /f /im wslhost.exe
taskkill /f /im wsl.exe
wsl --shutdown
Get-Service LxssManager | Restart-Service

Don't know if it'll work for everyone but it worked for me

If you have this issue and killing LxSSManager and wslservice.exe doesn't work.
Try to execute optionalfeatures.exe (from run or cmd) and disable windows subsystem for linux -> restarts( 2+times) -> enable wsl -> restart
It might work...

That's a good point @blackadar - in my case I noticed this problem occuring due to SentinelOne, the corporate security suite on my laptop, doing a full system scan. Which was doing a lot of sustained disk IO in addition to the CPU usage.

Sustained disk IO in addition to CPU usage is maybe a common use-case, if one is say ... using WSL to compile?

I found a combo of killing all the wsl services and then restarting LxssManager service managed to get it working.
In an admin powershell session:
taskkill /f /im wslservice.exe
taskkill /f /im wslhost.exe
taskkill /f /im wsl.exe
wsl --shutdown
Get-Service LxssManager | Restart-Service

Don't know if it'll work for everyone but it worked for me

Works when the service is start to hanging, but not after computer sleeps. But it's better than nothing ¯_(ツ)_/¯ Thanks!!

Is there any chance that will be fixed?

I see all the restarting LxssManager and whatnot, but on two systems where I use WSL2 neither of them has the LxssManager service running. So I have some doubt this is the cause, at least for my situation. Funnily enough only one of those systems shows these problems, the other just keeps running without any issues.

on two systems where I use WSL2 neither of them has the LxssManager service running
yes, the same applies to my Win10 machine (19044.3086).

in my case running taskkill /f /im wsl.exe is sufficient to restart WSL.

Try to execute optionalfeatures.exe (from run or cmd) and disable windows subsystem for linux -> restarts( 2+times) -> enable wsl -> restart
It might work...
@Lounarok - might it work as permanent fix or is it just another workaround?

Isn't anyone from Microsoft around? Who is responsible for this mess?

Try to execute optionalfeatures.exe (from run or cmd) and disable windows subsystem for linux -> restarts( 2+times) -> enable wsl -> restart
It might work...

@Lounarok - might it work as permanent fix or is it just another workaround?

I don't have any hang issue for now. It's been 2 days.
Will update if the issue happen again.

I can't believe this still isn't fixed and nobody cares lol

Try to execute optionalfeatures.exe (from run or cmd) and disable windows subsystem for linux -> restarts( 2+times) -> enable wsl -> restart
It might work...

@Lounarok - might it work as permanent fix or is it just another workaround?

I don't have any hang issue for now. It's been 2 days. Will update if the issue happen again.

It only helped me temporarily (and was the only thing that worked).

I create logs and found this:

It happens not only after hibernation, but after hibernation you get it 100%

I got myself a Surface Pro X with SQ2 and I set up a brand new WSL installation. This happens 100% after hibernate and is 100% reproducible.

Seems to happen to me some time after hibernation as well (not immediately, but after a few hours).

Same issue is happening to me for last 12 months or more. I always shutdown Docker and WSL as a workaround. Then I tried to limit the allocated memory to wsl and it made some improvements but this hanging thing still occurs from time to time. Sometimes wsl doesn't even respond to shutdown command and Docker fails to start when it happens.
Please provide a fix for this!

This looks a common issue which is not yet fixed. Even if I open the wsl from windows terminal and it remains idle for some time , it just gets freezes. Same case if we open wsl directly. ( I am using wsl2 )

Happens for me. No hibernation involved. Happens sporadically during everyday use, but when I return from afk it's almost always hung.

Just adding, that this issue still needs addressing

disabling wayland seems to help. Create a file named .wslconfig in your user's directory with this content:
[wsl2]
guiApplications=false

Have you try to update wsl with
wsl --update

guiapplications is only available for Windows 11 and , did wsl --update but it is not helping

guiapplications is only available for Windows 11 and , did wsl --update but it is not helping

It's not. Newer versions of WSL 2 support GUI on Windows 10, see e.g. https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps

try running wsl --update 3 times in a row in a cmd.exe session after a clean reboot.

Jeroen Ruigrok van der Werven dixit:

It's not. Newer versions of WSL 2 support GUI on Windows 10, see e.g.

But it happens without that as well, I normally run a WSL 1 only
(I also have a WSL 2 but it’s not the default, it only serves for
occasional tests, but, as WSL 2 has broken network, it’s unusable
for most tasks).

Jakob dixit:

try running wsl --update 3 times in a row in a cmd.exe session after a clean reboot.

That sounds more like magic placebos and cargo-culting than a real
solution… what should that bring, and where would that be documented…

Furthermore, even without using GUI applications, you might still hit relevant codepaths that that boolean value disables.
@bebbo Did you find it out by examining the ETW traces?

It is one of the tips I found during my search, e.g. here: https://www.minitool.com/news/vmmem-high-memory.html
And until now I had no more hangs or vmmemwsl high cpu issues.
Since I'm using VcxSrv gui applications do still work.
But does this help someone else too? Please report it here!

try running wsl --update 3 times in a row in a cmd.exe session after a clean reboot.

I find it also helps to pat the top of your head while rubbing your stomach and turning three times in place.

I found a combo of killing all the wsl services and then restarting LxssManager service managed to get it working.
In an admin powershell session:
taskkill /f /im wslservice.exe
taskkill /f /im wslhost.exe
taskkill /f /im wsl.exe
wsl --shutdown
Get-Service LxssManager | Restart-Service

Don't know if it'll work for everyone but it worked for me

Thanks, this quote was helpful for my case.
The problem was that LxssManager service was hanging in stopping process.
The attempt to kill LxssManager service in services.msc during stopping process didn't work for me.
So, I found the LxssManager service under Service Host: Local System in taskmanger and killed it.
And then, I restarted LxssManager service in services.msc and wsl command came back to normal.

No wonder this issue is more than a year old, was attempted to be closed without solving, and no one is still listening, it is Microsoft.
I have been a mac user but had to shift to windows (that too without administrator user). Created Linux containers to work and now hitting this issue. Without Administrator access, rebooting the windows is the only option. Have tried everything but nothing works.
Is there a way I can restart "Windows Subsystem for Linux Service" by a non-admin user? At least would save myself from rebooting my laptop.

I create logs and found this:  It happens not only after hibernation, but after hibernation you get it 100%

Yes, I noticed it ONLY after hybernation. I'm really disappointed that they just don't care enough to fix this. I've reported it through all the proper channels. But they don't fix it. Do you guys see it on Intel as well. I had always assumed that it was only on ARM Windows, which is basically Microsofts redheaded step child.

This happens on my Surface Book 2 running the latest windows 11 build as well after just a few minutes of sleep.
Killing wslservice.exe brings it to life again.

Hi, happily reporting that I've not experienced this issue anymore for long over a month now on latest Windows 11 release. My current OS build is 22621.2283. Using WSL 2 for daily work, sleeping and hibernating in the end of working day and resuming back the other day. Always leaving my Windows Terminal with WSL session opened.
I've been experiencing the issue heavily for long time before while on Windows 10 and shortly even after I upgraded my laptop in-place to Windows 11. I always had to taskkill the wslservice.exe proccess due to post-resume terminal freezes before. After some of the updates received during summer period, the issue disappeared completely for me. This is pure luck, I have not registered any note from Microsoft about potential fix of this issue while applying the updates.

Hi, happily reporting that I've not experienced this issue anymore for long over a month now on latest Windows 11 release. My current OS build is 22621.2283. Using WSL 2 for daily work, sleeping and hibernating in the end of working day and resuming back the other day. Always leaving my Windows Terminal with WSL session opened.
I've been experiencing the issue heavily for long time before while on Windows 10 and shortly even after I upgraded my laptop in-place to Windows 11. I always had to taskkill the wslservice.exe proccess due to post-resume terminal freezes before. After some of the updates received during summer period, the issue disappeared completely for me. This is pure luck, I have not registered any note from Microsoft about potential fix of this issue while applying the updates.

I found a combo of killing all the wsl services and then restarting LxssManager service managed to get it working.
In an admin powershell session:
taskkill /f /im wslservice.exe
taskkill /f /im wslhost.exe
taskkill /f /im wsl.exe
wsl --shutdown
Get-Service LxssManager | Restart-Service

Don't know if it'll work for everyone but it worked for me

Thanks, this quote was helpful for my case. The problem was that LxssManager service was hanging in stopping process. The attempt to kill LxssManager service in services.msc during stopping process didn't work for me. So, I found the LxssManager service under Service Host: Local System in taskmanger and killed it. And then, I restarted LxssManager service in services.msc and wsl command came back to normal.

Unfortunately workarounds like this doesn't help with those of us who do not have local admin with company issued workstations, let alone suggesting to "upgrade" to Windows 11.

@ToniCipriani I would not call the case workaround, it just appears to be completely fixed. No compromises from usability or extra configurations needed. Maybe you meant it in context of Windows 10 - right, originally I have not noticed I was replying to an issue filed for Windows 10 specifically since there are multiple similar/duplicate issue tickets of the same problem that I'm following. Take it just as an observation reported.
@mmichal3 I'm not on the git patch release WSL 2.0.0. To avoid confusion - yes, I'm running WSL 2 instances, they just somewhat confusingly number the whole WSL software stack release separately as I've just figured out. This is my full versions output:
PS C:\> wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.51
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.22621.2283
PS C:\> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2

Lukáš Kubín dixit:

PS C:> wsl --version
WSL version: <IP_ADDRESS>
[…]

Huh.
C:\WINDOWS\system32>wsl --version
Invalid command line option: --version
[…]
It hasn’t happened to me in a while, though I suspect…
C:\WINDOWS\system32>wsl -l -v
NAME            STATE           VERSION

Ubuntu-20.04    Running         1
Debian          Stopped         2

… this may have something to do with it: when it happened,
the WSL2 VM had been in use at least once since the last
reboot.
Given that WSL2 is useless anyway, what with the broken
networking, and in that it’s just a badly done Linux VM,
whereas WSL1 is the really interesting technology, this
may not be such a big loss… but I need to have access to
both, and both working, so I can test stuff for a customer
on both, so I would like this fixed in a way that doesn’t
require killing a running WSL… especially since the WSL1
sshd is my primary way of connecting to the machine.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

They just .. like in the last few days... Added a bunch of new networking
stuff. What do you mean broken networking? If it's something thwy upgraded
it might work for you now. Or if it just can't find DNS, that is (or at
least should be) fixable with a few config tweaks.
On Tue, Sep 26, 2023, 1:48 PM mirabilos @.***> wrote:

Lukáš Kubín dixit:

PS C:> wsl --version
WSL version: <IP_ADDRESS>
[…]

Huh.
C:\WINDOWS\system32>wsl --version
Invalid command line option: --version
[…]
It hasn’t happened to me in a while, though I suspect…
C:\WINDOWS\system32>wsl -l -v
NAME STATE VERSION

Ubuntu-20.04 Running 1
Debian Stopped 2

… this may have something to do with it: when it happened,
the WSL2 VM had been in use at least once since the last
reboot.
Given that WSL2 is useless anyway, what with the broken
networking, and in that it’s just a badly done Linux VM,
whereas WSL1 is the really interesting technology, this
may not be such a big loss… but I need to have access to
both, and both working, so I can test stuff for a customer
on both, so I would like this fixed in a way that doesn’t
require killing a running WSL… especially since the WSL1
sshd is my primary way of connecting to the machine.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/8529#issuecomment-1736278432,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXTKJWLIKSQRYWCNHXWCKILX4M5SVANCNFSM5ZGR6A7A
.
You are receiving this because you were mentioned.Message ID:
@.***>
CAUTION: EXTERNAL SENDER Do not click any links, open any attachments,
or REPLY to the message unless you trust the sender and know the content is
safe.

 And yes, it could be supported better. But
the way it integrates with the Linux desktop and uses video acceleration is
pretty slick. I especially like it on arm Linux for some apps I can't build
on arm windows for various reasons.
On Tue, Sep 26, 2023, 1:48 PM mirabilos @.***> wrote:

Lukáš Kubín dixit:

PS C:> wsl --version
WSL version: <IP_ADDRESS>
[…]

Huh.
C:\WINDOWS\system32>wsl --version
Invalid command line option: --version
[…]
It hasn’t happened to me in a while, though I suspect…
C:\WINDOWS\system32>wsl -l -v
NAME STATE VERSION

Ubuntu-20.04 Running 1
Debian Stopped 2

… this may have something to do with it: when it happened,
the WSL2 VM had been in use at least once since the last
reboot.
Given that WSL2 is useless anyway, what with the broken
networking, and in that it’s just a badly done Linux VM,
whereas WSL1 is the really interesting technology, this
may not be such a big loss… but I need to have access to
both, and both working, so I can test stuff for a customer
on both, so I would like this fixed in a way that doesn’t
require killing a running WSL… especially since the WSL1
sshd is my primary way of connecting to the machine.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/8529#issuecomment-1736278432,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXTKJWLIKSQRYWCNHXWCKILX4M5SVANCNFSM5ZGR6A7A
.
You are receiving this because you were mentioned.Message ID:
@.***>
CAUTION: EXTERNAL SENDER Do not click any links, open any attachments,
or REPLY to the message unless you trust the sender and know the content is
safe.

(OT but answering because I was directly called out)
mmichal3 dixit:

They just .. like in the last few days... Added a bunch of new networking
stuff. What do you mean broken networking?

It’s got a separate network interface that connects to the exteriour
by Hyper-V’s router/proxy, which is IPv4-only and bleaches ECN bits.

WSL1, by contrast, uses the native NT kernel’s network functions and
even something that doesn’t work on Win32 works under WSL1. It also
supports the current version of the IP protocol, IPv6, which pretty
much is mandatory these days.
Additionally, WSL2/Hyper-V networking breaks DNS badly:
https://github.com/microsoft/WSL/issues/6051

I wokudt go so far as to call it "just a badly done Linux virtual machine"

But it is one!
It’s really just a Linux VM with extra integrations for filesystem
and apparently graphics nowadays, but the VM part is really really
bad, literally anything, even shudder VirtualBox, is better.
Microsoft VirtualPC from 2004 is better. Really.

the way it integrates with the Linux desktop and uses video acceleration is
pretty slick.

Doesn’t help if the application cannot even connect to the exteriour
due to lack of IP support (only Legacy IP). Besides, I good as only
use it via SSH anyway, with a bit of RDP thrown in: the machine is
located in a server room (despite being a laptop) as that was the
easiest way for our admins to give me access to a Windows system…
Anyway, WSL1 is the really interesting technology. Somewhat like
Interix/SFU but using the Linux ABI.
To be honest, I’d have welcomed a bugfixed Interix/SFU just as well
(and probably invested some effort into getting the Debian/Interix
port up to date). But WSL1 like the BSDs’ Linuxulator does the job.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

This is what they say the new features are. I think it's still
experimental, but I doubt we expect new features to roll out fully tested
and complete. For what it's worth they claim it's supposed to show all your
network interfaces from Windows in the Linux environment.

IPv6 support
Connect to Windows servers from within Linux using the localhost
address <IP_ADDRESS>
Connect to WSL directly from your local area network (LAN)
Improved networking compatibility for VPNs
Multicast support
DNS tunneling
Hyper V firewall
Autoproxy

There's also some disk and memory stuff. That looks like some good stuff
coming down the pipe. Admittedly, it only is if they actually follow
through an it's not experimental for 5 years.
On Tue, Sep 26, 2023, 2:38 PM mirabilos @.***> wrote:

(OT but answering because I was directly called out)
mmichal3 dixit:

They just .. like in the last few days... Added a bunch of new networking
stuff. What do you mean broken networking?

It’s got a separate network interface that connects to the exteriour
by Hyper-V’s router/proxy, which is IPv4-only and bleaches ECN bits.

WSL1, by contrast, uses the native NT kernel’s network functions and
even something that doesn’t work on Win32 works under WSL1. It also
supports the current version of the IP protocol, IPv6, which pretty
much is mandatory these days.
Additionally, WSL2/Hyper-V networking breaks DNS badly:
https://github.com/microsoft/WSL/issues/6051

I wokudt go so far as to call it "just a badly done Linux virtual
machine"

But it is one!
It’s really just a Linux VM with extra integrations for filesystem
and apparently graphics nowadays, but the VM part is really really
bad, literally anything, even shudder VirtualBox, is better.
Microsoft VirtualPC from 2004 is better. Really.

the way it integrates with the Linux desktop and uses video acceleration
is
pretty slick.

Doesn’t help if the application cannot even connect to the exteriour
due to lack of IP support (only Legacy IP). Besides, I good as only
use it via SSH anyway, with a bit of RDP thrown in: the machine is
located in a server room (despite being a laptop) as that was the
easiest way for our admins to give me access to a Windows system…
Anyway, WSL1 is the really interesting technology. Somewhat like
Interix/SFU but using the Linux ABI.
To be honest, I’d have welcomed a bugfixed Interix/SFU just as well
(and probably invested some effort into getting the Debian/Interix
port up to date). But WSL1 like the BSDs’ Linuxulator does the job.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/8529#issuecomment-1736337239,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXTKJWLOHIV5JXSGJZXVMZ3X4NDOTANCNFSM5ZGR6A7A
.
You are receiving this because you were mentioned.Message ID:
@.***>
CAUTION: EXTERNAL SENDER Do not click any links, open any attachments,
or REPLY to the message unless you trust the sender and know the content is
safe.

Can I gently request we stay on topic?

Hi, happily reporting that I've not experienced this issue anymore for long over a month now on latest Windows 11 release. My current OS build is 22621.2283. Using WSL 2 for daily work, sleeping and hibernating in the end of working day and resuming back the other day. **** Always leaving my Windows Terminal with WSL session opened. ******

Hi, is the issue also gone if you do NOT leave terminal windows opened? That trick worked for me over a year, but with closed terminal windows it's all back. Mine is Win 11 22621.2283.

I had the same issue (all wsl commands hang, including wsl --shutdown) and I did a bunch of things, so not sure what worked for me, but I believe what I did along the process is to disconnect all network drives using this command in CMD
net use * /delete

In my case I was able to launch wsl using an elevated powershell, but not from a regular one. Using this I also updated wsl to the latest pre-release using wsl --update --pre-release, installed windows updates and restarted several times.
For reference here are the current versions I am using:
C:\Users\Me> wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-1
WSLg version: 1.0.58
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2361

It happened to me again.
The thing I did is to enter the WSL2 VM (wsl -d Debian from CMD), upgrade it, exit it and even stop it.
Merely having ever had a WSL2 VM active after the reboot is going to trigger this.
My WSL1 environment is still working fine, but I cannot use the wsl executable from CMD any more. (I normally enter by ssh’ing into the WSL1 system.)
The system is good as idle, about 3% CPU usage on average, when RDPing in and looking at Task Manager.
So this is a bug triggered by use, any use, of a WSL2 VM.

I could get it working again by…
net stop lxssmanager
REM damn, it doesn’t work, so let’s kill this manually
sc queryex lxssmanager
REM shows the PID, here 7800
wmic process where ProcessID=7800 delete
net start lxssmanager

Unfortunately, for the last step I had to manually open an admin cmd, the others worked from my normal one.
This is not a solution!

Just happened to me. Actually I didn't know what's going on, just searched "wsl shutdown doesn't work" and here I am...
My laptop went to sleep with docker on and came back unfunctional. I couldn't restart windows as I had so much stuff going on... WSL too - I need to do a lot of set up when restarting WSL, I am still looking for a way to recover instead of just restarting but getting desperate here...

same issue here.

happened to me as well. had to taskkill and update.

Annoyingly this happens for me pretty much anytime I hibernate without forgetting to shut down wsl first.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.51
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.3570

good lord, i know microsoft just trying their best, i am at this point i can choose between two things (as long as i have to use windows):

everytime to shutdown wsl before suspend
host a own virtual machine and to take care

@cinatic Is Windows 11 not an option for you? Seems that the issue disappeared somewhere around 10.0.22621.2283 version.

Unfortunately not yet, due to company policies i am still bound to win10

I am also experiencing this problem.
Every time windows wakes up from sleep, wsl doesn't work, vscode can't connect to wsl ubuntu, terminal can't open ubuntu, and I can only solve it with wsl --shutdown, but it's really a waste of time.
I'm surprised that this problem since it's been around for at least a year why is there never any official explanation?

benhillis commented "officially" (?) earlier this year but it's hard to notice that response in the huge number of replies (some of which are auto-collapsed):
https://github.com/microsoft/WSL/issues/8529#issuecomment-1460463871

Also facing this issue.

I have been following this thread for almost a year now. It has been frustrating to say the least. I updated WSL with the new beta patch which seems to have lowered the frequency of crashes somewhat, but then WSL never released any hard drive space back to the windows partition. I hopelessly tried solution to clean the virtual disk space. Eventually, I had no hard drive space left on my windows partition.
I suspect that the team that developed WSL is no longer at Microsoft and the project is bit-rotting away slowly. We have not heard anything here from Microsoft as far as I know...
Anyway, at my work we have now finally switched to apple computers. This ends WSL for my part, and I hope to never see it again.
Side note: Since the beginning, Microsoft has been developing rushed software, new frameworks to replace old ones, but never drops them. They pass the cost onto you instead (Fun fact: Bill Gates bought DOS for $70k, which was called qDOS - quick and Dirty OS. Very little has changed it seems.)

Filip Persson dixit:

I have been following this thread for almost a year now. It has been
frustrating to say the least.

Yeah.
At least it’s possible to only use WSL 1, which is better than WSL 2
anyway, to avoid this issue.
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

Faced the same issue.
wsl --update resolved the issue

I am also facing the same issue since many months.
I have also tried "wsl --update". It updated to latest version but the problem is still there.

Inspired by #9331, which fixed another mysterious WSL problem on another machine, I tried netsh winsock reset from an Admin shell, and reboot. Subsequently, this issue (WSL hanging, vmmem using ~100% CPU) has not reoccurred - in a week so far.
(Following the last advice, wsl --update did update the WSL version, but I still got hangups, perhaps a little less frequently.)

Just posting to confirm, this is still an issue as of January 2024. Every time hibernate is used with WSL running, which is often due to having a Docker instance open.
Usually using
wsl --shutdown

will resolve the issue, after waiting a few minutes, but not always. Sometimes the command gets fully stuck and nothing happens even after half an hour.
These commands:
taskkill /f /im wslservice.exe
taskkill /f /im wslservice.exe
taskkill /f /im wslhost.exe
taskkill /f /im wsl.exe
wsl --shutdown
Get-Service LxssManager | Restart-Service

are not a panacea either. For many users, the issue is going to be with a WSL instance used by their Docker instance, which means, they will have Vmmem be stuck non-responsive and causing full CPU load. The taskkill commands will be ineffective then, at least we observe this on our machines. The wsl --shutdown, like mentioned, will sometimes not finish and become stuck and Get-Service LxssManager | Restart-Service will just keep repeating WARNING: Waiting for service 'LxssManager (LxssManager)' to stop....
The second most reliable way I observe is wsl --shutdown, the only absolutely reliable is restarting the machine. This is simply awful.

I tried netsh winsock reset from an Admin shell, and reboot. Subsequently, this issue (WSL hanging, vmmem using ~100% CPU) has not reoccurred - in a week so far.

To follow up on this, the netsh winsock reset may have reduced the number of times this problem occurs, but not eliminated it entirely.
Like @AlexanderHess and others, it happens after resuming from Hibernate, but (for me) not every time I hibernate. Using just:
taskkill /f /im wslservice.exe
always works to stop the runaway process (always  vmmem using ~100% of the CPU) so I can restart wsl.
I am not using Docker, so the issue is with WSL alone.

Same most of the time it always slow down my pc.

When was the last response by anyone at Microsoft in this thread?
I use WSL all day at work, it was the deciding factor in me requesting a Windows laptop over Mac. I am still running into this issue multiple times a week. I have a quick batch file
taskkill /f /im wslservice.exe
ubuntu config --default-user jared

(the 2nd line because the first seems to always reset the default user to root) that I run when it happens, which usually works. But this at the least forces me to quit everything I was working on and reopen all my terminals, and sometimes the wsl command still just hangs and does nothing afterwards.
In short, this is a constant timewaster for me (and it seems like many others) and it seems like we should at least be getting occasional updates from the developers or at least just an acknowledgement that they are aware it is still an issue and they are working on it.

@microsoft: same issue here. WSL gets unresponsive after some time and required a machine reboot.

Facing this on windows 10 and 11. How this issue was closed / ignored for so long is beyond me. Embarrassingly bad user experience

I also experience this, weekly at a minimum. It is not related to hibernate for me (as others have noted) because I never use that feature.
WSL2 starts running away with half my CPU for no apparent reason (I've limited it in wslconfig so it doesn't slow the whole desktop).
This kills my workflow as I am developing with Docker (VSCode remote-dev), for Docker, all day

I also experience this, weekly at a minimum. It is not related to hibernate for me (as others have noted) because I never use that feature.

Do you work from laptop or desktop PC?

Hi folks! We are actively investigating this issue, and I'll post any updates to this thread as soon as they're ready.
I also wanted to add a thank you for all the users sharing their logs, work arounds, and pain points surrounding this problem. I can very much see that this is a frustrating bug to deal with, and we haven't been as communicative on this issue as I'd like (which I'll own up to!). Going forwards I'll keep a specific eye on this GitHub thread, even when not posting direct updates.

Hi @craigloewen-msft,

I also wanted to add a thank you for all the users sharing their logs, work arounds, and pain points surrounding this problem.

Thanks for the investigations and news. If you are still trying to debug the issue and aren't able to reproduce it yourself, and have some more ideas of logfiles or additional process monitoring that we could check when the system hangs up, do let us know. I'll do my best to try to help.

Hi @craigloewen-msft,

I also wanted to add a thank you for all the users sharing their logs, work arounds, and pain points surrounding this problem.

Thanks for the investigations and news. If you are still trying to debug the issue and aren't able to reproduce it yourself, and have some more ideas of logfiles or additional process monitoring that we could check when the system hangs up, do let us know. I'll do my best to try to help.

Same here - this would be a killer feature of Windows for me if it were more reliable. I am anxious to get it working without having to reboot a couple of times each day.

Also facing this issue. What is the process called that I need to kill in Windows Task Manager for WSL to shut down?
taskkill /f /im wslservice.exe

Says

ERROR: The process "wslservice.exe" not found.

[Edit]
Ah, I had to do:
taskkill /f /im wsl.exe

SUCCESS: The process "wsl.exe" with PID 17816 has been terminated.

Unfortunately, WSL would not come up afterwards again. So still a full reboot.

I want to say that my issue disappeared, for some reason. I upgraded the WSL Kernel, so maybe this was the reason.

Also facing this issue. What is the process called that I need to kill in Windows Task Manager for WSL to shut down?
taskkill /f /im wslservice.exe

Says

ERROR: The process "wslservice.exe" not found.

[Edit]
Ah, I had to do:
taskkill /f /im wsl.exe

SUCCESS: The process "wsl.exe" with PID 17816 has been terminated.

Unfortunately, WSL would not come up afterwards again. So still a full reboot.

I want to say that my issue disappeared, for some reason. I upgraded the WSL Kernel, so maybe this was the reason.

Did you upgrade to a custom kernel? What kernel are you using?

I Updated to the latest release from Github - since I am on a locked-down Windows Education edition, the App Store is not available, so I had to do it manually:

Download latest AppX WSL manually from WSL Releases

Use Admin PowerShell and run Add-AppxPackage ./Microsoft.WSL_<IP_ADDRESS>_x64_ARM64.msixbundle

This failed, for the following reason as stated above.

Enable Developer mode. Use Show-WindowsDeveloperLicenseRegistration (powerShell)

The Button is grayed out

Open Policies gpedit.msc

Go to Computer Configuration > Administrative Templates > Windows Components >
App Package Deployment.

Click "Allows development of Windows Store apps."
Change to "Enabled"

Developer Mode should now be active

Run Add-AppxPackage ./Microsoft.WSL_<IP_ADDRESS>_x64_ARM64.msixbundle

If it works, disable developer mode in policies afterwards.

Yes +1 to the comments above, if you're still seeing this please try upgrading to the latest WSL release version (2.0.15) and let us know if you're still seeing the issue there. (Helps us debug!)

I had the latest release version (2.0.14) installed [*], which was giving the same trouble, so I tried upgrading with:
wsl --update --pre-release

That gave me 2.1.1. I haven't run with this long enough to see if the problem reoccurs, so will report back later.
[*] PS. I assumed 2.0.14 is the latest release version because wsl --update doesn't upgrade further, and it is listed as such on the GitHub releases page. Would using 2.0.15 be better than going all the way to 2.1.1?

Craig Loewen dixit:

Yes +1 to the comments above, if you're still seeing this please try
upgrading to the latest WSL release version (2.0.15) and let us know if
you're still seeing the issue there. (Helps us debug!)

Uhm…
C:\WINDOWS\system32>wsl --update
Installing: Windows Subsystem for Linux
Catastrophic failure
That’s on a Win10 system (which has to stay Win10 because I have to
test things for customers on it).
bye,
//mirabilos
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

Yes +1 to the comments above, if you're still seeing this please try upgrading to the latest WSL release version (2.0.15) and let us know if you're still seeing the issue there. (Helps us debug!)

Is it applicable to 2.1, but I've got this issue yesterday with it:
$ wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3996

Huh…
C:\WINDOWS\system32>wsl --version
Invalid command line option: --version
Copyright (c) Microsoft Corporation. All rights reserved.
Usage: wsl.exe [Argument] [Options...] [CommandLine]
Arguments for running Linux binaries:
[…]

I'm still seeing this problem with <IP_ADDRESS>. The problem for me tends to arise specifically when trying to shut down a large (in terms of RAM) process. Here's an example screenshot from htop showing some nastiness where the top process is taking up an entire CPU but not actually doing anything:

Yes, I also had a hang-up with 2.1.1. 😢

Oh, this is wonderful.
I went quite a while without this issue… having used only my WSL1 system.
Now I wanted to upgrade my WSL2 system to the latest Debian point release, did so, exited the session, figured I forgot a config change I wanted to do, tried wsl -d Debian, and even wsl -l and… it hangs. This quickly.
What I do not have is the high CPU load, however, just the hanging command.

I've had such limited success using wsl2 across multiple machines that I'm becoming curious if it's actually being used satisfyingly by anyone. And if so, what are they doing with it? I also can't tell if it's abandonware: the kernels are ancient and don't seem to be updated. And I can't seem to successfully use anything like IntelliJ for java/scala development for more than an hour before having every wsl process freeze up.
Then I notice that it seems like there are very few users of it, at least if the number of reviews in the Microsoft Store is a meaningful metric. I'm not really sure what to do, but I keep hoping that this issue will be addressed, yet it still seems like nobody at Microsoft has yet reproduced it.

When things go haywire, it usually starts with messages like this in dmesg and then a single CPU seems to be pegged at 100%:
[Tue Feb 13 22:36:09 2024] rcu: INFO: rcu_sched self-detected stall on CPU
[Tue Feb 13 22:36:09 2024] rcu:         5-....: (13850 ticks this GP) idle=863c/1/0x4000000000000000 softirq=43398/43398 fqs=6500
[Tue Feb 13 22:36:09 2024]      (t=15000 jiffies g=108389 q=15800 ncpus=8)
[Tue Feb 13 22:36:09 2024] CPU: 5 PID: 1607 Comm: FileSystemWatch Not tainted <IP_ADDRESS>-microsoft-standard-WSL2+ #2
[Tue Feb 13 22:36:09 2024] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[Tue Feb 13 22:36:09 2024] pc : clear_rseq_cs.isra.0+0x34/0x44
[Tue Feb 13 22:36:09 2024] lr : __rseq_handle_notify_resume+0x250/0x420
[Tue Feb 13 22:36:09 2024] sp : ffff80000d1abc90
[Tue Feb 13 22:36:09 2024] x29: ffff80000d1abc90 x28:<PHONE_NUMBER>00000c x27:<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x26:<PHONE_NUMBER>000000 x25:<PHONE_NUMBER>000000 x24: ffff000013ff6000
[Tue Feb 13 22:36:09 2024] x23: ffff80000d1abeb0 x22: 0000ff2a6a1cbe3c x21: ffff000013ff5880
[Tue Feb 13 22:36:09 2024] x20: ffff8002162a8000 x19:<PHONE_NUMBER>000000 x18:<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x17:<PHONE_NUMBER>000000 x16:<PHONE_NUMBER>000000 x15:<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x14:<PHONE_NUMBER>000000 x13:<PHONE_NUMBER>000000 x12:<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x11:<PHONE_NUMBER>000000 x10:<PHONE_NUMBER>000aa0 x9 : ffff80000822f1a4
[Tue Feb 13 22:36:09 2024] x8 :<PHONE_NUMBER>000000 x7 :<PHONE_NUMBER>000000 x6 :<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x5 :<PHONE_NUMBER>000000 x4 :<PHONE_NUMBER>000000 x3 :<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] x2 :<PHONE_NUMBER>000000 x1 : 0000ff211d3ed8c8 x0 :<PHONE_NUMBER>000000
[Tue Feb 13 22:36:09 2024] Call trace:
[Tue Feb 13 22:36:09 2024]  clear_rseq_cs.isra.0+0x34/0x44
[Tue Feb 13 22:36:09 2024]  do_notify_resume+0x12c/0xd10
[Tue Feb 13 22:36:09 2024]  el0_svc+0x4c/0x70
[Tue Feb 13 22:36:09 2024]  el0t_64_sync_handler+0xd4/0x150
[Tue Feb 13 22:36:09 2024]  el0t_64_sync+0x148/0x14c

been automatically closed since it has not h

Run this instead: taskkill /f /im wsl.exe

Same here @ddonov, when docker desktop is running and notebook awakes from sleep.
My workaround is to kill the wslservice.exe in a admin powershell: taskkill /f /im wslservice.exe

ERROR: The process "wslservice.exe" not found

Please run this instead: taskkill /f /im wsl.exe

I managed to use wsl --shutdown a few times. However this time, it hangs.
The command of @AbdElRahmanMostafa1 also does nothing.
Everyday, after my laptop comes back from sleep or hibernate, I have to pray it doesn't hang these processes and waste my time.

I managed to use wsl --shutdown a few times. However this time, it (vmmem) hangs completely. The command of @AbdElRahmanMostafa1 also does nothing. Everyday, after my laptop comes back from sleep or hibernate, I have to pray it doesn't hang these processes and waste my time.
edit: when trying to kill the "vmmem" process, I get "Access Denied".

Did you run as administrator?
If not search for powershell, press right click and run as adminstrator
Then run this command: taskkill /f /im wsl.exe

I managed to use wsl --shutdown a few times. However this time, it (vmmem) hangs completely. The command of @AbdElRahmanMostafa1 also does nothing. Everyday, after my laptop comes back from sleep or hibernate, I have to pray it doesn't hang these processes and waste my time.
edit: when trying to kill the "vmmem" process, I get "Access Denied".

Did you run as administrator? If not search for powershell, press right click and run as adminstrator
Then run this command: taskkill /f /im wsl.exe

Yes, I mostly use command line tools as admin, still got access denied wehn killing vmmem.
I ended up killing all wsl processes in task manager; this action then killed vmmem.

I managed to use wsl --shutdown a few times. However this time, it (vmmem) hangs completely. The command of @AbdElRahmanMostafa1 also does nothing. Everyday, after my laptop comes back from sleep or hibernate, I have to pray it doesn't hang these processes and waste my time.
edit: when trying to kill the "vmmem" process, I get "Access Denied".

Did you run as administrator? If not search for powershell, press right click and run as adminstrator
Then run this command: taskkill /f /im wsl.exe

Yes, I mostly use command line tools as admin, still got access denied when killing vmmem. I ended up killing all wsl processes in task manager; this action then killed vmmem.

You don't need to kill vmmem but just wslservice.exe. Killing wslservice.exe terminate all wsl.exe and vmmem

Having same issue here. It is currently preventing me from work as the halting is happening constantly. Almost considering uninstalling everything and going old ways, installing everything for my local dev env on my windows as normal.
I used the taskkill /f /im wslservice.exe command and it did not shut down my wmmem process. Trying manually shuting it down also gave me the Access Denied error, even in administrator mode.
Just updated my wsl to the pre-release as mentioned (2.1.3 for me). Will update if this continue happening.

This worked for me...
PS C:\Users\admin> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2
PS C:\Users\admin> wsl shutdown
Failed to set wall message, ignoring: Interactive authentication required.
Failed to call ScheduleShutdown in logind, no action will be taken: Interactive authentication required.
PS C:\Users\admin> wsl sudo shutdown
[sudo] password for javi:
Shutdown scheduled for Fri 2024-02-23 08:12:30 CET, use 'shutdown -c' to cancel.
PS C:\Users\admin> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2
PS C:\Users\admin> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2
PS C:\Users\admin> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2
PS C:\Users\admin> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Stopped         2
PS C:\Users\admin>

Nice that this worked for you but the problem most people here are facing is that wsl process (e.g. wmmem) totally hangs.
So wsl -l -v does not answer at all nor wsl --shutdown or any other wsl command.
I just rebooted my windows and still have the same problem after reboot.
I already updated wsl to the latest release (not pre-release) but still no luck.
I need docker for my daily work but professional work with docker on windows does not seem to be possible.
My need to switch to Mac...

 when I use wsl vim editor my code, stop working, how i can reboot wsl, now I have to reboot my compute

WSL version: <IP_ADDRESS>
same issue, happens when computer wakes up from sleep and VSCode immediately tries to connect to remote WSL distro.
Manually killing all instances of wsl.exe works as a workaround.

I fixed my issue (put my PC to sleep twice and everything Ubuntu works) by installing the following packages:
sudo apt install build-essential flex bison dwarves libssl-dev libelf-dev

It's silly and annoying, but I can usually recover from this state with this, which I run from a batch script file.
start "" taskkill /F /IM wsl.exe && start "" taskkill /F /IM wslservice.exe && start "" taskkill /F /IM wslhost.exe && start "" taskkill /F /IM wslrelay.exe
start "" taskkill /F /IM wsl.exe && start "" taskkill /F /IM wslservice.exe && start "" taskkill /F /IM wslhost.exe && start "" taskkill /F /IM wslrelay.exe
start "" taskkill /F /IM wsl.exe && start "" taskkill /F /IM wslservice.exe && start "" taskkill /F /IM wslhost.exe && start "" taskkill /F /IM wslrelay.exe
start "" taskkill /F /IM wsl.exe && start "" taskkill /F /IM wslservice.exe && start "" taskkill /F /IM wslhost.exe && start "" taskkill /F /IM wslrelay.exe
start "" taskkill /F /IM wsl.exe && start "" taskkill /F /IM wslservice.exe && start "" taskkill /F /IM wslhost.exe && start "" taskkill /F /IM wslrelay.exe

I started to face this issue myself today, while working as normal yesterday night. I tried all the suggested solutions from this (and other) posts, but although I am able to kill the process using @tricodon's solution (taskkill /f /im wslservice.exe), I can't launch Kali afterwards. I have updated WSL2 to the latest version, but did not resolve the issue.
PS C:\WINDOWS\system32> wsl -v
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3374

WslLogs-2024-04-05_10-56-33.zip

This issue is stills happens to me, updating to the latest version generally fixes it but it does keep coming back.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4170

Nice that this worked for you but the problem most people here are facing is that wsl process (e.g. wmmem) totally hangs. So wsl -l -v does not answer at all nor wsl --shutdown or any other wsl command. I just rebooted my windows and still have the same problem after reboot. I already updated wsl to the latest release (not pre-release) but still no luck. I need docker for my daily work but professional work with docker on windows does not seem to be possible. My need to switch to Mac...

This. Docker is not running and wsl itself works just fine. Powershell usage jumps to around 10-15%

sometimes up to 40

note that commands work perfectly fine in command prompt

Still happening

Updating to the latest Windows 11 might have fixed the issue for me.
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3155

Problem-free, two months and counting...
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3296

I'm experiencing this issue too. The only solution works for me is restarting my laptop. It's so frustating since I need to reopen every workspace in VS Code and other apps.


Do not exit on error when no error occurred

Today, I realized that running bleep --help gives a non-zero exit code. This is a fix for that.

I can amend my PR, no worries.
On Tue, Feb 14, 2023, 17:26 Ondra Pelech @.***> wrote:

@.**** approved this pull request.
I'd even do it as
case Left(List()) =>
System.err.println(help)
ExitCode.Success
But this surely works too 👍
—
Reply to this email directly, view it on GitHub
https://github.com/oyvindberg/bleep/pull/298#pullrequestreview-1298521836,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABH467DUQPZUMLXUZF3VODTWXQBBTANCNFSM6AAAAAAU4DF254
.
You are receiving this because you authored the thread.Message ID:
@.***>

I'm having trouble building locally, not sure if my changes are the cause of this.

Looks good, thanks!
What do you think is the problem @daddykotex ? if you can paste output perhaps I can help diagnose it - compilation should work! :)

I did not spend much time investigating, but it looks like this:

Have you checked out git submodules?

Ahhh it's related to the submodule. Got it to work with git submodule update --remote

I see that the different branches are implemented differently. Is that intentional? (I don't have very strong preference either way.)

Woww, it's my bad. Sorry I was convinced I was updating the same code path not two different codepaths! I've updated with a common handleHelp method that I use on a fold on the two Either[Help, A] we get from command parsing.
wdyt?

That's a great improvement, I used it and reordered the args at the call site following your changes

@daddykotex I'm glad you like my proposal :bow: Have you already commited and pushed your changes?

Yes. The only left over is whether or not we should print the errors
included in the help object if any.
Its possible that they're already printed, I'll validate and update my code
later tonight and it will be ready to merge after that.
On Wed, Feb 15, 2023, 18:59 Ondra Pelech @.***> wrote:

@daddykotex https://github.com/daddykotex I'm glad you like my proposal
🙇 Have you already commited and pushed your changes?
—
Reply to this email directly, view it on GitHub
https://github.com/oyvindberg/bleep/pull/298#issuecomment-1432251452,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABH467E6YG6XBZJSBXNJE7DWXVUXXANCNFSM6AAAAAAU4DF254
.
You are receiving this because you were mentioned.Message ID:
@.***>

It's good to go.