When WSL Lies: Fixing the CreateVm / HCS / ERROR_FILE_NOT_FOUND Crash After a Windows Update

It worked five minutes ago

You restarted your PC like you've done a thousand times. You open your terminal, type wsl, and instead of your familiar shell you get this:

Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND

That's the panic moment. Sitting inside that distro is your whole dev environment — years of setup, hundreds of gigabytes of work, all in a Linux disk that suddenly "won't boot." And the error helpfully tells you a file wasn't found, without saying which one.

Here's the good news, up front: your data is almost certainly fine, and the error is lying to you about why this happened. That second part is the whole point of this post — chase the literal words of this error and you'll waste an afternoon hunting a missing file that was never the problem.

What the error actually means (and why it's misleading)

ERROR_FILE_NOT_FOUND here is a wrapper, not the real error. To see why, you need one piece of mental model:

WSL2 doesn't run Linux "natively" — it runs your distro inside a lightweight virtual machine. The component that builds that VM is HCS, the Host Compute Service: the Hyper-V layer Windows uses to stand up containers and VMs. So CreateVm/HCS/ERROR_FILE_NOT_FOUND isn't "a Linux file is missing." It's HCS failing to create the virtual machine, and surfacing a generic "file not found" code on the way out.

Once you reframe it from "my distro is corrupt" to "the VM layer underneath my distro won't start," every step that follows makes sense.

First move: confirm your data is safe

Before you touch anything, prove to yourself the disk is intact. Your distro's filesystem lives in a single virtual disk file, ext4.vhdx. Find it and check it has real size:

Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Recurse -Filter "ext4.vhdx" |
  Select-Object FullName, @{ n = "GB"; e = { [math]::Round($_.Length / 1GB, 1) } }

If that returns a path and a size of many gigabytes, your data is sitting right there, perfectly intact. Which leads to the single most important rule in this whole post:

The diagnostic ladder: rule out the easy stuff

Work from the outside in. Each rung below is the real fix for some people who hit this error — and none of them was the fix here. That's the lesson worth internalizing: the same error message has many possible causes, so you rule them out rather than guess.

1. Is WSL itself healthy? wsl --version should report your WSL, kernel, and WSLg versions. If this errors outright, you've got an install problem, not a VM problem.
2. Is your config the culprit? Temporarily rename %UserProfile%\.wslconfig (e.g. to .wslconfig.bak) and try again with defaults. A bad memory/processor/networking line here can stop the VM from starting.
3. Is the hypervisor set to launch? Run bcdedit and check hypervisorlaunchtype. If it's off, set it back: bcdedit /set hypervisorlaunchtype auto, then reboot.
4. Are the Windows features on? This is the big one most guides get half-right: HypervisorPlatform is a separate feature from VirtualMachinePlatform, and it's often the missing piece. Make sure both are enabled. (Enabling it helped — but it still wasn't the full fix here.)
5. Are the services running? Check vmcompute (Hyper-V Host Compute Service) and hns (Host Network Service). Note: LxssManager and vmms not existing is normal on modern WSL — chasing those two is a common false alarm.
6. Is virtualization on in the BIOS? Run systeminfo and look for "A hypervisor has been detected." If virtualization is disabled in firmware, nothing above the BIOS can fix it.

Finding the real error code

Every rung above came back healthy, which is exactly when you stop guessing and go ask Windows what actually failed. HCS logs its real result to an event channel:

Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-Compute-Operational" |
  Select-Object -First 20 TimeCreated, Id, Message

The line that mattered:

Create compute system, result 0xC0370103

0xC0370103 is a hypervisor-partition error — the "hypervisor not available" class of failure. Not a missing file. This is where guessing ends and knowing begins: the VM layer is present, but Windows can't get a working hypervisor partition to build the VM on.

The red herrings

Search that error and you'll get a wall of confident "fixes." Here's why the popular ones mostly don't apply:

• netsh winsock reset — wrong layer entirely. That resets networking; your VM isn't failing to network, it's failing to be created.
• wsl --install -d Ubuntu — dangerous if your distro is still registered (see the warning above). It "works" for people whose distro is already gone.
• Rolling back to WSL 2.6.3 — works for some, but 2.6.3 is also blamed for breaking WSL elsewhere. It's situational, not universal.

The meta-skill here: vet every forum fix against your confirmed state. Does their error code match yours? Is their distro registered like yours? If not, their fix isn't your fix.

The actual fix: repair, don't reinstall

The root cause was mundane: a Windows update displaced WSL's service registration. The platform got knocked loose — not your distro, not your disk. So the fix isn't a reinstall, it's an in-place repair of the WSL version you already have:

msiexec.exe /f "wsl.2.7.8.0.x64.msi" /qb

/f means repair: it re-lays WSL's files and re-registers its services without touching your distro or its data. Download the MSI that matches your installed version from the WSL releases page — repairing with the wrong version is just an upgrade/downgrade in disguise.

The snag nobody warns you about: the locked service

This is where the "trivial" repair ate an hour. The installer immediately wedges on:

Service 'WSL Service' (WSLService) could not be stopped.

…because Docker Desktop and live WSL processes are holding the service open. The repair can't stop a service that's in use. Kill them first, then re-run the repair:

taskkill /F /IM wslservice.exe
taskkill /F /IM "Docker Desktop.exe"

Side-tip: don't reach for wsl --shutdown to do this — it tends to just hang. Nine times out of ten that "hang" is the QuickEdit console freeze (you clicked into the window and selected text); press Esc or Enter and it unsticks. Honest takeaway: the repair command was trivial; the locked service was the real time-sink.

Verify and restore

1. Reboot.
2. Test clean first, with defaults: wsl -d Ubuntu. If your shell comes up, you're back.
3. Rename your .wslconfig back from .wslconfig.bak.
4. Confirm your tuning actually took: free -h && nproc (memory and CPU count should match your config).
5. Reset anything you toggled while debugging — sleep timers, firmware settings, services you stopped.

Don't get burned twice: a real backup strategy

The scare is a good prompt to fix the actual risk. You don't need to image the whole distro — most of that hundreds-of-gigs is re-downloadable anyway (models, Docker layers, package caches). Back up what's irreplaceable:

• The small stuff that can't be re-downloaded: dotfiles, SSH/GPG keys, cloud credentials, tool configs. A targeted tarball of those is tiny.
• Encrypt it. That tarball holds private keys in plaintext — it should never sit around unencrypted.
• Audit your git repos for unpushed work. If everything's pushed, GitHub is your project backup. Unpushed branches are the only code truly at risk.

And the quick-reference for next time, because there will be a next time: kill Docker + wslservice.exe → msiexec /f on your WSL MSI → reboot.

This one was mine to untangle — I run my own WSL dev box — but the shape of it generalizes: when an error blames a missing file, check whether something underneath it just got knocked loose by an update.