Cannot start WSL (using Win11 22H2)

Question

I think this started happening after I updated my Windows 11. Current version is Windows 11, Version 22H2 (OS Build 22623.1037).

Initially, my Docker Desktop also stopped working, but I uninstalled it to focus on WSL only.

What I tried:

• wsl -l -v --> no response

• Opening Ubuntu 20.04 icon from the start menu --> no response. WSL (using WSL2) is completely unresponsive, and so is my Docker Desktop.

Obviously, I'm expecting WSL to show the shell prompt screen, but it's completely unresponsive!

Answer 1

WSL did change quite substantially in Windows 11 22H2, so the upgrade could be a factor. The good news for troubleshooting this, at least, is that there are now two different "types" of WSL installation. If one is having an issue, then perhaps switching to the other may resolve. The two "types" are:

• WSL as a Windows feature -- This is the original (now old) way that WSL was delivered. This is known as the "In-box" version of WSL, since it "comes with Windows" and just has to be enabled.

• WSL as a Store (UWP) app -- This is the new method of installing WSL. It's been in Preview since October 2021, but with Windows 11 22H2, it became the official way of installing new WSL releases. A wsl --update in Windows 11 22H2 should (in my experience) switch from the in-box version to the Store version. More accurately, both are enabled, but the Store version takes priority.

Both versions still require the "Virtual Machine Platform" feature (or Hyper-V) to be enabled in Windows in order to provide WSL2 functionality. It would be useful to verify, via the Turn Windows features on or off settings, that the VMP is enabled. If not, enable it and reboot. It's unlikely, IMHO, that it is disabled, since you would normally receive an error message when starting a WSL2 distribution (rather than unresponsiveness). Still worth double-checking though.

The easiest way to determine if you are using the In-box or Store/App, if it is working, would be to check the Start menu for "Windows Subsystem for Linux". If present, that would indicate the Store version. If absent, the in-box.

Depending on the results:

• If you find you are using the in-box version, try installing the Store version. You can do that from the Microsoft Store page directly.

  A reboot is advisable, especially in your case.

  Then check wsl --version. If it reports component versions, then the WSL App is installed. See if you can launch your distribution or run wsl -l -v at that point.

• If you are using the Store/App version, try uninstalling it. This can be done simply by searching the Start menu for "Windows Subsystem for Linux", right-clicking, and Uninstall. It can also be done through the normal Add or remove programs settings.

  After uninstalling, confirm in Turn Windows features on or off that the "Windows Subsystem for Linux" feature is enabled, reboot, and try to launch your distribution and run wsl -l -v.

  If so, you may want to try to reinstall the Store version again at that point to see if a simple "uninstall/reinstall" solved the issue.

---

Other troubleshooting steps:

• With the Store version installed, try running in the new "Safe mode". To do so, create or edit, in your Windows user profile directory, .wslconfig with the following:

  [wsl2]
  safeMode = true
  

  Try to run it again.

• Run the following in PowerShell:

  Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\
  

  Look for any "oddness" in here, which I know is tough to quantify since you don't have a known "good state". However, an obvious example of a potential problem would be garbled characters in a directory or distribution name.

• Uninstall everything possible (other than the distribution) and reinstall. That includes uninstalling the WSL Store App and turning off the Windows Subsystem for Linux and Virtual Machine Platform features.

  Turning back on each component individually (starting with VMP, then WSL feature) might give you some indication of a deeper issue. Watch carefully during any reboots for messages pertaining to the component installation.

• In the worst case (but not yet, let's keep troubleshooting for a bit, if needed) you might try backing up and deleting the existing WSL registry entries found there. You can back up the WSL2 disk image itself from the directory specified in the BasePath property, under the LocalState directory there. The filename for WSL2 images should always (currently) be ext4.vhdx. That image can be restored if and when you get the Subsystem itself back to a working state.