WSL2-Error: A connection attempt failed on Windows 19555.1001

[ad-on-is]

After updating to Windows 19555 I get the following error, when starting WSL:

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.

PS C:\Users\add> wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-19.10 (Default)
docker-desktop
docker-desktop-data
PS C:\Users\add> wsl -d Ubuntu-19.10
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.
PS C:\Users\add> wsl -d docker-desktop
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.
PS C:\Users\add>

Update

I wanted to try this workaround on a fresh Alpine, https://github.com/microsoft/WSL/issues/4371#issuecomment-521107556 but neither /bin nor /sbin were symlinks.

[NaiveTomcat]

I might have figured out a workaround by shutting down and restart wsl.

Only workable in Powershell.

see #4866

And my %PATH% length is 1054 chracters

[balcsida]

Hi,

I just also wanted to confirm that reducing the path variable length works: I had a PATH with the length of 1330 character and reducing it to 1005 characters makes WSL2 work again.

I also tried the tip shared by @lengthmin, but it didn't work for me, unfortunately.

[Xepol]

Roll back was the only solution here. Reducing path <1000 chars (and even rebooting) had no effect. Thankfully I backed up my .vhdx before I rolled back here, because rolling back destroyed all my wsl installs.

So, shut down the lsxx service, copy out the .vhdx files for anything that matters, rollback. Reinstall any required WSL installations, create your users, then shut down lsxx service again, copy back your .vhdx files and you should be back exactly where you were.

Not quite 15 minutes because of the copying (my .vhdx is quite large), but still better than the wall of hurt this bug (whatever it is) causes.

[JMBBunch]

It appears the remaining problem (VS Code with WSL) has been narrowed down to the Remote - WSL extension (at least that is what a bot reported), and this is the link to the issue as reported there:
https://github.com/microsoft/vscode-remote-release/issues/2272

[JMBBunch]

Here's a workaround for those who don't want to roll back Win10 to use VS Code with WSL:

First, shorten the PATH enough to ensure WSL can run again. Then, shorten it some more (probably a lot) to get VS Code to run.

I could not get my Windows PATH pruned enough to risk breaking what I need in Windows. 391 in Windows and 471 in WSL were still too long. Instead, reset the PATH for the session by starting up WSL within Powershell:

1. Open Powershell.
2. $Env:PATH="C:\Users\username\AppData\Local\Microsoft\WindowsApps;C:\Users\username\AppData\Local\Programs\Microsoft VS Code\bin;"
3. C:\windows\system32\wsl.exe The prompt changes to WSL, sitting at /mnt/c/WINDOWS/system32 3a. Optional: check your WSL path: echo $PATH You'll see your new short Windows path tacked onto the usual Linux pathing.
4. Change to the WSL folder you want VS Code to open: cd ~
5. Run VS Code: code . Woo hoo! We have WSL folders in VS Code again!

Hope this helps someone!

[therealkenc]

Equivalent in cmd.exe is setPATH=<min path you need for interop>. [Contrast setx.]

[chensjlv]

To help people, I think you still need vscode path in your $PATH for the vscode server to launch. I tuned it so it works for both powershell and vscode. Remember to backup your old path! Here are my configs

User's Path

C:\Users\{youusername}\AppData\Local\Programs\Microsoft VS Code\bin;

System's path

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program Files\PowerShell\6\;

[LiamKarlMitchell]

So how to fix this?

Okay, I deleted everything in my user and system environment path variables apart from this from the System one just in-case. %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

After a reboot Ubuntu appears to run.

To get docker to work again you need to add this to your path for User/System. C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin

But I don't have WSL docker endpoint? docker context ls

Edit: Okay, disabling Apply & Restart then re-enabling and clicking Apply & Restart showed a prompt to enable WSL Intergration. I said yes and now I see the WSL INTERGRATION menu under Docker Desktops settings for Resources (I had not previously seen this part) so it seems that the length of the PATH variables was somehow causing a problem.

Still no WSL docker context showing up however like this guide has. https://www.hanselman.com/blog/DockerDesktopForWSL2IntegratesWindows10AndLinuxEvenCloser.aspx

Expect to see: wsl * Docker daemon hosted in WSL 2 npipe:////./pipe/docker_wsl

I'm going to switch to Windows Containers to see if that makes it show up as this one says I have to use Windows Containers? https://www.thomasmaurer.ch/2019/08/run-linux-containers-with-docker-desktop-and-wsl-2/

Still no luck and now the integration menu has vanished.

Can someone please refer me to a guide that works I just want to run up docker-compose to spin up Linux containers from windows with shared volumes so I can edit code but using WSL2 so its fast?

[aeschli]

I pushed new versions of the Remote - WSL extension (0.41.9, 0.42.3) with a workaround to overcome the PATH length issues (the extension uses a empty PATH when internally calling wsl.exe).

[keevan]

Just wanted to link this blog post I found useful regarding the suggested 'spring clean' https://peter.hahndorf.eu/blog/BloatedPathVariable.html

Essentially the command to list out all the paths is:

($env:path -split ";") | ? {if (Test-Path ([System.Environment]::ExpandEnvironmentVariables("$_"))){Write-Host $_}else{Write-Host $_ -f red}}

The quick fix to get it loading (by overriding the PATH) worked for me, but I'm currently seeing if I can clean up my PATH length enough to get it to work.

Edit: I started from a length of 2000+, still not working at 960 Got it working at 844

$Env:Path.length

[lucyllewy]

There's something more than simple length of the PATH variable, because I'm down well below where others have managed to get it working at 536 characters yet it still isn't able to launch here with the message as reported by others:

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.

My PATH variable now contains:

C:\Users\yabea> $env:path -split ";"
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\Program Files\PowerShell\6\
C:\HaxeToolkit\haxe
C:\HaxeToolkit\neko
C:\Program Files (x86)\GnuPG\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files\Git\cmd
C:\Program Files\dotnet\
C:\Program Files\Docker\Docker\resources\bin
C:\ProgramData\DockerDesktop\version-bin
C:\Users\yabea\AppData\Local\Programs\Microsoft VS Code\bin
C:\Users\yabea\AppData\Local\Microsoft\WindowsApps

[NaiveTomcat]

There's something more than simple length of the PATH variable, because I'm down well below where others have managed to get it working at 536 characters yet it still isn't able to launch here with the message as reported by others:

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.

My PATH variable now contains:

C:\Users\yabea> $env:path -split ";"
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\Program Files\PowerShell\6\
C:\HaxeToolkit\haxe
C:\HaxeToolkit\neko
C:\Program Files (x86)\GnuPG\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files\Git\cmd
C:\Program Files\dotnet\
C:\Program Files\Docker\Docker\resources\bin
C:\ProgramData\DockerDesktop\version-bin
C:\Users\yabea\AppData\Local\Programs\Microsoft VS Code\bin
C:\Users\yabea\AppData\Local\Microsoft\WindowsApps

Try to shrink PATH variable to null by

$env:PATH=""

It should work and should make no influence to other application.

[rmja]

Clearing the path does not work for me:

> $env:PATH=""
> C:\Windows\System32\wsl.exe -d docker-desktop
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.

[rishdas]

Thanks, we are debugging this internally - trying to figure out why only some users are hitting this.

Thanks I am facing this issue too

[rishdas]

I am facing the same issue funny though I am not facing this issue on Windows Installation with a VM Anyways switching to WSL (1) for now. Please update once we have solution

[benhillis]

@rishdas - The best thing to do would be to roll back to the previous build until a new Fast build is out with the fix.

[gianugo]

FYI - my path is 602 characters and I'm still getting the same error. The one (possible and minor) difference: I upgraded my distro to WSL2 after upgrading to 19555. Since then it didn't start anymore, and no shortening of %PATH% seems to be helping. I'm on corpnet, happy to provide access to my machine if it could help debugging.

[24githubs]

I recently had to reinstall window , The only thing that finally worked for me!!

version 2004 (OS Build 19555,1001)

[pbellusci]

Same Problem here, I really can't believe how you play with our environments. Don't you have a QA department to test all of this things? I'm contractor, who will pay for the hours that I'll have to lose to fix this?.

C'mon, be professional guys, for once in life.

[gel-mashup]

Same Problem here, I really can't believe how you play with our environments. Don't you have a QA department to test all of this things? I'm contractor, who will pay for the hours that I'll have to lose to fix this?.

C'mon, be professional guys, for once in life.

we are in fast ring. these things are expected.. i suggest stop your update at 19551 or move to slow ring (slow ring version now supports wsl2)

[pauljmelia]

Also having this issue; reduced the length of my %PATH% below 500 and still couldn't get docker-desktop to start, reverted to previous build and paused updates for a week.

[rikkit]

Same Problem here, I really can't believe how you play with our environments. Don't you have a QA department to test all of this things? I'm contractor, who will pay for the hours that I'll have to lose to fix this?.

By volunteering for fast ring you volunteered to join the QA department.

[jmar5439]

I discovered a workaround that is working in my system. I have Windows 10 PRO Versión 10.0.19041 compilación 19041. I 've installed WSL 2 and configured Docker to work with wsl2. Seems like docker is interfering some way and some processes are not managed correctly ( specially Docker Desktop Service). In order to start WSL 2 , I turned off docker, I disabled "Docker auto start" and "Windows Fast start up".

net stop docker
 net stop com.docker.service 

[MWaser]

This really sucks for me as I've just joined the Insider program and don 't have a previous version to roll back to. What can people like me do?

Actually, if I roll back and switch to slow ring -- will that work? I'm trying that now and will report back.

[pbellusci]

Same Problem here, I really can't believe how you play with our environments. Don't you have a QA department to test all of this things? I'm contractor, who will pay for the hours that I'll have to lose to fix this?.

By volunteering for fast ring you volunteered to join the QA department.

No way. Rule #1 of software development... TEST things before push anything. We're in 2020, we have a tons of tools for testing.

This is not serious.

[TeamDman]

The insiders program is part of the testing, for before features are pushed to the masses.

I'd argue that it's irresponsible/unprofessional to depend solely on the stability of insiders to do your job, especially when virtual box + remote-ssh in vscode works just as well as wsl remoting does.

That's not to say that this issue isn't an inconvenience, but the entitlement being displayed here by many is laughable.

[cmeiklejohn]

Just ran into the problem, was able to revert to 19551 and get it working again.

[ad-on-is]

The insiders program is part of the testing, for before features are pushed to the masses.

I'd argue that it's irresponsible/unprofessional to depend solely on the stability of insiders to do your job, especially when virtual box + remote-ssh in vscode works just as well as wsl remoting does.

That's not to say that this issue isn't an inconvenience, but the entitlement being displayed here by many is laughable.

Well, after WSL2 was realesed, users tested and loved it, in the way that it works right now. Since it's functionalities proved to be reliable and usable for daily work, we adopted it into our dev-environments. So we expect at least the core features to work, which already have been tested and verified. And we can at least expect that, can't we? It's not like we're whining and crying about some announced and untested nice-to-have features.

[benhillis]

Not to split hairs, but WSL2 has still not officially "released" - It is still only in Insider builds.

If you are on the Fast ring you will occasionally be impacted by bugs in WSL or other components. Having insiders test pre release versions of Windows is invaluable, and catches things like this that were missed during testing. Rolling back builds takes minutes, it is no great hardship.

[benhillis]

Unfortunately 19559 does not have the fix, the build snapped before it was ready.

[craigloewen-msft]

Windows Insider build 19546 is out today and has a fix for this issue. Please give it a try and let us know if this is resolved for you!

[magneticflux-]

Build 19564 resolved the issue for me.

[n3dst4]

Fixed for me.

[ad-on-is]

Yep, 19564 fixed it!

[appurist]

Thanks so much. I can confirm that the fast ring update does address the issue. And I can confirm that WSL2 is available on the Windows Insiders slow ring.

Any idea when we might see this fix on the slow ring?

[philwilliammee]

fixed for me too thanks

[benhillis]

@appurist - This bug has never made it to the slow ring.

[appurist]

@benhillis Sorry I misread your answer with my first reply (read "never" as "not yet"). Thanks for pointing that out. The slow ring has WSL2 already, correct?

I guess this issue is ready to be closed. ;)

[OpenWaygate]

I have fixed this problem in 19555.1001 by reducing $Env:Path.length, today my system update to 19559.1000 and I find a problem but I'm not sure whether it exists in 19555.1001.

The bash works only with Administrator.

[SonicGD]

I'm on 19564 and still see this issue in windows terminal:

Only 1 of those 7 tabs opened normally, all 6 others with [process exited with code 1] error.

[sebagomez]

Don't know if totally related but I'm also on 19564.1005 but I still have an error starting Docker

Docker.Core.Backend.BackendException:
Timed out waiting for the lifecycle-server to start.
This may be the result of a slow environment or there may be a real problem.
This timeout can be increased by editing settings.json, value 'lifecycleTimeoutSeconds'.
This file is usually in C:\Users\(your username)\AppData\Roaming\Docker
   at Docker.Core.Pipe.NamedPipeClient.<TrySendAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Docker.Core.Pipe.NamedPipeClient.Send(String action, Object[] parameters)
   at Docker.Actions.DoRestartVM(Settings previousSettings)
   at Docker.Actions.<>c__DisplayClass34_0.<RestartVM>b__0()
   at Docker.ApiServices.TaskQueuing.TaskQueue.<>c__DisplayClass18_0.<.ctor>b__1()

  System.TimeoutException:
  Timed out waiting for the lifecycle-server to start.
This may be the result of a slow environment or there may be a real problem.
This timeout can be increased by editing settings.json, value 'lifecycleTimeoutSeconds'.
This file is usually in C:\Users\(your username)\AppData\Roaming\Docker
     at Docker.Backend.LifecycleClient.WaitForServerUp(TimeSpan pingTimeout)
     at Docker.Backend.ContainerEngine.WslEngine.DoStart(Settings settings, String daemonOptions, Credential credential)
     at Docker.Backend.ContainerEngine.WslEngine.Restart(Settings settings, String daemonOptions, Credential credential)
     at Docker.Backend.BackendNamedPipeServer.<Run>b__8_3(Object[] args)
     at Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass9_0.<Register>b__0(Object[] parameters)
     at Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters)

[haydenrou]

I'm also on 19564 and am still struggling to open WSL #4892

[ShadowEO]

Same as @haydenrou, updated to 19564 and can't open at all, though in my case, I can't even get a WSL session to start even after butchering the path variable to null now. Still getting "A connection attempt failed" with a blank PATH now.

[Coldrain1232008]

Same as above. I'm 19564.1005 with [process exited with code 1] error.

[LunchWithaLens]

This is working for me again now - 19564 Insider Preview. I had trimmed down my $PATH in earlier builds with no success. It did take a while to start though.

[haydenrou]

4892 is still broken in 19569, any update?

[sebagomez]

I'm also on 19569 and the error I published before was still occurring (https://github.com/microsoft/WSL/issues/4860#issuecomment-586294413)

Fixed it by uninstalling and installing the Docker Client back again.

[tylerjkline]

Windows Insider build 19546 is out today and has a fix for this issue. Please give it a try and let us know if this is resolved for you!

Did NOT fix for me, was working fine until I shutdown WSL2 and tried to restart it for other things, I'm running build 19569.

[mafshin]

On Build 19559.1000 and WSL2 complained to start, but upgrading to 19577.1000 fixed that :-)

[pkostelnik]

No Problem anymore with WSL2 since 19582