Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL is non-responsive after waking from hibernate #8696

Open
2 tasks
roja45 opened this issue Aug 6, 2022 · 502 comments
Open
2 tasks

WSL is non-responsive after waking from hibernate #8696

roja45 opened this issue Aug 6, 2022 · 502 comments

Comments

@roja45
Copy link

roja45 commented Aug 6, 2022

Version

Windows 11 Pro 21h2 build 22000.832

WSL Version

  • WSL 2
  • WSL 1

Kernel Version

5.10.60.1

Distro Version

Ubuntu 2-.04

Other Software

Docker desktop windows

Repro Steps

Hibernate machine
Start up windows
open a new terminal

Expected Behavior

Shouldn't hang

Actual Behavior

No response, terminal hangs. wsl --shutdown from command prompt also hangs, only solution is to restart the machine.

Diagnostic Logs

No response

@roja45
Copy link
Author

roja45 commented Aug 6, 2022

image

@roja45
Copy link
Author

roja45 commented Aug 6, 2022

image

@roja45
Copy link
Author

roja45 commented Aug 8, 2022

WslLogs-2022-08-08_08-43-05.zip

logs captured while trying to restart wsl

@De-Been-Tech-Solutions
Copy link

WSL has found it hard to reconnect to the PC's storage by the sounds of things.

The next time this happens, I believe restarting WSL will fix it, as it does appear to have a memory leak as well.

Close then re-open is what I meant by this.

@roja45
Copy link
Author

roja45 commented Aug 9, 2022

But how do I restart wsl? wsl --shutdown just hangs.

@De-Been-Tech-Solutions
Copy link

You close it.

Then you re-open it.

@De-Been-Tech-Solutions
Copy link

If it won't close, open task manager then kill the process from there.

@david-dlc-cerezo
Copy link

david-dlc-cerezo commented Aug 16, 2022

Same happens to me, no posible to wsl --shutdown, it hangs as well. The only solution is to restart windows, what is is quite annoying.

@QuentinLemCode
Copy link

QuentinLemCode commented Aug 16, 2022

Hello
Same issue for me, the wsl command hangs at each command
image

Edit : I managed to relaunch it without restarting windows by killing all wsl processes in task manager

@roja45
Copy link
Author

roja45 commented Aug 16, 2022

I don't think this is related to hibernation, I was also using PHPStorm (latest version which was supposed to have fixed a bug with WSL). I have finally abandoned PHPStorm and have been using VSCode for the last week or so, and no more problems with WSL crashing, it has been rock solid ever since.

@pnmcosta
Copy link

pnmcosta commented Sep 7, 2022

I'm on 22000.918 I do get an error after hibernate wake:
image

Only a full restart fixes it! 👎

@rowleya
Copy link

rowleya commented Sep 8, 2022

On Windows OS Build 22000.918, I am also getting a freeze of WSL2 on return from hibernate. CPU use is high:
image

I also can't stop the service:
image

WSL doesn't respond at all (listing doesn't work, status doesn't work, version doesn't work):
image

I am using the latest WSL release 0.66.2.

Restart works to bring things back but that is all that works.

@egorgam
Copy link

egorgam commented Sep 11, 2022

rowleya you may to try update Docker Desktop for last version (v4.12) #8703

In my case I have same problems with WSL2 and hibernate behavior. I tried to turn off hibernation but looks like my laptop dont support S1-S3 sleep mode. So updating the Docker fixed vmmem leak, but not wsl2 stucks after waking up.

@rowleya
Copy link

rowleya commented Sep 12, 2022

I don't have Docker Desktop installed here as I use docker on WSL2 when needed. Note that there isn't a vmmem memory leak here; that is just how much memory I am using!

Of interest, I usually use eclipse within WSL2 and leave that running when hibernating. That had been working until recently, but with the issue, it also meant that the CPU usage of VMMem went very high when restoring from hibernate. On Friday I closed eclipse before hibernating, and on coming back this morning, the high CPU is gone, but WSL still won't start up again without a restart of the computer.

@rowleya
Copy link

rowleya commented Sep 12, 2022

OK, even more interesting, I saw a thread about collecting wsl logs, so I tried to do that this morning, running the process just before hibernating. It seems that the issue didn't then show up. I don't know if this means that it is something to do with the amount of time of hibernation or something... I will try to remember to run the logging process tonight again and see what happens tomorrow...

@genmeblog
Copy link

It happens also to me:

WSL: 0.66.2.0
Kernel: 5.15.57.1
WSLg: 1.0.42
MSRDC: 1.2.3401
Direct3D: 1.606.4
DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows: 10.0.22000.918

After hibernation (not sleeping), VmmemWSL eats 100% CPU, there is no way to shutdown, terminate or restart. I also do not see any memory leaks (memory usage is reasonable).

@rowleya
Copy link

rowleya commented Sep 12, 2022

"Working" was said a bit too soon. It was running, but it was slow! A restart has fixed that again, but I do wonder if something is slowing things down with hibernate and then by the time it comes back (if overnight for example), it has slowed down to basically nothing at all...

@genmeblog
Copy link

OK, even more interesting, I saw a thread about collecting wsl logs, so I tried to do that this morning, running the process just before hibernating. It seems that the issue didn't then show up. I don't know if this means that it is something to do with the amount of time of hibernation or something... I will try to remember to run the logging process tonight again and see what happens tomorrow...

I observe exaclty the same thing. After I turned on logging, wsl doesn't hang...

@saschagysel
Copy link

Having the same issue. It must have started probably after a Windows Update around 2-3 weeks ago as it worked before.

@rowleya
Copy link

rowleya commented Sep 13, 2022

As expected, WSL had frozen on return from hibernate this morning. I have attached the logs gathered during this time, started just before I entered hibernate, and stopped after returning; I did also try to start a WSL terminal just before stopping to ensure it was frozen. Eclipse was also open during this time but non-responsive on return (I could see the window and contents, but couldn't do anything with them).

The logs are attached below:
WslLogs-2022-09-12_16-38-51.zip

@rowleya
Copy link

rowleya commented Sep 13, 2022

From the log, it seems the issue is likely related to the Microsoft Windows Host Network Interface Service, onRundown event, which seems to go into some sort of overdrive...

@rowleya
Copy link

rowleya commented Sep 14, 2022

Progress this morning. Further investigation of the virtual network interfaces, I seemed to have VirtualBox installed. I think this was installed by an IT administrator when they set up my laptop as I didn't install it myself. Anyway, having removed this, it seems that things are better on resume from hibernate. WSL is still responsive, though Eclipse was still running poorly. Restarting WSL seemed to then fix all the speed issues, which is a big step up from having to restart the machine!

@deeep
Copy link

deeep commented Sep 14, 2022

( same issue... uninstalling last win11 update "helped" )

@jheinzel
Copy link

jheinzel commented Sep 14, 2022

I observe more or less the same behavior. My configuration:

  • Windows: 21H2 (OS Build 22000.918)
  • Kernel: 5.10.102.1
  • WSLg: 1.0.26
  • Distro: Ubuntu 22.04
  • Additional software: Docker desktop installed
  • Hardware: Surface Book 3

Behavior

  • Ubuntu shell hangs when opened
  • docker-cli hangs, restarting of docker desktop is not possible

"Workaround"

  • Restart LxssManager service (stopping the service takes a lot of time)
  • wsl --shutdown also works most of the time (not always).
  • Docker desktop has to be restarted, which causes all running containers to be stopped.

@rowleya
Copy link

rowleya commented Sep 16, 2022

I did another Windows update yesterday and am now on 10.0.22000.978. Unfortunately this seems to have brought back the issue again; once again the system resumes from hibernate with VmmemWSL running at high CPU but all of WSL being non-responsive.

This time I managed to find a better workaround than restarting the PC though. If I kill the "Windows Subsysem for Linux Preview" process then WSL stops. I then have to manually start the LxssManager process which appears to have stopped (maybe this is the cause of the issue?). Once I do this, I can once again start WSL as if nothing had happened.

I note that LxssManager is set to start "Manual". I don't know if this is the correct setting, but then I can't change it to "Automatic" as I get an error "Access Denied" if I try. Any comments on this front are welcome...

@cringegnere
Copy link

Same issue here on my laptop after hibernation.
Windows 11 21H2 Build 22000.978

@JoshuaJWilborn
Copy link

Having the same issue. Build 22000.978

@OrangePixelLtd
Copy link

Started happening to me just after the last windows update. Build 22000.978

@gyaaniguy
Copy link

This time I managed to find a better workaround than restarting the PC though. If I kill the "Windows Subsysem for Linux Preview" process then WSL stops. I then have to manually start the LxssManager process which appears to have stopped (maybe this is the cause of the issue?). Once I do this, I can once again start WSL as if nothing had happened.

Thank you! Works for me. Key is to close all wsl* processes
image
Then start the service net start LxssManager

@vindolin
Copy link

Same problem here on Build 22000.978, wsl --shutdown appears to be hanging for about a minute but then finishes and everything works again.

@ThePlenkov
Copy link

ThePlenkov commented Sep 18, 2024

Hi everyone. I just got my problem solved by changing autoMemoryReclaim to dropcache instead of gradual. This issue seemed to be a reason. #11066. If your WSL hangs and you have Docker Desktop - just check - may be it's resource saving mode. Here is my config which works

[wsl2]
dnsTunneling=true
swap=0
memory=12GB
processors=2
[experimental]
autoMemoryReclaim=dropcache  # gradual

@heckler
Copy link

heckler commented Sep 27, 2024

Could it be that gen 11 processors and newer are affected? Or more likely to be affected.

Just chiming in that I'm on an i7-10750H and being driven mad by this issue :-(

@anodynos
Copy link

https://docs.google.com/spreadsheets/d/10ML3KBdtINHYe8rSvat7JR_luVf1IeSammuAGVI983Q/edit#gid=0

Could it be that gen 11 processors and newer are affected? Or more likely to be affected.

Just chiming in that I'm on an i7-10750H and being driven mad by this issue :-(

Interesting, I was somehow convinced it was the CPU generation that had a role, at least in my case it did. Can you please add to https://docs.google.com/spreadsheets/d/10ML3KBdtINHYe8rSvat7JR_luVf1IeSammuAGVI983Q/edit#gid=0 ?

@heckler
Copy link

heckler commented Sep 30, 2024

Interesting, I was somehow convinced it was the CPU generation that had a role, at least in my case it did. Can you please add to https://docs.google.com/spreadsheets/d/10ML3KBdtINHYe8rSvat7JR_luVf1IeSammuAGVI983Q/edit#gid=0 ?

Done!

Just noticed that the spreadsheet does not capture the WSL distro - I took the liberty of adding a new column to capture that information, but feel free to delete it if you think it is irrelevant.

Note though that there is a documented issue with Ubuntu 24.04 which is similar to this one (in the symptoms at least), documented here). I had faced that issue, but everything was good for me since moving to 22.04, until last week, when I started seeing this problem after an apt update+upgrade (which may or may not be related)

@stevenh
Copy link

stevenh commented Oct 4, 2024

Just had an similar issue where all WSL processes crashed on resume from hibernation which includes: terminal sessions, docker desktop and all VS Code sessions started from WSL.

Eventually I could start a new sessions but not straight away, there were lots of errors from RestartManager in the log, but no new history events from windows update.

I couldn't get VS Code to restart without a reboot as it complained about missing wsl directories.

After a reboot terminal gave an error about missing default session and I had to reconfigure.

I suspect something performed some updates and didn't restore tihngs correctly, but I can't find out what, nothing in update history.

@stevenh
Copy link

stevenh commented Oct 4, 2024

Actually even though its not listed in Settings -> Windows Update -> Update History it did apply an update. I found it in Event Viewer -> Windows Logs -> Application

Beginning a Windows Installer transaction: C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.3.24.0_x64__8wekyb3d8bbwe\wsl.msi. Client Process Id: 24404.
Product: Windows Subsystem for Linux -- Installation completed successfully.
Windows Installer installed the product. Product Name: Windows Subsystem for Linux. Product Version: 2.3.24.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
Ending a Windows Installer transaction: C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.3.24.0_x64__8wekyb3d8bbwe\wsl.msi. Client Process Id: 24404.

So in my case it had applied a WSL upgrade, without prompting or any sign in the main update history but that seems to be triggered when the machine starts up, its likely not limited to hibernation but as hibernation is the only time that existing sessions would be running it's the one people will likely see more adverse effects.

I wonder if some of the other reports are caused by these silent updates?

@grochoge
Copy link

grochoge commented Oct 8, 2024

I'm running into this even without a hibernate.

If I analyze wait chain on wslservice.exe (from the Task Manager details tab), I see it waiting for dllhost.exe. I can end the dllhost.exe thread from there and WSL starts working again, but will eventually stop due to waiting on the same dllhost.exe thread.

Doing a stack trace of that thread, it's stuck on vp9fs.dll:

ntoskrnl.exe!KiSwapContext+0x76
ntoskrnl.exe!KiSwapThread+0x500
ntoskrnl.exe!KiCommitThreadWait+0x14f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!KiSchedulerApc+0x3bd
ntoskrnl.exe!KiDeliverApc+0x391
ntoskrnl.exe!KiSwapThread+0x827
ntoskrnl.exe!KiCommitThreadWait+0x14f
ntoskrnl.exe!KeWaitForAlertByThreadId+0xc4
ntoskrnl.exe!NtWaitForAlertByThreadId+0x30
ntoskrnl.exe!KiSystemServiceCopyEnd+0x25
ntdll.dll!NtWaitForAlertByThreadId+0x14
ntdll.dll!TppBarrierAdjust+0xfa
ntdll.dll!TpWaitForIoCompletion+0x34
vp9fs.dll!wil::details::DestroyThreadPoolIo<1>::Destroy+0x12
vp9fs.dll!p9fs::Plan9FileSystem::`vector deleting destructor'+0x116
vp9fs.dll!Microsoft::WRL::Details::RuntimeClassImpl<Microsoft::WRL::RuntimeClassFlags<2>,1,0,0,IPlan9FileSystem>::Release+0x42
combase.dll!<lambda_ef8a5b5bdab9c6b69f38e6b21c5d3987>::operator()+0xbb
combase.dll!ObjectMethodExceptionHandlingAction<<lambda_ef8a5b5bdab9c6b69f38e6b21c5d3987> >+0xe
combase.dll!CStdIdentity::ReleaseCtrlUnk+0x81
combase.dll!CStdMarshal::DisconnectWorker_ReleasesLock+0x4d8
combase.dll!CStdMarshal::Disconnect+0xf1
combase.dll!CRemoteUnknown::RemReleaseWorker+0x77e
RPCRT4.dll!Invoke+0x73
RPCRT4.dll!Ndr64StubWorker+0xb0b
RPCRT4.dll!NdrStubCall3+0xc9
combase.dll!CStdStubBuffer_Invoke+0x60
combase.dll!ObjectMethodExceptionHandlingAction<<lambda_c9f3956a20c9da92a64affc24fdd69ec> >+0x43
combase.dll!DefaultStubInvoke+0x1ee
combase.dll!SyncServerCall::StubInvoke+0x26
combase.dll!ServerCall::ContextInvoke+0x403
combase.dll!DefaultInvokeInApartment+0xad
combase.dll!ComInvokeWithLockAndIPID+0xaf6
combase.dll!ThreadInvokeWorker+0x7c4
combase.dll!ThreadInvoke+0x9
RPCRT4.dll!DispatchToStubInCNoAvrf+0x18
RPCRT4.dll!RPC_INTERFACE::DispatchToStubWorker+0x1a6
RPCRT4.dll!RPC_INTERFACE::DispatchToStubWithObject+0x186
RPCRT4.dll!LRPC_SCALL::DispatchRequest+0x16f
RPCRT4.dll!LRPC_SCALL::HandleRequest+0x7f8
RPCRT4.dll!LRPC_ADDRESS::HandleRequest+0x341
RPCRT4.dll!LRPC_ADDRESS::ProcessIO+0x89e
RPCRT4.dll!LrpcIoComplete+0xc2
ntdll.dll!TppAlpcpExecuteCallback+0x260
ntdll.dll!TppWorkerThread+0x456
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

@OneBlue
Copy link
Collaborator

OneBlue commented Oct 8, 2024

@grochoge: Thank you for sharing this stack, this is super interesting. This is a bug that we fixed in 2.3.24. Can you try to update to the latest version and see if that solves the issue for you ?

@grochoge
Copy link

@OneBlue So far 2.3.24 does seem to have fixed the issue!

I'm not sure if it's the same as the original issue (since I was seeing it before hibernating as well), but FWIW it appears to be working after hibernate as well.

@anikishov
Copy link

anikishov commented Oct 16, 2024

Hi,

I see same behavior on the latest version of wsl

wsl --version
Версия WSL: 2.3.24.0
Версия ядра: 5.15.153.1-2
Версия WSLg: 1.0.65
Версия MSRDC: 1.2.5620
Версия Direct3D: 1.611.1-81528511
Версия DXCore: 10.0.26100.1-240331-1435.ge-release
Версия Windows: 10.0.19045.3570

cat .wslconf

[wsl2]
swap=0
[experimental]
autoMemoryReclaim=gradual #dropcache

Image

WSL not respond to the --shutdown command, only restarting the laptop can help.

@anikishov
Copy link

anikishov commented Oct 17, 2024

Hi,

I see same behavior on the latest version of wsl

wsl --version
Версия WSL: 2.3.24.0
Версия ядра: 5.15.153.1-2
Версия WSLg: 1.0.65
Версия MSRDC: 1.2.5620
Версия Direct3D: 1.611.1-81528511
Версия DXCore: 10.0.26100.1-240331-1435.ge-release
Версия Windows: 10.0.19045.3570

cat .wslconf

[wsl2]
swap=0
[experimental]
autoMemoryReclaim=gradual #dropcache

Image

WSL not respond to the --shutdown command, only restarting the laptop can help.

I tried to use "dropcache", but the next day after restarting the laptop, the result was the same. I open the laptop and the WSL stops after about 60 minutes.

[wsl2]
swap=0
[experimental]
autoMemoryReclaim=dropcache #gradual

@heckler
Copy link

heckler commented Oct 17, 2024

Update: I still face this issue on version 2.3.24.0

Primarily when starting or stopping WSL, so I try to keep it always running. If I face the issue, it tends to resolve itself without intervention after 10-15min, but the host machine is unusable until it does.

@Bravehartk2
Copy link

Same here. After closing the notebook over night WSL hangs after spawning from hibernation and mounts from within the distro (f.e. /mnt/c) aren't available anymore.

PS C:\Users\MYUSER\Downloads> wsl --version
WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.2033

Docker Desktop is installed on version 4.23.0 (120376).

But wsl --shutdown works for me. Afterwards everything works again. But this workaround is annoying.

@anodynos
Copy link

anodynos commented Nov 12, 2024

Interesting, I was somehow convinced it was the CPU generation that had a role, at least in my case it did. Can you please add to https://docs.google.com/spreadsheets/d/10ML3KBdtINHYe8rSvat7JR_luVf1IeSammuAGVI983Q/edit#gid=0 ?

Done!

Just noticed that the spreadsheet does not capture the WSL distro - I took the liberty of adding a new column to capture that information, but feel free to delete it if you think it is irrelevant.

Its absolutely great, the more info the better! Thanks.

TBH I started it about a year ago, but hasnt had the traction & user contrinutions I would think it would.... It needs more columns for sure.... when I started it I thought the CPU generation was the issue, but I think its not....

Note though that there is a documented issue with Ubuntu 24.04 which is similar to this one (in the symptoms at least), documented here). I had faced that issue, but everything was good for me since moving to 22.04, until last week, when I started seeing this problem after an apt update+upgrade (which may or may not be related)

Interesting, cause I have both Ubuntu 22.4 & 24.4 installed and running, and hibernate works great on my new HP Omen Laptop

i5-13500HX
Windows 11 Pro 24H2

PS C:\Users\agelo> wsl --version
WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.2161

BTW, I'll add it to the sheet ;-)

@paulosincos
Copy link

So... +1 with the same problem here... hehe

@Crypto-Spartan
Copy link

For anyone seeking a temporary solution: https://github.com/carlfriedrich/wsl-kernel-build

@borjamunozf
Copy link

Yes. We have deployed the patched kernel to more than six developers and the problem is gone.

For anyone seeking a temporary solution: https://github.com/carlfriedrich/wsl-kernel-build

It's the only solution available.

@tiago-s-vieira-alb
Copy link

Workaround for me:
taskkill /f /im wslservice.exe

@springjools
Copy link

springjools commented Nov 20, 2024 via email

@snoecker
Copy link

my WSL updated to 2.3.26 , if anyone is frisky about testing it. At this point I've accepted it will never be fixed and just pop in here every few months to see if just maybe it might have.

@uqiu
Copy link

uqiu commented Dec 1, 2024

https://github.com/gardengim/keepwsl

add a service to keeping wsl awake when windows sleep may help.

@jp06
Copy link

jp06 commented Dec 4, 2024

So, this has been around for years :D ... I didn't want to shut down but want to turn off lights in PC, so I tried hibernating.

I just encountered this a while ago, I didn't restart but WSL seems to become responsive again after terminating WSL in Task Manager.


Workaround for me: taskkill /f /im wslservice.exe

@tiago-s-vieira-alb I think this is more convenient. Will try this later, thanks!

@Bravehartk2
Copy link

Bravehartk2 commented Dec 4, 2024

So, this has been around for years :D ... I didn't want to shut down but want to turn off lights in PC, so I tried hibernating.

I just encountered this a while ago, I didn't restart but WSL seems to become responsive again after terminating WSL in Task Manager.

Workaround for me: taskkill /f /im wslservice.exe

@tiago-s-vieira-alb I think this is more convenient. Will try this later, thanks!

You can simply run

$> wsl --shutdown

on a administrative PowerShell as well.

But this is just a work around.

@grochoge
Copy link

grochoge commented Dec 4, 2024

I just ran into this, although it was quite a while after resuming from hibernation so I'm not sure it's the same.
I tried enabling the debug console, but don't see anything printed from the issue.

I used the hcdiag crash command on the WSL instance and see the following output in the debug console:

[20318.376833] NMI: PCI system error (SERR) for reason ff on CPU 0. 
[20318.376835] Dazed and confused, but trying to continue

So the kernel is still there to some extent. Is there a way to actually get a backtrace from this?

@grochoge
Copy link

grochoge commented Dec 4, 2024

On normal Ubuntu the watchdog will trigger a backtrace on soft lockup (e.x. if a realtime task is monopolizing the CPU). It doesn't look like the watchdog is enabled on the WSL kernel?

Also is there any documentation on creating a crash dump/debugging the WSL2 Linux kernel?

I am planning to try the following:
Enabling the debug console in WSL settings
Creating /etc/sysctl.d/20-panic.conf

kernel.panic_on_unrecovered_nmi = 1
kernel.unknown_nmi_panic = 1
kernel.oops_all_cpu_backtrace = 1

Restarting WSL to apply changes
When the problem happens, using hcsdiag list to get the GUID for WSL, then running hcsdiag crash to crash WSL.

It seems to only print a backtrace for CPU 0 though, so I'm not sure this will be sueful.

@Crypto-Spartan
Copy link

So, this has been around for years :D ... I didn't want to shut down but want to turn off lights in PC, so I tried hibernating.
I just encountered this a while ago, I didn't restart but WSL seems to become responsive again after terminating WSL in Task Manager.

Workaround for me: taskkill /f /im wslservice.exe

@tiago-s-vieira-alb I think this is more convenient. Will try this later, thanks!

You can simply run

$> wsl --shutdown

on a administrative PowerShell as well.

But this is just a work around.

wsl --shutdown normally doesn't work if the process is really stuck, but taskkill /f /im wslservice.exe almost always works

@bjanders
Copy link

bjanders commented Dec 4, 2024

I just ran into this, although it was quite a while after resuming from hibernation so I'm not sure it's the same. I tried enabling the debug console, but don't see anything printed from the issue.

@grochoge For me it always happens about 30-40 minutes after resuming from hibernation.

@jp06
Copy link

jp06 commented Dec 5, 2024

Can confirm this also worked for me: https://github.com/carlfriedrich/wsl-kernel-build

@eiriklid
Copy link

eiriklid commented Dec 6, 2024

This is a long shot, but I will tag the top contributors to this repo to see if they are aware of this issue, and that a fix has existed in https://github.com/[carlfriedrich/wsl-kernel-build](https://github.com/carlfriedrich/wsl-kernel-build) for 6 months now.

@OneBlue and @craigloewen-msft.

@grochoge
Copy link

I had WSL2 freeze again, not after a hibernation though.

I sent the crash command from hcsdiag and saw some backtrace printed to the debug console, but it closed the window before I could read it :-(. Is the debug console output logged anywhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests