[wsl] VSCode not opening in WSL after WSL update

[ecastro-capgemini]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.83.1
• OS Version: Windows 11 - 22H2 - 22621.2715 // WSL 5.15.133.1 (uname -a)

Steps to Reproduce:

1. In previous versions of the Kernel (< 5.15.90), open a WSL terminal, select a firectory (cd), type code . => It works
2. Upgrade wsl to current verison 5.15.90 (wsl --update)
3. Try step 1 again. It does not work anymore
4. Run Windows update to get latest patches (as stated in WSL not opening well WSL#9945)
5. Reboot
6. It keeps failing

Work around : install VSCode for Linux (sudo snap install code --classic) and use it in degraded mode.

Failure log:

[2023-11-15 09:57:23.686] Extension version: 0.81.8
[2023-11-15 09:57:23.686] L10N bundle: undefined
[2023-11-15 09:57:23.699] authorityHierarchy: wsl+Ubuntu
[2023-11-15 09:57:23.699] WSL extension activating for a local WSL instance
[2023-11-15 09:57:23.738] Resolving wsl+Ubuntu, resolveAttempt: 1
[2023-11-15 09:57:23.738] NodeExecServer run: C:\WINDOWS\System32\wsl.exe --status
[2023-11-15 09:57:24.121] WSL feature installed: true (wsl --status)
[2023-11-15 09:57:24.121] NodeExecServer run: C:\WINDOWS\System32\wsl.exe --list --verbose
[2023-11-15 09:57:24.449] 1 distros found
[2023-11-15 09:57:24.450] Starting VS Code Server inside WSL (wsl2)
[2023-11-15 09:57:24.450] Windows build: 22621. Multi distro support: available. WSL path support: enabled
[2023-11-15 09:57:24.450] Scriptless setup: false
[2023-11-15 09:57:24.517] NodeExecServer run: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c [ -f '/tmp/vscode-distro-env.Mcqg6T' ] && cat '/tmp/vscode-distro-env.Mcqg6T' || echo ''
[2023-11-15 09:57:24.674] WSL daemon log file: 
[2023-11-15 09:57:24.677] Probing if server is already installed: if [ -d ~/.vscode-server/bin/f1b07bd25dfad64b0167beb15359ae573aecd2cc ]; then printf 'install-found '; fi; if [ -f /etc/alpine-release ]; then printf alpine-; fi; uname -m
[2023-11-15 09:57:24.677] NodeExecServer run: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c if [ -d ~/.vscode-server/bin/f1b07bd25dfad64b0167beb15359ae573aecd2cc ]; then printf 'install-found '; fi; if [ -f /etc/alpine-release ]; then printf alpine-; fi; uname -m
[2023-11-15 09:57:25.203] Using shell environment from invoking shell: /tmp/vscode-distro-env.Mcqg6T
[2023-11-15 09:57:27.369] Probing result: install-found x86_64
[2023-11-15 09:57:27.369] Server install found in WSL
[2023-11-15 09:57:27.370] NodeExecServer run: C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" f1b07bd25dfad64b0167beb15359ae573aecd2cc stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=476210498-2090502899-3813312384-234974362 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all'
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: CreateProcessParseCommon:708: Failed to translate C:\Users\ecastro\AppData\Local\Programs\Microsoft VS Code
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate c:\Users\ecastro\.vscode\extensions\ms-vscode-remote.remote-wsl-0.81.8
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python312\Scripts\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python312\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python311\Scripts\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python311\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Eclipse Adoptium\jdk-17.0.3.7-hotspot\bin
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\system32
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\Wbem
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\WindowsPowerShell\v1.0\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\OpenSSH\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Meld\
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Git\cmd
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\ProgramData\nvm
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\nodejs
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WindowsApps
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\ProgramData\chocoportable\bin
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Programs\Microsoft VS Code\bin
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Sysinternals.TCPView_Microsoft.Winget.Source_8wekyb3d8bbwe
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\ProgramData\nvm
[2023-11-15 09:57:27.904] <3>WSL (749) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\nodejs
[2023-11-15 09:57:27.904] sh: 1: /scripts/wslServer.sh: not found
[2023-11-15 09:57:27.904] For help with startup problems, go to https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2023-11-15 09:57:31.848] Download in background is enabled

[vscodenpa]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.84.2. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[ecastro-capgemini]

Just upgraded to 1.84.2.
Same problem, same log 🙁
(same up-to-date version of WSL standard extension 0.81.8)

[ecastro-capgemini]

Same failure with VS Code Insider (1.85.0-insider)
Same failure with previous versions of the WSL plugin (ms-vscode-remote.remote-wsl)

[ecastro-capgemini]

wsl.exe --version on machine were it works: (v 1.2.5)

Version WSL : 1.2.5.0
Version du noyau : 5.15.90.1
Version WSLg : 1.0.S1
Version MSRDC : 1.2.3770
Version direct3D : 1.608.2-61064218
Version de DXCore : IO.O.25131.1002-220531-1700.rs-onecore-base2-hyp
Version de Windows : 10.0.22000.2538

wsl.exe --version on machine were it fails: (v.2.0.9)

Version WSL : 2.0.9.0
Version du noyau : 5.15.133.1-1
Version WSLg : 1.0.59
Version MSRDC : 1.2.4677
Version direct3D : 1.611.1-81528511
Version de DXCore : 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Version de Windows : 10.0.22621.2715

[aercolino-cognizant-cepsa]

Same here

WSL version: 2.0.9.0
Kernel version: 5.15.133.1-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.22000.2538

[aercolino-cognizant-cepsa]

I've been able to make it work again, unexpectedly.

For the last year, every single working day, I started VSCode with code . from the Ubuntu folder, to which I got by first launching WSL from the Windows terminal with wsl.

This time, instead, I just double clicked the icon on the Windows desktop, and VSCode started without errors, connected to WSL, and opened the last file I was editing yesterday, in the Ubuntu folder.

[ecastro-capgemini]

1 - I confirm 🎉, but only when I reboot my machine and if VSCode on WSL is the first thing I do.
2 - If I first open a WSL Terminal in Windows (e.g. wsl.exe on CLI), subsequent attempts to use VSCode with WSL will fail.

3 - After I successfuly open WSCode on WSL and I close it, subsequent attempts to re-open it succeed.

4 - It looks like VSCode hijack WSL so that wsl.exe cannot use it, and wsl.exe hijack WSL so that VSCode cannot use it.

In case 3, I can get the following error message:

C:\Users\ecastro>wsl.exe
<3>WSL (3677) ERROR: CreateProcessParseCommon:708: Failed to translate C:\Users\ecastro
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python312\Scripts\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python312\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python311\Scripts\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Python311\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Eclipse Adoptium\jdk-17.0.3.7-hotspot\bin
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\system32
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\Wbem
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\WindowsPowerShell\v1.0\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\WINDOWS\System32\OpenSSH\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Meld\
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Git\cmd
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\Microsoft VS Code\bin
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WindowsApps
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\ProgramData\chocoportable\bin
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Users\ecastro\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Sysinternals.TCPView_Microsoft.Winget.Source_8wekyb3d8bbwe
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\ProgramData\nvm
<3>WSL (3677) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\nodejs
ecastro@mymachine:~$ uname -a
Linux mymachine 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

At this point, $PATH does not contain Windows PATH anymore.

[daltonv]

Somehow starting wsl from powershell as admin seems to fix it for me.

Opening the standalone wsl.exe is still borked with the paths not being translated, but wsl from powershell and VSCode work now.

[dancristiancecoi]

Same issue using the most up-to-date version of VS Code and WSL. Can confirm that starting VS Code with the executable right after a reboot (instead of running "code . " in the WSL terminal) works for VS Code.

Edit: Docker Desktop still does not start

[aeschli]

There has been no changes to the WSL extension recently. I suspect it's a problem in WSL 5.15.90. @craigloewen-msft

microsoft/WSL#10752 (comment) also mentions this and has a workaround.

[ecastro-capgemini]

Somehow starting wsl from powershell as admin seems to fix it for me.

Opening the standalone wsl.exe is still borked with the paths not being translated, but wsl from powershell and VSCode work now.

Good idea. I've found that after a reboot:

• If one starts wsl.exe in standard mode, it cannot be launched in admin mode
• Conversely; if one starts wsl.exe in admin mode, it cannot be launched in standard mode any more.

For unknown reason, VSCode is starting in admin mode on my machine, instead of normal mode.

[dancristiancecoi]

The suggestion from here works for me.

Add the following to .wslconfig:

[wsl2] 

virtio9p=false

After rebooting the laptop (just wsl --shutdown was not sufficient for me) I can start VS Code (both from the exe or the wsl terminal) & Docker desktop without issues. Don't know what are the repercussions for disabling virtio9p but things seem to work okay for me.

[HecGonOra]

Somehow starting wsl from powershell as admin seems to fix it for me.
Opening the standalone wsl.exe is still borked with the paths not being translated, but wsl from powershell and VSCode work now.

Good idea. I've found that after a reboot:

• If one starts wsl.exe in standard mode, it cannot be launched in admin mode
• Conversely; if one starts wsl.exe in admin mode, it cannot be launched in standard mode any more.

For unknown reason, VSCode is starting in admin mode on my machine, instead of normal mode.

I have the same issue. How did you check in which mode is running VsCode? Also I found that always is getting setup from Windows, not from wsl.

[ecastro-capgemini]

I have the same issue. How did you check in which mode is running VsCode? Also I found that always is getting setup from Windows, not from wsl.

It is written in the seach bar, on the top of the Window (e.g. 🔍my_project [WSL: Ubuntu] [Administrator])

[kbolontzakis]

I have the exact same issue @ecastro-capgemini and the virtio9p solution hasn't changed anything.

[benhillis]

I have the exact same issue @ecastro-capgemini and the virtio9p solution hasn't changed anything.

Could you try restarting after changing the setting please?

[kbolontzakis]

I have the exact same issue @ecastro-capgemini and the virtio9p solution hasn't changed anything.

Could you try restarting after changing the setting please?

I had restarted multiple times but the issue was still there. Then, I decided to install a competitor paid IDE for PHP with remote connection capabilities and it worked right away. Both IDEs worked at that point and continued to be working up to now. We will see if the issue will return in VS.

[felixtheflex]

[wsl2] 
virtio9p=false

@ecastro-capgemini - it worked on my captop.

[TheGlitch1]

I've litterally re-registred Ubuntu and the issue wasn't fix.
The only solution / fix I've accidentally used is to avoid executing WSL from windows and use vscode to connect directly to WSL.

[felixtheflex]

I've litterally re-registred Ubuntu and the issue wasn't fix. The only solution / fix I've accidentally used is to avoid executing WSL from windows and use vscode to connect directly to WSL.

please note by saying, ~/.wslconfig it means c:\users\%username%\.wslconfig. Changes need to be done on Windows side and not wsl's.

[wsl2] 
virtio9p=false

Put changes in c:\users\%username%\.wslconfig, it might just work?

[kbolontzakis]

I've litterally re-registred Ubuntu and the issue wasn't fix. The only solution / fix I've accidentally used is to avoid executing WSL from windows and use vscode to connect directly to WSL.

please note by saying, ~/.wslconfig it means c:\users\%username%\.wslconfig. Changes need to be done on Windows side and not wsl's.

[wsl2] 
virtio9p=false

Put changes in c:\users\%username%\.wslconfig, it might just work?

Thank you for the clarification. That worked right away!

[vanguard478]

I did the changes as mentioned here but it isn't working for me.
Still getting this error

/.vscode/extensions/ms-vscode-remote.remote-wsl-0.81.8/scripts/wslCode.sh: 63: /home/vanguard/.vscode/bin/e7d7e9a9348e6a8cc8c03f877d39cb72e5dfb1ff/bin/remote-cli/code: not found

The suggestion from here works for me.

Add the following to .wslconfig:

[wsl2] 

virtio9p=false

After rebooting the laptop (just wsl --shutdown was not sufficient for me) I can start VS Code (both from the exe or the wsl terminal) & Docker desktop without issues. Don't know what are the repercussions for disabling virtio9p but things seem to work okay for me.

[aeschli]

@benhillis Can we move this issue to the WSL repo, or is there already a corresponding issue?

[ecastro-capgemini]

Seems to be resolved by WSL 2.0.14

> wsl.exe --update

[aldaniel]

Somehow starting wsl from powershell as admin seems to fix it for me.

Opening the standalone wsl.exe is still borked with the paths not being translated, but wsl from powershell and VSCode work now.

this works for me

[Tantino]

Seems to be resolved by WSL 2.0.14
wsl.exe --update

[bamurtaugh]

Thanks all for the continued feedback. It sounds like upgrading to WSL 2.0.14 resolved the issue for several folks.

Are there still folks experiencing trouble here? If so, to help the WSL team take a closer look, could you please take a trace? https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1.