Windows commands inside WSL hang forever

[siferati]

Version

WSL 0.50.2.0

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.74.3

Distro Version

Ubuntu 20.04.3 LTS

Other Software

No response

Repro Steps

I'm not sure what went wrong nor how to debug this. It was working fine before but all of a sudden I stopped being able to use windows commands from inside WSL. notepad.exe, wsl.exe, etc they all just hang forever and not even Ctrl+C is able to kill them and I'm forced to close the terminal.

Expected Behavior

Can use windows commands from inside WSL (e.g. wsl.exe --version)

Actual Behavior

Windows commands (e.g. wsl.exe --version) hang forever and not even Ctrl+C is able to kill them and I'm forced to close the terminal.

Diagnostic Logs

nodepad.exe

$ strace notepad.exe
execve("/mnt/c/Windows/system32/notepad.exe", ["notepad.exe"], 0x7fff357161e0 /* 37 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x378290)       = 0
set_tid_address(0x3782c8)               = 400
brk(NULL)                               = 0xf79000
brk(0xf7a000)                           = 0xf7a000
brk(0xf7b000)                           = 0xf7b000
gettid()                                = 400
gettid()                                = 400
gettid()                                = 400
gettid()                                = 400
brk(0xf7c000)                           = 0xf7c000
brk(0xf7d000)                           = 0xf7d000
brk(0xf7e000)                           = 0xf7e000
sched_getaffinity(0, 128, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]) = 32
getpid()                                = 400
getcwd("/home/tiago", 4096)             = 12
uname({sysname="Linux", nodename="DESKTOP-VN589IP", ...}) = 0
getcwd("/home/tiago", 4096)             = 12
open("/mnt/c/Windows/system32/notepad.exe", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_PATH) = 3
readlink("/proc/self/fd/3", "/mnt/c/Windows/system32/notepad."..., 4095) = 35
fstat(3, {st_mode=S_IFREG|0555, st_size=348160, ...}) = 0
stat("/mnt/c/Windows/system32/notepad.exe", {st_mode=S_IFREG|0555, st_size=348160, ...}) = 0
close(3)                                = 0
open("/proc/self/mountinfo", O_RDONLY)  = 3
readv(3, [{iov_base="", iov_len=0}, {iov_base="68 72 0:26 / /mnt/wsl rw,relatim"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="- tmpfs none rw,mode=755\n96 95 0"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="ev,noexec,relatime - cgroup cgro"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="66 / /mnt/c rw,noatime - 9p drvf"..., iov_len=1024}], 2) = 270
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3)                                = 0
getcwd("/home/tiago", 4096)             = 12
open("/proc/self/mountinfo", O_RDONLY)  = 3
readv(3, [{iov_base="", iov_len=0}, {iov_base="68 72 0:26 / /mnt/wsl rw,relatim"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="- tmpfs none rw,mode=755\n96 95 0"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="ev,noexec,relatime - cgroup cgro"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="66 / /mnt/c rw,noatime - 9p drvf"..., iov_len=1024}], 2) = 270
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TIOCGPGRP, [397])              = 0
getpgid(0)                              = 397
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
ioctl(0, TIOCGWINSZ, {ws_row=39, ws_col=166, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
                                                                                 dup(0)                                  = 3
                                                                                                                            socket(AF_VSOCK, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
       bind(4, {sa_family=AF_VSOCK, sa_data="\0\0\377\377\377\377\377\377\377\377\0\0\0\0"}, 16) = 0
                                                                                                    getsockname(4, {sa_family=AF_VSOCK, sa_data="\0\0\343\221\264\332\377\377\377\377\0\0\0\0"}, [16]) = 0
                                    listen(4, 4)                            = 0
                                                                               socket(AF_UNIX, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 5
                                                                                                                                  connect(5, {sa_family=AF_UNIX, sun_path="/run/WSL/350_interop"}, 110) = 0
                                     write(5, "\6\0\0\0006\1\0\0\343\221\264\332\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 310) = 310
                                                                                                                                        poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                        accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0]c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 6
                                                                                                                                       poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                       accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0^c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 7
                                                                                                                                      poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                      accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0_c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 8
                                                                                                                                     poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                     accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0`c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 9
                                                                                                                                    close(4)
      = 0
         rt_sigprocmask(SIG_BLOCK, [INT WINCH], NULL, 8) = 0
                                                            signalfd4(-1, [INT WINCH], 8, 0)        = 4
                                                                                                       poll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 5, -1

wsl.exe --version

$ strace wsl.exe --version
execve("/mnt/c/Windows/system32/wsl.exe", ["wsl.exe", "--version"], 0x7fff7408be88 /* 37 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x378290)       = 0
set_tid_address(0x3782c8)               = 282
brk(NULL)                               = 0x2100000
brk(0x2101000)                          = 0x2101000
brk(0x2102000)                          = 0x2102000
gettid()                                = 282
gettid()                                = 282
gettid()                                = 282
gettid()                                = 282
brk(0x2103000)                          = 0x2103000
brk(0x2104000)                          = 0x2104000
brk(0x2105000)                          = 0x2105000
sched_getaffinity(0, 128, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]) = 32
getpid()                                = 282
getcwd("/home/tiago", 4096)             = 12
uname({sysname="Linux", nodename="DESKTOP-VN589IP", ...}) = 0
getcwd("/home/tiago", 4096)             = 12
open("/mnt/c/Windows/system32/wsl.exe", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_PATH) = 3
readlink("/proc/self/fd/3", "/mnt/c/Windows/system32/wsl.exe", 4095) = 31
fstat(3, {st_mode=S_IFREG|0555, st_size=172032, ...}) = 0
stat("/mnt/c/Windows/system32/wsl.exe", {st_mode=S_IFREG|0555, st_size=172032, ...}) = 0
close(3)                                = 0
open("/proc/self/mountinfo", O_RDONLY)  = 3
readv(3, [{iov_base="", iov_len=0}, {iov_base="68 72 0:26 / /mnt/wsl rw,relatim"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="- tmpfs none rw,mode=755\n96 95 0"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="ev,noexec,relatime - cgroup cgro"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="66 / /mnt/c rw,noatime - 9p drvf"..., iov_len=1024}], 2) = 270
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3)                                = 0
getcwd("/home/tiago", 4096)             = 12
open("/proc/self/mountinfo", O_RDONLY)  = 3
readv(3, [{iov_base="", iov_len=0}, {iov_base="68 72 0:26 / /mnt/wsl rw,relatim"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="- tmpfs none rw,mode=755\n96 95 0"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="ev,noexec,relatime - cgroup cgro"..., iov_len=1024}], 2) = 1024
readv(3, [{iov_base="", iov_len=0}, {iov_base="66 / /mnt/c rw,noatime - 9p drvf"..., iov_len=1024}], 2) = 270
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TIOCGPGRP, [279])              = 0
getpgid(0)                              = 279
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
ioctl(0, TIOCGWINSZ, {ws_row=39, ws_col=166, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
                                                                                 dup(0)                                  = 3
                                                                                                                            socket(AF_VSOCK, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
       bind(4, {sa_family=AF_VSOCK, sa_data="\0\0\377\377\377\377\377\377\377\377\0\0\0\0"}, 16) = 0
                                                                                                    getsockname(4, {sa_family=AF_VSOCK, sa_data="\0\0\333\221\264\332\377\377\377\377\0\0\0\0"}, [16]) = 0
                                    listen(4, 4)                            = 0
                                                                               socket(AF_UNIX, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 5
                                                                                                                                  connect(5, {sa_family=AF_UNIX, sun_path="/run/WSL/244_interop"}, 110) = 0
                                     write(5, "\6\0\0\08\1\0\0\333\221\264\332\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 312) = 312
                                                                                                                                      poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                      accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0\32c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 6
                                                                                                                                       poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                       accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0\33c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 7
                                                                                                                                        poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                        accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0\34c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 8
                                                                                                                                         poll([{fd=4, events=POLLIN}], 1, 10000) = 1 ([{fd=4, revents=POLLIN}])
                                         accept4(4, {sa_family=AF_VSOCK, sa_data="\0\0\35c\317O\2\0\0\0\0\0\0\0"}, [16], SOCK_CLOEXEC) = 9
                                                                                                                                          close(4)
            = 0
               rt_sigprocmask(SIG_BLOCK, [INT WINCH], NULL, 8) = 0
                                                                  signalfd4(-1, [INT WINCH], 8, 0)        = 4
                                                                                                             poll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 5, -1

[siferati]

While shutting down WSL doesn't fix it, rebooting the PC does. The issue seems to happen most frequently after using vscode -- maybe something related to the WSL remote extension? The issue seems to happen randomly after some time has passed since wsl has started.

[benhillis]

Interesting, we will probably need the /logs from the Windows side. Coud you please share those?

[ghost]

Hello! Could you please provide more logs to help us better diagnose your issue? You can find instructions on how to attach logs here, please make sure to post the link to the Feedback Hub item in this chat so we can see it.

Thank you!

[tobiaskohlbau]

I can confirm that I noticed the same issue. Quiet strange behavior, the first one or two times calling and windows executable works like a charm. Afterwards the behavior described by @siferati kicks in and only rebooting the system fixes it for now (did not try to dig deeper).

@benhillis if you could provide an email where I could send the logs (recorded with: wpr -start wsl.wprp -filemode) to I would happily contribute the file. But I would rather not share this openly on GitHub.

[Biswa96]

The logs can be attached here or in Feedback Hub as explained here https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-collect-wsl-logs

[tobiaskohlbau]

The logs can be attached here or in Feedback Hub as explained here master/CONTRIBUTING.md#8-collect-wsl-logs

I've read that but did recorded it manually. Therefore I ask for an email as @craigloewen-msft did provide such email earlier on in some networking related issue.

[siferati]

windows logs: logs.zip

Sorry they're so long... I still haven't found a way to reliably trigger the issue, so I had to do random stuff for 5min until it eventually happened. I stopped recording once the problem occurred, so the relevant logs should be the most recent ones.

Edit: replaced logs with shorter ones

[siferati]

Some more info I found about the issue:

When this issue happens, if I run windows commands (e.g. wsl.exe --version) in a linux path (e.g. /home/username) it will hang forever like I described above. But if I run the command inside /mnt/c then it will work as expected.

[tobiaskohlbau]

@siferati by any chance you're using wsl2-ssh-pageant, npipe or similar tools automated at launch in combination with socat? I'm currently suspecting this as the root cause of breaking it, I've removed it for now and try to replicate the issue.

[siferati]

I'm not using any of those tools AFAIK. The only thing I changed about launching wsl is running the docker daemon as described in https://docs.microsoft.com/en-us/windows/wsl/wsl-config#boot-settings

[tobiaskohlbau]

I've found #7754 which sounds exactly like this issue. Maybe it's a good idea to mark this as duplicate.

[jflam]

This happens to me daily when I try to launch VS Code using code . from WSL. It also happens with one of my VS Code extensions that shells out to Powershell to do manipulate the Windows clipboard. From the linked #7754 thread, this seems to only be happening with the store installed version. Is there a recommended way to revert from the store version to the inbox version? Or should I just uninstall the store version?

[benhillis]

Thanks for the logs, I'll start looking at this.

[rvanlaak]

@benhillis would be awesome if you are able to reproduce and fix. Would such a fix get spread via a Microsoft Store WSL package update?

For me the loss of interoperability happened for both the non-store and the latest store version. What happens is that my PHPStorm loses all Git functionality. The file I/O then stays ok, so PHPStorm still alows me to make edits. Restarting PHPStorm to see if Git interactions becomes available then crashes the entire IDE.

When I/O interoperability is lost, I am unable to navigate to the mount from Explorer, nor am I able to start a new terminal and log into wsl by running the wsl command.
Interesting here is that the terminal session that I have open in PHPStorm at that moment keeps open, and still allows me to run commands.

Found out that non-store wsl versions can solely update the kernel from the command line without upgrading to the store version by running wsl --update --inbox

[benc-uk]

Hitting this one daily running code ./blah and with Git credential manager, the later I can mostly mitigate by using SSH for Git but it's still a huge pain

[cpbotha]

This behaviour was previously also filed, discussed but not yet remedied over at #7754

The work-around is to uninstall the store-version of WSL and revert to the "system" version.

P.S. I see that @tobiaskohlbau already noted the prior issue. :)

[rvanlaak]

The work-around is to uninstall the store-version of WSL and revert to the "system" version.

This workaround is not confirmed to work for everyone, myself included.

[zadjii-msft]

@DHowett this is the one

[OneBlue]

Thanks to everyone who submitted logs.

We've made some progress on the issue, but we need more diagnostics to root cause it.

Instructions once you have a repro (elevated command prompt):

curl.exe https://raw.githubusercontent.com/microsoft/terminal/main/src/Terminal.wprp > Terminal.wprp
wpr.exe -start Terminal.wprp!DefTerm  -filemode

[Start a windows process from wsl, make sure it hangs, then wait a couple seconds]

wpr.exe -stop logs.etl

Then using the task manager, check if the process is actually running on the Windows side, if it is, dump it (under the 'details tab', right click, then 'create dump file'). Do the same for all conhost.exe processes running on the machine.

Then reply to this issue with logs.etl and the dumps of all the above processes, if any. Please also include your Windows build number, and the output of wsl --version

[siferati]

@OneBlue your command has a typo: the curl should be done to a file named Terminal.wprp

I wasn't able to record the logs, when I run the command I get error code: 0xc00ce56f switch from current encoding to specified encoding not supported

I was trying to run notepad.exe but it did not show in the task manager. I uploaded the dumps from conhost to gdrive (too big to upload here).

WSL: 0.51.2.0
kernel: 5.10.81.1
WSLg: 1.0.30
Windows: 10.0.22000.434

[OneBlue]

Thanks @siferati. Fixed the typo :).

Interesting, did Terminal.wprp get downloaded correctly ? If the process isn't created at all the logs would be what we need.
Maybe you have another trace running ? What if you try to run wpr.exe -stop logs.etl to stop any pre-existing tracing ?

[siferati]

Managed to fix the encoding error by replacing UTF-8 with UTF-16 in the Terminal.wprp file.

logs.zip

[SebastianMineur]

I've also started experiencing this issue in the last week. Seems to also be related to web servers running in WSL not responding to requests.

logs.zip

WSL version: 0.51.2.0
Kernel version: 5.10.81.1
WSLg version: 1.0.30
Windows version: 10.0.22000.376

[rvanlaak]

New WSL version was released! https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-5.10.93.2

Would the following release notes that were included possibly relate to fixes for this bug?

Switched Dxgkrnl Version to 2111
Removed the limit of existing and total sysmem allocations
Properly flush the device for termination during process cleanup
Fixed SPDX-License-Identifier for d3dkmthk.h

[OneBlue]

Update: we're still actively investigating this issue.

We know that the problem is between the Plan9 client on the host and the server that runs in WSL2, but we don't know what triggers this 'stuck' state yet. I'll update this issue when we'll have more info.

[mwidmann]

You need to install https://www.microsoft.com/store/productId/9P9TQF7MRM4R which will then install the version, @OneBlue mentioned. Been running for a couple of hours now and I had no issues so far.

[CarlosNihelton]

Hi All! Thanks a lot for the fixes landed. With the new released version, would there be a preferred way to access the distros filesystems between \\wsl.localhost and \\wsl$ ?

[myusrn]

Fyi, i had the windows wsl feature enabled as work around until fix for this came out. After announcement above i reinstalled the windows store wsl preview app then unchecked/removed the windows wsl feature and then rebooted. After that the wsl --version command produces the following output confirming install of the wsl preview store app that is expected to have the fixes in place. So for file explorer access to \\wsl.localhost and \\wsl$ paths has been working without any hangs eventually showing up.

WSL version: 0.58.0.0
Kernel version: 5.10.102.1
WSLg version: 1.0.32
MSRDC version: 1.2.2924
Direct3D version: 1.601.0
Windows version: 10.0.22000.593

Also noticed that wsl preview store app, vs windows wsl feature install option honors windows host mouse button settings in wslg xclient/xserver gui app sessions. For example if you have swapped left and right mouse bottoms in windows host they will be swapped as well in wslg xclient/xserver gui app sessions which is nice level of integration. Also am finding my wsl linux distro wslg supported edge and chrome browser sessions are not hanging sporadically as they did with the windows wsl feature based install.

[daniluk4000]

When will non-preview WSL update? Will we be able to update using wsl --update?

[alexbogias]

It seems that it crashes Jetbrains IDE again:
`

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffda01badc0, pid=7192, tid=9236

JRE version: OpenJDK Runtime Environment JBR-11.0.14.1.1-1751.46-jcef (11.0.14.1+1) (build 11.0.14.1+1-b1751.46)

Java VM: OpenJDK 64-Bit Server VM JBR-11.0.14.1.1-1751.46-jcef (11.0.14.1+1-b1751.46, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)

Problematic frame:

V [jvm.dll+0x24adc0]

`

[zed76r]

Update on this issue:

It turns out that this problem is actually composed of 3 bugs:

1. The p9rdr.sys bug I mentioned earlier 2) A bug in WSL's linux plan9 server that would cause sockets to sometimes be dropped when a new client connects 3) A bug in WSL's init process that causes error logs from the plan9 server to go to /dev/null instead of dmesg.

Explanation:

1. is what causes the actual 'hang', but it can only be triggered if the server closes the socket right after the connection is established (so only happens when 2) happens). And because of 3), there were no records of 2) happening, which 'hid' where the issue actually came from.

While 1) is part of the Windows image (and the fix hasn't shipped to insider builds yet), 2) an 3) have been fixed in the latest store WSL release that we just published today (0.58.0). With those fixes, the code path that triggers 1) shouldn't be reached anymore, so the issue should go away.

Note that 2) is also present is the inbox version of WSL (although it appears to hit less frequently than with the store version). We have also checked-in fix to the Windows image, but it hasn't shipped yet.

TL; DR: The fix is available in the latest Store WSL (0.58.0)

@OneBlue

When the p9rdr.sys bug‘s fix ship to windows update? The bug still reproduce but very few times after I upgrade WSL from msstore.

[alexbogias]

I updated to the latest version but it stills hangs every time I open a 2nd big project in PHPStorm with both project files located in \wsl$\Ubuntu\home\alex.... I am not trying to disable phpcs Inspection, which also located inside \wsl$. Furthermore, I think that it created numerous temporary files and seems better. I don't know if this is a wsl, jetbrains or a phpcs bug.

It's not even possible to do wsl --shutdown now. My windows hang for minutes and new ubuntu cli don't respond.

Please let me know what log files would help you

[galiovsky]

@alexbogias Why do you think it's related to this issue? I don't see any indication in your posts that it is. Have you tried reaching out to JetBrains support? I see you commented under https://youtrack.jetbrains.com/issue/IDEA-276250, but hadn't even said if you did try the workaround mentioned there or not... And that issue seems to be an altogether different one than this one, despite some people mixing the two together in the comments...

[alexbogias]

Phpstorm acts differently now with the latest wsl update, thats why. I think its more than one bug to be honest. And yes it looks like there are also jetbrains bug related :(

[galiovsky]

Phpstorm acts differently now with the latest wsl update, thats why.

@alexbogias Doesn't that, on the contrary, mean, that your problems are no longer related to this issue?

I think its more than one bug to be honest. And yes it looks like there are also jetbrains bug related :(

Yes, your problems are/were likely caused by multiple bugs jumbled together. But have you actually read through the whole https://youtrack.jetbrains.com/issue/IDEA-276250 issue and its comments where you posted? There are clear workarounds mentioned that most likely work for your problems too. And even though there probably is another WSL issue involved, it's not related to this particular WSL issue, but something along the lines of #7252...

---

One day, I hope the projects that first instigated users to just use the issue tracker in place of a regular user group will go down in history books for the slippery slope they put all of us on...

[alexbogias]

I am not really sure if that matters, but after uninstalling both WSL preview and WSLg preview from "add & remove programs (settings)" and did a wsl --update again, everything works more stable :S

[JustLookAtNow]

默认分发: Ubuntu
默认版本: 2
WSL 版本： 0.61.8.0
内核版本： 5.10.102.1
WSLg 版本： 1.0.39
MSRDC 版本： 1.2.3213
Direct3D 版本： 1.601.0
DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows版本： 10.0.22000.739

@OneBlue I reproduced this problem on a new version, is it only fixed on 0.58.0

[schiorean]

When is this going to be fixed? There's a lot of pain in the Jetbrains community, it's horror to have to reboot Windows a couple of time each day when the WSL freeze happens.

[maicol07]

@schiorean the issue has been fixed some months ago in WSL v0.58.0.
Can you check if your WSL installation is more recent than 0.58.0?

[schiorean]

Looks like it's not fixed, I'm running 0.66.2. Or it's another related bug, but the symptom is the same: WSL (and WSL commands) freezes and the only way to make it work again is to restart the computer.

[galiovsky]

Looks like it's not fixed, I'm running 0.66.2. Or it's another related bug, but the symptom is the same: WSL (and WSL commands) freezes and the only way to make it work again is to restart the computer.

It's another bug and probably not even related to this one. The symptoms are not the same: WSL itself never froze due to this bug, the distro itself was running just fine, only the interoperability with Windows was lost.

This bug has been fixed. I haven't had it occur once since 0.58.0.

[cubic3d]

Same here running 0.66.2.0 and have to reboot mostly after my Suface Book was in standby. @schiorean have you found or created an issue for that?

[schiorean]

@cubic3d no I didn't find or add a new issue. I added an issue on the Jetbrains issue tracker though.

[schiorean]

@cubic3d Created a new issue on Github with complete WSL logs #8824.

[sufius]

for me the problem was solved, just by adding the .gradle folder to the ignore/exclude list of the windows defender security setting:

btw: I'm using the WSL2 app provided in the Microsoft store

[nrclark]

for me the problem was solved, just by adding the .gradle folder to the ignore/exclude list of the windows defender security setting:

@sufius now that it's been a couple of weeks - was that the root cause for you? Did excluding from windows defender make the difference?

[sufius]

@nrclark Yes, my problem was solved by this exclusion.