Access \\wsl$ or \\wsl.localhost$ in Explorer, Explorer is not responding

SunJun8 commented 2 years ago

Version

Microsoft Windows [Version 10.0.22000.556]

WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version

linux-msft-wsl-5.10.93.2

Distro Version

Debian

Other Software

explore.exe for windows 11

Not sure if it has something to do with these softwares, but I'm using them
Windows Terminal 1.11.3471.0
usbipd-win 2.1.0
vscode windows 1.65

Repro Steps

I'm not sure if this problem occurs on every device, but it happens on both thinkbook14 (4800u) and (5800u)

Fresh install win11
Install Windows Subsystem for Linux Preview from the Microsoft Store. (At this point you already have the wsl2 kernel and wslg)
Install debian in microsoft store
Install usbip via winget (lastest version)
May need to connect a usb device to wsl or open a wsl GUI program
wait (maybe)
Access \wsl$ or \wsl.localhost$ in Explorer

Expected Behavior

Open the root directory of wsl

Actual Behavior

Explorer is not responding

Diagnostic Logs

No response

SunJun8 commented 2 years ago

Any attempt to access \wsl$\debian, including

explore.exe .
\wsl$ or \wsl.localhost$
...

will cause Explore noresponding

FDCTLC commented 2 years ago

I am experiencing the same problem with a small difference: the interactions are working as expected in the beginning (after windows 11 reboot) and suddenly the \wsl$ and \wsl.localhost$ accesses for one WSL are severed and there is no way to have them working again (even with a wsl --shutdown ).
I have several WSLs (both generations) working at once and the problem seems not to affect all the wsl at once. It seems that a reboot of the whole windows machine if temporarily fixing the problem (it will happen again later, unluckily)

I am working on DELL precision towers

lwschan commented 2 years ago

I am experiencing the exact same problem, but I am using the Ubuntu distro.

Additionally, when this is happening, any attempt to do git push or code . will yield no response. It just keeps running forever.

Similar to what @fdctlc claims, a wsl --shutdown doesn't solve the problem, a full system reboot is needed.

SunJun8 commented 2 years ago

@FDCTLC For me it seems to be related to adding \wsl.localhost\distribution to quick access

SunJun8 commented 2 years ago

@lewisgauss For me, git is still working fine, only affects windows access to wsl paths

lwschan commented 2 years ago

@SunJun8 Is your Git in WSL2 setup to use Git Credential Manager from your Windows host?

SunJun8 commented 2 years ago

@SunJun8 Is your Git in WSL2 setup to use Git Credential Manager from your Windows host?

nope

lwschan commented 2 years ago

@SunJun8 Is your Git in WSL2 setup to use Git Credential Manager from your Windows host?

nope

You've confirmed my suspicions then, seems like for whatever reason, the connection between the host and WSL2 becomes lost, randomly. Or at least I've not seen a pattern yet...

FDCTLC commented 2 years ago

@SunJun8 Is your Git in WSL2 setup to use Git Credential Manager from your Windows host?

nope

You've confirmed my suspicions then, seems like for whatever reason, the connection between the host and WSL2 becomes lost, randomly. Or at least I've not seen a pattern yet...

For the moment I have the same feeling. The connection is lost randomly but with some relation with programming activities (visual studio code with WSL or visual studio [professional] with remote compilation)

SunJun8 commented 2 years ago

hey buddy i found a way to reproduce： Add \wsl.localhost\distribution to "library"

benhillis commented 2 years ago

We have recently resolved a few issues that would explain the hang when accessing \\wsl.localhost, a new version of the Store package will have the fix, but a few of the issues are in the Windows OS so an upcoming Insider build will have the fixes for those.

danchitnis commented 2 years ago

@benhillis Is the update propagating to insider Beta as well since now both versions of Beta and Dev are matching? The recent Store update of the WSL kernel seems to freeze more than the previous version.

oaklandcorp-jkaiser commented 2 years ago

@benhillis Are there any build numbers, versions, or other links we can use to track the progress of these fixes? In my opinion joining the insider program seems too risky for professional development so it would be good to have some way to keep an ear out for when these fixes will receive a mainstream release.

kissgyorgy commented 2 years ago

I have the exact same problem after installing the Microsoft Store version of WSL 2 and running the wsl.exe --update command. It is working for a couple of minutes after reboot, then everything is inaccessible, commands like wsl --status or wsl --shutdown doesn't work.

I'm on Windows Insider Program Beta Channel, the above mentioned fixes are not included in it yet. Output of wsl --status command:

Default Distribution: Ubuntu
Default Version: 2
WSL version: 0.56.2.0
Kernel version: 5.10.102.1
WSLg version: 1.0.30
MSRDC version: 1.2.2924
Direct3D version: 1.601.0
Windows version: 10.0.22581.200

Having a Quick access shortcut to a WSL folder, OR accessing the WSL filesystem from Windows (e.g. clicking on the Linux\Ubuntu folder in the sidebar) OR starting VS Code seems to be instantly freezing WSL and from that point on, I can't interact with it in any way.

Any recommended workarounds until it get fixed?

danchitnis commented 2 years ago

I might have found a workaround if you are using VS code. Connect to WSL via VS Code's remote connection. Use the left-hand tree view to browse folders and files. if you want to access a file in WSL, right-click and "Download" the file to the Windows file system. At the moment explorer.exe is very buggy beyond the WSL issue and it is freezing for many reasons.

benhillis commented 2 years ago

@oaklandcorp-jkaiser - the fix will be contained in 0.58.0 of the WSL store package which is going through test passes currently and (if everything goes well) will be available later this week.

You will not need an insider build.

oaklandcorp-jkaiser commented 2 years ago

That's great news! Thank you for the insight.

OneBlue commented 2 years ago

/dupe #7883

ghost commented 2 years ago

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

azzazkhan commented 1 year ago

Still facing this issue, this is the biggest issue that makes WSL undependable. In the middle of my work WSL stops and I have to shut down the WSL manually using wsl --shutdown due to which all my active processes and Docker containers get terminated.

OneBlue commented 1 year ago

@azzazkhan: Can you please share dumps when you hit this issue ?

/dumps

ghost commented 1 year ago

Hello! Could you please provide logs and process dumps to help us better diagnose your issue?

To collect WSL logs and dumps, 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 -Dump

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 / WSL