Skip to content
WSLFix Published Updated 4 min readViews unavailable

Fixing a WSL Distro That Won't Start or Hangs on 'Installing'

Working through Windows features, firmware virtualization, kernel version, and disk space in order to find why a WSL distro hangs or refuses to start.

A WSL distro that hangs on “Installing, this may take a few minutes” indefinitely, or an existing distro that suddenly refuses to launch, usually traces to one of a small number of well-known specific causes.

Step 1: check Windows feature prerequisites are actually enabled

Windows Features → confirm both:
  "Windows Subsystem for Linux"
  "Virtual Machine Platform" (required specifically for WSL2)

A distro hanging specifically on first install is frequently traced to one of these two required Windows features not actually being enabled, even if wsl --install appeared to run without error.

Step 2: check virtualization is enabled in firmware

Task Manager → Performance tab → CPU →
  check "Virtualization: Enabled"

WSL2 requires hardware virtualization support enabled at the firmware (BIOS/UEFI) level — this can be disabled by default on some systems, or disabled by IT policy on managed corporate machines, and WSL2 specifically (not WSL1) cannot function without it.

Step 3: check for a conflict with another virtualization product

Some third-party virtualization software, antivirus products with virtualization-based protection features, or certain other hypervisor software can conflict with the Hyper-V-based virtualization WSL2 depends on — temporarily disabling other virtualization software is a useful diagnostic step if WSL2 specifically stopped working after installing something else.

Step 4: check the WSL kernel version is current

wsl --update

An outdated or corrupted kernel component is a common cause of a distro hanging or failing during startup specifically — running this update command, then fully restarting WSL2 via wsl --shutdown, resolves a meaningful fraction of these cases.

Step 5: check Windows Event Viewer for a more specific error

Event Viewer → Windows Logs → Application →
  filter for source "WSL" or recent errors around
  the time of the failed launch attempt

A generic “Installing” hang in the terminal window often has a considerably more specific underlying error logged in Windows’ own Event Viewer, worth checking before assuming a cause.

Step 6: try a full unregister and reinstall as a more drastic fix

wsl --unregister <DistroName>

This deletes the distro’s entire filesystem — only do this after confirming you don’t need anything inside it, or after exporting a backup first. Reinstalling from a clean state resolves cases where the distro’s own internal state, rather than the WSL platform itself, has become corrupted.

Step 7: check for a Windows Update that changed WSL platform behavior

A distro that worked previously and suddenly stopped, immediately following a Windows Update, points toward something in that specific update affecting WSL2’s virtualization stack — checking release notes for the specific recent update, or searching for other users reporting the same regression, can confirm this pattern quickly.

Step 8: verify sufficient disk space is actually available

WSL2’s dynamically-expanding virtual disk needs free space on the underlying Windows drive to grow into — a distro failing specifically during an operation that needs to expand the virtual disk, on a nearly-full drive, can look like a generic startup failure rather than the actual disk-space issue underneath.

Why systematically ruling out each layer beats guessing

A distro startup failure can originate at the Windows feature level, the firmware virtualization level, the WSL kernel level, or the distro’s own internal state — working through these layers in order, from most fundamental (firmware, Windows features) to most specific (the individual distro), finds the actual cause faster than randomly trying fixes aimed at the wrong layer.

Checking enterprise policy specifically on managed machines

On a corporate or otherwise centrally managed Windows machine, a distro that never worked (rather than one that previously worked and stopped) may simply be blocked by Intune or Group Policy restricting WSL availability entirely, rather than any of the technical causes above. Checking with whoever administers the machine’s policy — before spending time on firmware or kernel-level troubleshooting — is worth doing first specifically on managed hardware, since no amount of local troubleshooting resolves a deliberate administrative block.

Capturing diagnostic details before trying a destructive fix

Before reaching for wsl --unregister, capture the exact error text, the Windows build number, and the output of wsl --version and wsl --status — this information is what actually lets you (or anyone helping you) confirm whether your specific symptom matches a known, already-fixed issue in a newer WSL release, rather than needing to rediscover the cause again after a reinstall that might not even address it.

Related:

Sources:

Comments