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.

[olafkfreund]

Same problem here. All the WSL1 instances are working.

[gel-mashup]

i got this bug, i am using ubuntu 18.04 distro and i cant seem to start wsl2 instance

[FabienD]

Hi,

+1, VSCode can't established connection.

• VSCode Version: 1.42.0-insiders or stable 1.41.1
• Local OS Version: Microsoft Windows [Version 10.0.19555.1001]
• Remote OS Version: Ubuntu 18.04
• Remote Extension/Connection Type: WSL
• WSL Version: 2

[FabienD]

Hi,

For me, uninstalled / re-install openssh-server on the linux host fix the connection issue.

cf. https://docs.microsoft.com/fr-fr/windows/wsl/troubleshooting

[benhillis]

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

[briandenicola]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved.

PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

[ad-on-is]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved.

PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

Sorry, but this is absolutely no workaround. There are obvious reasons why we use v2 and not v1.

[briandenicola]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved. PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

Sorry, but this is absolutely no workaround. There are obvious reasons why we use v2 and not v1.

I'm not sure why the down vote on my comment. I should made myself clear in that post I'm speaking for myself and not in any official capacity from Microsoft. I was trying to be helpful to the community to folks who need to have their wsl distros up and functional.

v2 is vastly better than v1. We all love v2 but if it's a matter between up but limping along versus being down then I'll take being up while the issue is being worked on.

[ad-on-is]

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

There's really some strategic solution needed here regarding Windows 10 Updates and especially WSL.

What I mean is, yes, we opted for the Fast Ring and we know what risks we are taking as Beta-Testers. But WSL2 has become a crucial part of our work environment. Iin fact, so crucial, that we do rely more on a stable working WSL than we do on a stable Windows itself. We spend more time in WSL, Terminal and VSCode than we do with Explorer or [insert any other fancy-shmency Windows feature here].

So please, for the sake of our work and time, can you guys at MS be more careful with such updates. We really love WSL, and are looking forward to all the new features you're going to provide us with. And most importantly, we are truly thankful for that.🤘

[ad-on-is]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved. PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

Sorry, but this is absolutely no workaround. There are obvious reasons why we use v2 and not v1.

I'm not sure why the down vote on my comment. I should made myself clear in that post I'm speaking for myself and not in any official capacity from Microsoft. I was trying to be helpful to the community to folks who need to have their wsl distros up and functional.

v2 is vastly better than v1. We all love v2 but if it's a matter between up but limping along versus being down then I'll take being up while the issue is being worked on.

Since the title already says "WSL2-Error..." there's really no need to suggest a workaround for converting to v1.

It's not about which one is better. There are features that v1 can do but v2 can't, and vice versa. Depending on these features and based on our needs, we have distros running as v1 or v2, simultaneously.

[therealkenc]

For folks who can get into their WSL 2 shell on 19555, but are experiencing the "VS Code Remote - WSL" problem mentioned above (looks like screencap), you can work-around by using "VS Code Remote SSH".

[nunix]

quick questions: do you use a custom kernel? what does your .wslconfig looks like? your distro 19-10 is custom tight? do you face the same issue with a store one?

I know the team is debugging, but I got some time this error when playing around with the kernel 🤔

[ad-on-is]

quick questions: do you use a custom kernel? what does your .wslconfig looks like? your distro 19-10 is custom tight? do you face the same issue with a store one?

I know the team is debugging, but I got some time this error when playing around with the kernel

I've already reverted Windows back to the previous version. It's the official WSL-Ubuntu downloaded from the Ubuntu-Website, nothing custom and also no custom kernel here.

[JMBBunch]

I updated to Windows 10 Pro Insider Preview 19555.rs_prerelease.200127-0900 this morning. I first noticed the above issues with WSL when opening VSCode after the update (same problem with VSCode x64 v1.41.0 and 1.41.1 and I also did update its Remote - WSL extension to 0.41.7).

I have nothing of importance in my WSL so upon experiencing these symptoms (and trying the SSL-related fix mentioned above which did not help), I figured I'd get rid of the Ubuntu 18.04 LTS distro I have installed and have a fresh go at it.

Upon opening the WSL window to finish the installation, I get this:

In case I didn't paste that in right, the upshot is the new installation prompts for a new default user account, as expected. I created one ("ubuntu") and it said the password was updated successfully, but then it came back with a connection attempt failure, which looks a lot like the same problem in my previously-working setup even though that error was within VSCode's terminal window and this one is in the WSL command window: "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."

As you can see in the screenshot, I thought I'd try a different name just in case, but the same error came up and came back to another new UNIX username prompt.

In case it matters, after I updated Win10, I also installed (for the first time) the new cross-platform Powershell (6.2.4 x64). It was then I discovered VSCode couldn't open WSL.

[kobenauf]

Similar message for me. I upgraded to build 19555 and now WSL 2 is totally dead: 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. Interestingly, the icon on my taskbar that launches Ubuntu is also wrong now. It used to be a little picture of a command prompt, but now it's a white blank page. That shortcut does still open Terminal, but with the error above. From that window I can still open powershell fine, just not Ubuntu. Not to be too dramatic, but I depend on this to do my work all day long, so this is very much impacting me.

[benhillis]

@kobenauf - The roll back feature works very well and is actually quite quick.

[benhillis]

We were able to debug what the issue is here and are pushing the fix. This issue triggers if you have a somewhat a long %PATH%, so one potential workaround (until a new build comes out with the fix) would be to do some "spring cleaning" on your %PATH% variable to make it shorter.

[ad-on-is]

We were able to debug what the issue is here and are pushing the fix. This issue triggers if you have a somewhat a long %PATH%, so one potential workaround (until a new build comes out with the fix) would be to do some "spring cleaning" on your %PATH% variable to make it shorter.

By %PATH% variable you mean the user defined one within Windows?

[benhillis]

@ad-on-is - Correct.

[kobenauf]

@benhillis thanks for saying that about rolling back. I've never actually done that on Win10 and was afraid it would corrupt my system. (That happened to many, many, ... many years ago.) And you're right, it was pretty quick and it fixed the problem. Thanks!

[JMBBunch]

Reporting back: I cleaned up my PATH (there were terribly long Intel Management Engine related PATHs for both /Program Files/ and /Program Files (x86)/ so I removed the x86 ones) and rebooted. I just put Ubuntu back (from the Windows Store) and VOILA! It started fine.

However, VSCode is still showing the same error. So to get it all clean, I uninstalled/reinstalled VSCode again, and removed and reinstalled the Remote - WSL extension; no help. I also pruned my path some more and reset it from the command line (and exited and re-entered to make sure the new path was retained) and tried again - same thing. Here's VSCode's Terminal output after trying a Remote-WSL: New Window command:

[laoshancun]

same issue on 19555.1001 WSL2 Ubuntu

[benszymkow]

We were able to debug what the issue is here and are pushing the fix. This issue triggers if you have a somewhat a long %PATH%, so one potential workaround (until a new build comes out with the fix) would be to do some "spring cleaning" on your %PATH% variable to make it shorter.

Is the new build going to come out in next few days or is it going to be a week+? Just want to figure out whether to roll back or just wait

[philwilliammee]

reduced my windows $PATH length to 458 characters, WSL2 path length 637 and wsl2 started but vscode cant connect to server. same error as others https://github.com/microsoft/WSL/issues/4860#issuecomment-580967091 adding startup output below as text.

[2020-02-01 12:06:06.597] Resolving wsl+Ubuntu, resolveAttempt: 1
[2020-02-01 12:06:06.648] Starting VS Code Server inside WSL (Ubuntu)
[2020-02-01 12:06:06.648] Extension version: 0.41.7, Windows build: 19555. Multi distro support: available. WSL path support: enabled
[2020-02-01 12:06:06.795] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 12:06:16.880] Unable to detect if server is already installed: Error: Command failed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 12:06:16.880] 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.
[2020-02-01 12:06:16.880] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 26076a4de974ead31f97692a0d32f90d735645c0 stable .vscode-server 0  ' in c:\Users\USER\.vscode\extensions\ms-vscode-remote.remote-wsl-0.41.7
[2020-02-01 12:06:26.953] 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.
[2020-02-01 12:06:26.953] VS Code Server for WSL closed unexpectedly.
[2020-02-01 12:06:26.953] For help with startup problems, go to
[2020-02-01 12:06:26.953] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2020-02-01 12:06:26.965] WSL Daemon exited with code 0

[FabienD]

reduced my windows $PATH length to 458 characters, WSL2 path length 637 and wsl2 started but vscode cant connect to server. same error as others #4860 (comment) adding startup output below as text.

[2020-02-01 12:06:06.597] Resolving wsl+Ubuntu, resolveAttempt: 1
[2020-02-01 12:06:06.648] Starting VS Code Server inside WSL (Ubuntu)
[2020-02-01 12:06:06.648] Extension version: 0.41.7, Windows build: 19555. Multi distro support: available. WSL path support: enabled
[2020-02-01 12:06:06.795] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 12:06:16.880] Unable to detect if server is already installed: Error: Command failed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 12:06:16.880] 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.
[2020-02-01 12:06:16.880] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 26076a4de974ead31f97692a0d32f90d735645c0 stable .vscode-server 0  ' in c:\Users\USER\.vscode\extensions\ms-vscode-remote.remote-wsl-0.41.7
[2020-02-01 12:06:26.953] 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.
[2020-02-01 12:06:26.953] VS Code Server for WSL closed unexpectedly.
[2020-02-01 12:06:26.953] For help with startup problems, go to
[2020-02-01 12:06:26.953] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2020-02-01 12:06:26.965] WSL Daemon exited with code 0

Have you checked that SSH server runs on the host ? In my case, ssh-server wouldn't start after upgrade (few keys were missing). I don't know if it happened after Windows or Ubuntu udpates, I've done both in the same time. After uninstall openssh-server (purge), re-install it, remove all .vcode dirs, on host and window (so re-install plugins), all works fine again.

[zippaaa]

@JMBBunch

I just put Ubuntu back (from the Windows Store) and VOILA! It started fine.

~~Check, please, Wsl version: wsl -l -v Do you changed version to 2? wsl --set-version~~

UPD: Yes! I made PATH short and now WSL2 is working.

[kobenauf]

I had rolled back yesterday to 19551, which fixed the problem. At the same time I cleaned up my Windows paths as suggested above, and this morning I see Windows did the auto-update to 19555 again. This time I can indeed launch WSL 2 again.

However, I have the problem @philwilliammee posted above, that VSC won't launch. Same error as him. As @FabienD suggested, I checked if ssh server was running, and it was not. When I try to start it, I see this error:

sudo service ssh start
* Starting OpenBSD Secure Shell server sshd
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key

I ran sudo service ssh start a second time, and it started without errors.

sudo service ssh status
* sshd is running

I should point out, I've never had to do this on previous upgrades, so something is a bit different this time.

However after starting the ssh server, VSC still has the same error when it opens.

| ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 14:56:02.345] Unable to detect if server is already installed: Error: Command failed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 14:56:02.345] 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.
[2020-02-01 14:56:02.345] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 26076a4de974ead31f97692a0d32f90d735645c0 stable .vscode-server 0  ' in c:\Users\Kip Obenauf\.vscode\extensions\ms-vscode-remote.remote-wsl-0.41.7
[2020-02-01 14:56:12.422] 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.
[2020-02-01 14:56:12.422] VS Code Server for WSL closed unexpectedly.
[2020-02-01 14:56:12.422] For help with startup problems, go to
[2020-02-01 14:56:12.422] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

On Windows, I deleted C:\Users\Kip Obenauf\.vscode. When I started code . again, it told me the Remote extension wasn't installed, so it installed it. I restarted code . afterwards, but I still get the same error.

[FabienD]

I had rolled back yesterday to 19551, which fixed the problem. At the same time I cleaned up my Windows paths as suggested above, and this morning I see Windows did the auto-update to 19555 again. This time I can indeed launch WSL 2 again.

However, I have the problem @philwilliammee posted above, that VSC won't launch. Same error as him. As @FabienD suggested, I checked if ssh server was running, and it was not. When I try to start it, I see this error:

sudo service ssh start
* Starting OpenBSD Secure Shell server sshd
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key

I ran sudo service ssh start a second time, and it started without errors.

sudo service ssh status
* sshd is running

I should point out, I've never had to do this on previous upgrades, so something is a bit different this time.

However after starting the ssh server, VSC still has the same error when it opens.

| ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 14:56:02.345] Unable to detect if server is already installed: Error: Command failed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2020-02-01 14:56:02.345] 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.
[2020-02-01 14:56:02.345] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 26076a4de974ead31f97692a0d32f90d735645c0 stable .vscode-server 0  ' in c:\Users\Kip Obenauf\.vscode\extensions\ms-vscode-remote.remote-wsl-0.41.7
[2020-02-01 14:56:12.422] 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.
[2020-02-01 14:56:12.422] VS Code Server for WSL closed unexpectedly.
[2020-02-01 14:56:12.422] For help with startup problems, go to
[2020-02-01 14:56:12.422] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

On Windows, I deleted C:\Users\Kip Obenauf\.vscode. When I started code . again, it told me the Remote extension wasn't installed, so it installed it. I restarted code . afterwards, but I still get the same error.

Hi, have checked ssh-server status after error ? Have you try to reinstall it ?

[tforster]

Rolling back worked for me and it was less time than it took to make a cup of tea. Kudos to all the MS engineers that make the Insiders program reliable enough that the rest of us can be at the leading edge, while still having a dependable safety net for these occasional hiccups.

[kobenauf]

@FabienD I reinstalled openssh-server, but I still get the same error. At this point I am also just rolling back to 19551 so I can do work.

[PhilDim1]

Same issue, here.

[dancosta]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved. PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

Sorry, but this is absolutely no workaround. There are obvious reasons why we use v2 and not v1.

I'm not sure why the down vote on my comment. I should made myself clear in that post I'm speaking for myself and not in any official capacity from Microsoft. I was trying to be helpful to the community to folks who need to have their wsl distros up and functional. v2 is vastly better than v1. We all love v2 but if it's a matter between up but limping along versus being down then I'll take being up while the issue is being worked on.

Since the title already says "WSL2-Error..." there's really no need to suggest a workaround for converting to v1.

It's not about which one is better. There are features that v1 can do but v2 can't, and vice versa. Depending on these features and based on our needs, we have distros running as v1 or v2, simultaneously.

I personally think that @bjd145 comment was a valid idea. It may not be a option to everyone using WSL2 but may be an option. In my case I had just 2 options: downgrading my Ubuntu or Rollingback the Windows update! I chose the latter option because I wanted to see how it is to rollback windows update, and I was encouraged to do so because some people here reported they successfully did it.

And @bjd145 was kind enough to give the complete set of commands to use his workaround to the problem.

Thanks everyone here and MS to be doing such a great work. It is good to know MS is already doing a new build to fix it @benhillis =)

[JMBBunch]

@FabienD I did have the SSH server issues. It was not running, and when I started it the key problems appeared. So I did purge and reinstall, and then SSH server started up without errors. It now comes up as Running when I open WSL. This did not solve the VSCode issue, unfortunately.

Incidentally, I installed both Ubuntu and Ubuntu-18.04 from the Store. I ensured both are set to version 2. VSCode is not coming up for either of them. Same messages. (Same SSH server issues and fix attempts also.)

Then, I tried @FabienD 's suggestion to remove the .vscode folder from the User profile, start VSCode from the WSL command line with "code .", and install the Remote extension when prompted, but I am still getting the same errors.

Thought I'd dig a little more. The terminal output in VSCode shows a line that starts, "Probing if server is already installed", and then issues the command:

C:\WINDOWS\System32\wsl.exe -d Ubuntu-18.04 -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"

That is followed by the error message, "Unable to detect if server is already installed", so I thought I'd test the above command line in the various Windows terminals. All of those successfully return: "found"

PATH in Windows is 534 characters. PATH in WSL (Ubuntu 18.04) is 803 characters.

Does anyone know whether these paths are still too long?

[ad-on-is]

i was hitting the same issue with my v2 distro then i successfully converted it back to v1. I can now access the distro. Took about an hour to convert down but at least it's a viable workaround until the issue is resolved. PS C:\Users\brian> wsl --list -v NAME STATE VERSION

• Ubuntu-18.04 Stopped 2 PS C:\Users\brian> wsl --set-version Ubuntu-18.04 1 PS C:\Users\brian> wsl --list -v NAME STATE VERSION
• Ubuntu-18.04 Running 1 PS C:\Users\brian>wsl brian@brian_pc:~$

Sorry, but this is absolutely no workaround. There are obvious reasons why we use v2 and not v1.

I'm not sure why the down vote on my comment. I should made myself clear in that post I'm speaking for myself and not in any official capacity from Microsoft. I was trying to be helpful to the community to folks who need to have their wsl distros up and functional. v2 is vastly better than v1. We all love v2 but if it's a matter between up but limping along versus being down then I'll take being up while the issue is being worked on.

Since the title already says "WSL2-Error..." there's really no need to suggest a workaround for converting to v1. It's not about which one is better. There are features that v1 can do but v2 can't, and vice versa. Depending on these features and based on our needs, we have distros running as v1 or v2, simultaneously.

I personally think that @bjd145 comment was a valid idea. It may not be a option to everyone using WSL2 but may be an option. In my case I had just 2 options: downgrading my Ubuntu or Rollingback the Windows update! I chose the latter option because I wanted to see how it is to rollback windows update, and I was encouraged to do so because some people here reported they successfully did it.

And @bjd145 was kind enough to give the complete set of commands to use his workaround to the problem.

Thanks everyone here and MS to be doing such a great work. It is good to know MS is already doing a new build to fix it @benhillis =)

If you use WSL to just play around with Linux, and want to try all these geeky stuff everyone is talking about, then sure, there are many options.

But, if you work on client projects, where time and reliability play a significant role, you definitely don't want to waste time experimenting with nonsense workarounds. Especially not when you have projects (sourcecode) stored inside WSL (in a vhdx-file) which could eventually end up in data corruption or even data loss.

You just want to get back to a working environment as soon as possible. Thankfully restoring Windows nowadays is just a matter of minutes and not hours.

[ad-on-is]

@FabienD I did have the SSH server issues. It was not running, and when I started it the key problems appeared. So I did purge and reinstall, and then SSH server started up without errors. It now comes up as Running when I open WSL. This did not solve the VSCode issue, unfortunately.

Incidentally, I installed both Ubuntu and Ubuntu-18.04 from the Store. I ensured both are set to version 2. VSCode is not coming up for either of them. Same messages. (Same SSH server issues and fix attempts also.)

Then, I tried @FabienD 's suggestion to remove the .vscode folder from the User profile, start VSCode from the WSL command line with "code .", and install the Remote extension when prompted, but I am still getting the same errors.

Thought I'd dig a little more. The terminal output in VSCode shows a line that starts, "Probing if server is already installed", and then issues the command:

C:\WINDOWS\System32\wsl.exe -d Ubuntu-18.04 -e sh -c "[ -d ~/.vscode-server/bin/26076a4de974ead31f97692a0d32f90d735645c0 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"

That is followed by the error message, "Unable to detect if server is already installed", so I thought I'd test the above command line in the various Windows terminals. All of those successfully return: "found"

PATH in Windows is 534 characters. PATH in WSL (Ubuntu 18.04) is 803 characters.

Does anyone know whether these paths are still too long?

Even though I rolled back, I checked my Windows PATH out of curiosity, and I wouldn't consider them to be long, since therer are only 4 lines, AppData, VScode, Flutter-sdk and Dashlane paths, which are crucial for me.

[PhilDim1]

Even though I rolled back, I checked my Windows PATH out of curiosity, and I wouldn't consider them to be long, since therer are only 4 lines, AppData, VScode, Flutter-sdk and Dashlane paths, which are crucial for me.

Mine was nearly that short. Nothing excessive, not in length or sheer number.

[vanguard737]

Regarding $PATH length, just in case this helps anybody: I didn't want to make any persistent changes to my system $PATH. So I just did some temporary $PATH-pruning within Powershell, with decent results.

# My default $PATH is pretty long...
PS C:\WINDOWS\system32> $Env:Path.length
1651
# ...and at that length, I can't login:
PS C:\WINDOWS\system32> 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.
# ...So, I'll temporarily make the path as short as humanly possible:
PS C:\WINDOWS\system32> $Env:Path = "C:\Windows\System32;C:\Windows";
# ...which is pretty short:
PS C:\WINDOWS\system32> $Env:Path.length
30
# ...And now I can login without issue.  Victory!
PS C:\WINDOWS\system32> wsl
root@DESKTOP-UVCU1I3:/mnt/c/WINDOWS/system32#

[jbudz]

Thanks for the workarounds everyone. I didn't feel like fiddling too much so gave the rollback approach a try. I went from 19555 to 19551 - it took about 15 minutes. generic disclaimer about removing updates

Start -> Settings -> Update and Security -> Recovery -> Go back to the previous version of Windows 10

[PhilDim1]

Regarding $PATH length, just in case this helps anybody: I didn't want to make any persistent changes to my system $PATH. So I just did some temporary $PATH-pruning within Powershell, with decent results.

# My default $PATH is pretty long...
PS C:\WINDOWS\system32> $Env:Path.length
1651
# ...and at that length, I can't login:
PS C:\WINDOWS\system32> 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.
# ...So, I'll temporarily make the path as short as humanly possible:
PS C:\WINDOWS\system32> $Env:Path = "C:\Windows\System32;C:\Windows";
# ...which is pretty short:
PS C:\WINDOWS\system32> $Env:Path.length
30
# ...And now I can login without issue.  Victory!
PS C:\WINDOWS\system32> wsl
root@DESKTOP-UVCU1I3:/mnt/c/WINDOWS/system32#

Thanks, this actually worked for me. I had no idea my $PATH was that large. I cut mine down to ~700, it works. Weird issue

[alexign]

same boat here. just truncate Windows %PATH% from lengthy string to some: C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\HashiCorp\Vagrant\bin;C:\Users\username\AppData\Local\Microsoft\WindowsApps;C:\Users\username\AppData\Local\Programs\Microsoft VS Code\bin

and now code can open wsl2 dir's

[stefanjarina]

So rollback it is as truncating PATH is not an option if one have tons and tons of software that needs to be there. This PATH length limit in windows is just terrible, especially when software such as intel or razer pollute it with several really long paths.

[BabyDino]

I just deleted my previous Windows installation files before starting vscode. Not my smartest move.

I agree with @ad-on-is that using the fast ring is a risk but all latest builds seems to have serious issues which makes it unusable as a developer. Truncating %PATH% seems to do the trick for now.

FWIW: my $Env.Path.length is 217 chars which seems to work.

[uniibu]

Like the other above, shortening your %PATH% seems to work. The length of my %PATH% was 1800+ and now down to 1288 and wsl now works fine.

To shorten my PATH, I removed duplicates variables. You could edit your PATH by going to System Properties -> Advance -> Environment Variables. And under System Variables, look for Path, then edit.

I found that I had duplicate entries like C:\WINDOWS, C:\Windows, %SystemRoot%, C:\WINDOWS\System32, C:\Windows\System32, %SystemRoot%\System32 etc.. So i removed the %SystemRoot% and C:\WINDOWS(capitals) duplicate entries, and this significantly reduced my PATH variable.

[wagneripjr]

We were able to debug what the issue is here and are pushing the fix. This issue triggers if you have a somewhat a long %PATH%, so one potential workaround (until a new build comes out with the fix) would be to do some "spring cleaning" on your %PATH% variable to make it shorter.

Thank!, I've shortened the path (removed SQL Server entries 😄 ) and WSL is working again

[pellea]

Shortening the $PATH is working to start WSL but I still cannot start my VSCode env. This workaround is useless for me.

I revert back to the previous build version of Windows.

[sc0ttwad3]

@uniibu I frequently run into those duplicated C:\Windows, C:\Windows\System32, ...and the rest, entries in the system path. Over the course of Windows 10 (since the first available builds years ago), I think I have removed those duplicates at least dozen or more times. And still haven't figured out when/what re-adds the unecessarily.

[gaffneyd4]

Shortened my path down to 1048, appears to be working fine now. Thanks to everyone for all of the tips, I was honestly surprised to see so much activity on an issue created 3 days ago! Its cool to see that the community is adopting these WSL features as quickly as they're released! I don't say this often, but keep up the great work MS! 🙌

[bytemain]

I have reverted to 19551. But I found a reg value that seems to help:

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name 'LongPathsEnabled' -Value 1

from: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

I haven't tried, just to share.

[skuzzer]

I have reverted to 19551. But I found a reg value that seems to help:

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name 'LongPathsEnabled' -Value 1

from: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

I haven't tried, just to share.

This doesn't work.

I've managed to shorten my path to 956 chars and WSL2 now launches but the VS code extension still fails

[NaiveTomcat]

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

Only workable in Powershell.

see #4866