Accessing 9P share for particular distro hangs

[lediur]

Version

Microsoft Windows [Version 10.0.22494.1000]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.74.3

Distro Version

Ubuntu 18.04

WSL Version

WSL version: 0.50.2.0
WSLg version: 1.0.29

Other Software

Docker (installed in WSL) 20.10.10
Visual Studio Code 1.63.0 Insider with Remote-WSL v0.63.3
Firefox Developer Edition 95.0b12

Repro Steps

• Boot
• Able to access files in the 9P share for this distro just fine (for example, selecting files with Firefox)
• Wait some period of time (I haven't been able to determine a clear reason for the issue, hoping someone with more experience investigating 9P issues can help me gather the appropriate logs and diagnostic data)
• Attempt to access the 9P share

Expected Behavior

Successfully view the files in the virtual disk for that distro

Actual Behavior

File Explorer stalls (indefinitely increasing progress bar) when trying to access the share, but is responsive.

When trying to open the browser "select file" dialog, Firefox hangs and becomes unresponsive. This behavior persists through Firefox restarts.

Map Network Drive stalls when trying to connect.

Stopping or restarting the affected distro has no effect.

I am able to access the files in another unrelated distro (Debian) using the 9P share.

VS Code's WSL connection continues to work, as do any servers with open ports (like web servers).

The issue does not persist when I restart the computer, so I am able to access the files again, but I have noticed the issue consistently reoccurring.

Diagnostic Logs

This ETL file was recorded with WPR when attempting to access the 9P share using File Explorer.

etl.zip

[lediur]

Restarted and immediately tried to access some CSV files on the 9P share with Excel. Excel complained that the files weren't accessible, but I was able to copy these files to the Desktop, which resulted in this dialog:

I was able to open the files from the desktop after copying. I was also able to open other files in nearby folders. The share became unresponsive shortly afterwards, so I thought it might be something to do with certain files or alternate streams.

After restarting again, I was unable to reproduce this "inaccessible files" behavior following the steps above.

I did not start any other programs other than Firefox to write this comment, Excel and VS Code to attempt opening these files.

[DanPinGF]

Maybe try posting some report information to help figure out the problem? Typically you can find the WER report logs in the C:\ProgramData\Microsoft\Windows\WER\ReportArchive folder.

FYI, you can similarly access crash information through 'Event Viewer' > 'Application'.

[benhillis]

/dupe #7479

[ghost]

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!