microsoft
WSL Freezing 0x8007274c
Windows Version
10.0.22621.1413
WSL Version
1.1.3.0
Are you using WSL 1 or WSL 2?
- [X] WSL 2
- [ ] WSL 1
Kernel Version
5.15.90.1-microsoft-standard-WSL2
Distro Version
Ubuntu 22.04.1 LTS
Other Software
- Docker Desktop (Windows) version 4.17.0
- PhpStorm 2022.3.3
- WebStorm 2022.3.3
Versão do WSL: 1.1.3.0
Versão do kernel: 5.15.90.1
Versão do WSLg: 1.0.49
Versão do MSRDC: 1.2.3770
Versão do Direct3D: 1.608.2-61064218
Versão do DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows versão: 10.0.22621.1413
Repro Steps
Every that I set up my development applications (such as Docker, PhpStorm, WebStorm, etc), it starts to happen repeatedly throughout the day.
- start Ubuntu in WSL along with the others apps
- use it for a while
- after some time, if I try to open a new WSL terminal, I got
Error code: Wsl/Service/0x8007274c - PhpStorm and WebStorm start to report failed connection attempts to WSL as well (e.g. during sync git status)
Additional Information:
I started to experience it since from Windows 10 22H2 update. After a while, I did a fresh Windows 11 install, and the behavior is still happening.
Expected Behavior
Terminals and apps work without hangs.
Actual Behavior
- WSL terminals stucked
- high CPU on VmmemWSL Windows background process
- apps that needs to connect with WSL cannot work properly
To be able to continue to work:
- wsl --shutdown (sometimes, multiple times)
- Docker desktop has to be restarted
Diagnostic Logs
No response
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!
![microsoft-github-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/95686?v=4 "Published by a pub.dev verified publisher"){kind=small}
I had the same issue when running a amazonlinux container in WSL. As long as the container was up, i was not able to open a second WSL instance in Windows.
Thanks @andersonams. Looking at the logs, it looks like the issue is that WSL is out of memory.
Does increasing wsl2.memory to let's say 8GB help ?
Thanks @andersonams. Looking at the logs, it looks like the issue is that WSL is out of memory.
Does increasing
wsl2.memoryto let's say 8GB help ?
So, after the fresh Windows 11 install, I tried the "free memory" mode, with no explicit configuration on the .wslconfig before and I was seeing the same behavior. Same as well when I put 8GB.
With no explicit configuration, the VmmemWSL process almost hits 8GB of usage (the PC has 16GB total), but with the same behavior that I described.
While I was trying to found a solution through internet, I saw some hints to put guiApplications=false into .wslconfig. But, it did not help too much. Only the high CPU usage of VmmemWSL was mitigated.
Docker Command Error in WSL
When running the command docker scout quickview in Windows Subsystem for Linux (WSL), I encountered the following error:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Error code: Wsl/Service/0x8007274c
Press any key to continue...
[process exited with code 4294967295 (0xffffffff)] You can now close this terminal with Ctrl+D, or press Enter to restart.
WslLogs-2024-03-14_21-38-38.zip
This is happening to me constantly lately. since I started working on a project where I need to run front-end and back-end servers at the same time, and one docker container running a postgreSQL and I'm coding with VsCode, my machine got 16Gb RAM, and I'm not using .wslconfig, but I read the WSL docs and it tells me that the default RAM is 50% windows RAM, so I think maybe the problem is not a RAM problem, maybe something with vscode and/or some plugin.
I'm having the same issue, trying to run a frontend in WSL, while the Windows based backend runs some docker containers.
Continuing to be a problem, after turning my computer on and opening the Ubuntu app, I get
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Error code: Wsl/Service/0x8007274c
Press any key to continue...
So far, the only workaround I have found is to open a cmd prompt and run wsl --shutdown and restart WSL
I had forgotten about this thread, but for what it's worth, I think I fixed it by reinstalling WSL and some related tools.
I also get this sporadically. This issue report mentioned vscode as a contributing factor, and I was able to confirm that killing the vscode instance which had been open for a long time (with C++ intellisense plugin) which had a wsl2 remote directory open, fixed the problem. Not sure what the underlying issue is, though.
I tried giving more memory to WSL and this worked for me, just create a file named .wslconfig on your %UserProfile% folder on windows and set this config
[wsl2]
memory=10GB
restart WSL and maybe this works for you too.
Getting same error all the time. Can't work with vscode Terminal.
Found this issue while having the same problem with no opening of WSL terminal impossible. Reason: Cause of Error code: Wsl/Service/0x8007274c The error:
Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat.
Fehlercode: Wsl/Service/0x8007274c
[Verarbeitung des Prozesses mit Code 4294967295 (0xffffffff) beendet]
Sie können dieses Terminal jetzt mit STRG+D schließen oder zum Neustart die EINGABETASTE drücken.
sudo dmesg --follow
kworker/0:3: page allocation failure: order:7, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
Tainted: [W]=WARN
Workqueue: hv_pri_chan vmbus_add_channel_work
Call Trace:
<TASK>
dump_stack_lvl+0x76/0xc0
warn_alloc+0x143/0x1b0
__alloc_pages_slowpath+0xe4e/0xee0
__alloc_pages_noprof+0x257/0x350
vmbus_open+0x8c/0x160
? __cfi_hvs_channel_cb+0x10/0x10
hvs_probe+0x20f/0x390
vmbus_probe+0x4b/0xa0
really_probe+0x135/0x3a0
driver_probe_device+0x87/0x1d0
__device_attach_driver+0x118/0x130
? __cfi___device_attach_driver+0x10/0x10
bus_for_each_drv+0x148/0x180
__device_attach.llvm.7042910400676041000+0xaf/0x130
bus_probe_device+0xb6/0x140
device_add+0x28d/0x490
vmbus_device_register+0x84/0x110
vmbus_add_channel_work+0xc1/0x250
process_scheduled_works+0x1dd/0x410
worker_thread+0x30e/0x3c0
? __cfi_worker_thread+0x10/0x10
kthread+0x15b/0x180
? __cfi_kthread+0x10/0x10
ret_from_fork+0x48/0x60
? __cfi_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Mem-Info:
wsl --version
WSL-Version: 2.4.11.0
Kernelversion: 5.15.167.4-1
WSLg-Version: 1.0.65
MSRDC-Version: 1.2.5716
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.26100.3194
Similar unsolved issues:
- #9852
- #11612
- #10174
Estuve teniendo muchos problemas similares con esto, pero lo que hice fue buscar el archivo .wslconfig en el perfil del usuario de Windows, lo renombré, lancé nuevamente el comando wsl --install y funcionó correctamente.
For me, the problem was that I had several instances running in the background. I did a CTRL+ALT+DELETE, opened taskmanager and closed all instances of WSL2. Then I was able to start it up.
For me, the problem was that I had several instances running in the background. I did a CTRL+ALT+DELETE, opened taskmanager and closed all instances of WSL2. Then I was able to start it up.
Thank's man, This work for me.
For me, the problem was that I had several instances running in the background. I did a CTRL+ALT+DELETE, opened taskmanager and closed all instances of WSL2. Then I was able to start it up.
My instances were VMs that I had not considered, installed by Podman desktop, apart from those I already had. I shut them all down using:
wsl --shutdown
or
wsl --shutdown --force
