WSL2 CreateVm/HCS/ERROR_FILE_NOT_FOUND: The Repair That Worked

WSL worked five minutes ago. Now it cannot find a file.

I restarted Windows, opened a terminal, typed wsl, and got this instead of Ubuntu:

Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND

That is a fairly alarming error when the Linux distro behind it contains years of configuration, development tools, local projects, Docker data, and hundreds of gigabytes of files. The message says a file is missing but does not tell you which file, where it should be, or whether it belongs to Windows, WSL, or Ubuntu. Tremendously helpful stuff.

In my case, the message was misleading. The Ubuntu virtual disk was still there. The problem was in the Windows-side WSL startup path, and repairing the WSL package restored it without reinstalling Ubuntu.

That does not mean this error always has the same cause. The useful lesson is the diagnostic path: confirm the distro and disk still exist, check the virtualization layer, and repair WSL before doing anything destructive to the distro itself.

What does CreateVm/HCS/ERROR_FILE_NOT_FOUND mean?

Short answer: WSL failed while asking Windows to create the lightweight virtual machine used by WSL2. The error does not, by itself, prove that your Ubuntu files are missing.

WSL2 runs a real Linux kernel inside a lightweight utility virtual machine. Microsoft documents that architecture in its comparison of WSL1 and WSL2 . HCS means Host Compute Service, one of the Windows components involved in creating and managing that compute environment.

The error chain is basically a breadcrumb trail:

• Wsl/Service — the request passed through the WSL service.
• CreateInstance — WSL was trying to start the distro.
• CreateVm — startup failed while creating the WSL2 VM.
• HCS — the failure surfaced through the Host Compute Service layer.
• ERROR_FILE_NOT_FOUND — the final Windows error returned through that chain.

The last segment is not enough to tell you which file or object could not be resolved. In this case, chasing Ubuntu files would have been the wrong direction because the failure occurred before the distro could boot.

First check: is the distro still registered?

Start with the safest possible command:

wsl --list --verbose

If Ubuntu still appears in that list, Windows still knows the distro exists. Write down the exact distribution name because you will use it in the next checks. Mine was Ubuntu.

Then check the WSL package and configuration:

wsl --version
          wsl --status

These commands do not prove the VM can start. They simply confirm that wsl.exe can read the installed WSL package and report its version and basic configuration.

Second check: is the Ubuntu virtual disk still there?

WSL2 normally stores a distro's Linux filesystem in an ext4.vhdx virtual hard disk. Microsoft provides a registry-based method for locating the correct disk instead of recursively searching through every app package on the machine.

In PowerShell, replace Ubuntu if your distro has a different name:

$distro = "Ubuntu"

          $registryEntry = Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss |
            Where-Object { $_.GetValue("DistributionName") -eq $distro }

          $vhdPath = $registryEntry.GetValue("BasePath") + "\ext4.vhdx"

          Get-Item $vhdPath |
            Select-Object FullName, @{Name="GB"; Expression={[math]::Round($_.Length / 1GB, 1)}}

Mine returned a roughly 335 GB disk. That was very reassuring: the file had not simply vanished. It was not proof that every byte inside it was healthy, though. A VHDX can exist and still have filesystem damage.

Reinstalling Ubuntu is not the first move either. It may create a clean distro, but a new empty distro does nothing to diagnose the existing one or repair the Windows-side WSL package.

Read-only diagnostic checks

Before changing Windows features or reinstalling anything, gather the current state. These checks are read-only.

1. Temporarily remove custom WSL settings from the equation

The file %UserProfile%\.wslconfig controls the WSL2 virtual machine's memory, CPU, kernel, networking, and other global settings. A bad setting can interfere with startup.

If the file exists, rename it temporarily:

Rename-Item "$env:USERPROFILE\.wslconfig" ".wslconfig.bak"

Do not delete it. If the file was not the problem, you will restore it after WSL is working again.

2. Check the virtualization feature WSL2 actually uses

Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

WSL2 requires Virtual Machine Platform. Older/manual WSL setups may also use the Windows Subsystem for Linux optional component:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Do not enable HypervisorPlatform merely because the name sounds relevant. Microsoft's WSL installation and troubleshooting instructions point to VirtualMachinePlatform for WSL2 VM startup. Windows Hypervisor Platform is a different optional feature and is not a substitute for it.

3. Check whether the hypervisor is allowed to start

Run this from an elevated terminal:

bcdedit /enum | findstr -i hypervisorlaunchtype

If it returns hypervisorlaunchtype Off, the Windows hypervisor is disabled at boot. The corrective command is:

bcdedit /set hypervisorlaunchtype Auto

That command changes the boot configuration, so do not run it unless the check actually returns Off. Reboot after changing it.

4. Check firmware virtualization

Open Task Manager → Performance → CPU and check whether Virtualization says Enabled. You can also use:

systeminfo.exe | Select-String "Hyper-V Requirements|A hypervisor has been detected"

If firmware virtualization is disabled, Windows cannot build the WSL2 virtual machine. That setting must be corrected in the computer's UEFI/BIOS firmware. UEFI means Unified Extensible Firmware Interface; BIOS is the older term most people still use for the same setup screen.

5. Check the relevant Windows services

Get-Service vmcompute,hns,WslService,LxssManager -ErrorAction SilentlyContinue

The exact service names present depend on whether the machine is using the newer packaged WSL or an older inbox version. Do not declare the installation broken because an old guide tells you to restart LxssManager and that service does not exist. Record which services are present and whether they are running or stopped.

Try the supported low-risk recovery steps first

Save any work in Docker, WSL, and VS Code before continuing.

1. Update WSL:

   wsl --update

   If Microsoft Store delivery is the problem, Microsoft also supports:

   wsl --update --web-download

2. Shut down all running distributions and the WSL2 utility VM:

   wsl --shutdown

3. Restart Windows and test wsl -d Ubuntu again.

Microsoft specifically documents wsl --shutdown as the command that terminates running distributions and restarts the WSL2 VM environment. It should come before force-killing the WSL service.

Those steps did not fix my machine, but that still mattered. The WSL command-line tool responded, the distro remained registered, the virtual disk still existed, and a normal update plus VM restart did not restore startup. The failure was narrowing toward the Windows-side WSL package or service state.

Check the Host Compute Service event log

When the basic checks look normal, stop throwing random forum commands at the machine and read the event channel closest to the failure:

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

Match the timestamps against your failed WSL launch. On my system, one of the relevant entries included:

Create compute system, result 0xC0370103

What 0xC0370103 actually means

This code needs to be handled carefully. Microsoft's own Host Compute Service source maps 0xC0370103 to an operation-pending state. It does not mean "the hypervisor is not installed."

In other words, the event supported the conclusion that VM creation was getting stuck or failing to complete inside the HCS path. It did not hand me the root cause on a platter. The useful evidence was the entire pattern, not one hex code.

The fix that worked: repair WSL instead of replacing Ubuntu

The recovery that finally worked was an in-place repair of the installed WSL package. Windows Installer's /f option repairs an installed package; it does not intentionally unregister your Linux distribution.

1. Run wsl --version and record the installed WSL version. If that command fails, check Settings → Apps → Installed apps → Windows Subsystem for Linux.
2. Download the matching MSI package for your CPU architecture from the official Microsoft WSL releases page . Most Windows PCs use x64; Windows on Arm devices use ARM64.
3. Close Docker Desktop, VS Code, Windows Terminal tabs using WSL, and any other WSL-dependent software.
4. Run wsl --shutdown.
5. Open Windows Terminal or Command Prompt as Administrator.
6. Run the MSI repair.

This is the command form that worked on my machine:

msiexec.exe /f "C:\Users\YOUR-NAME\Downloads\wsl.2.7.8.0.x64.msi" /qb

Replace the path, filename, version, and architecture with the package that matches your installation. /f invokes repair and /qb shows a basic progress interface.

The real snag: WSLService could not be stopped

The repair itself was straightforward. Getting the installer to stop the WSL service was the part that wasted my time. The installer reported:

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

Docker Desktop and other WSL-dependent processes can keep the service occupied. Work through this in the following order:

1. Save your work.
2. Quit Docker Desktop from its notification-area icon.
3. Close VS Code, WSL terminals, and other applications using WSL.
4. Run wsl --shutdown.
5. Retry the MSI repair.
6. If the service remains locked, restart Windows and run the repair before opening Docker Desktop or launching a distro.

Only if the service is still stuck after all of that would I force-terminate the remaining processes:

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

Once the locking processes were gone, I reran the same MSI repair and it completed.

Verify the repair before restoring your custom configuration

1. Restart Windows.
2. Run wsl --list --verbose and confirm Ubuntu is still registered.
3. Launch it directly with wsl -d Ubuntu.
4. Check your home directory and important project paths.
5. Leave Docker Desktop closed until the distro starts normally on its own.

If you renamed .wslconfig, restore it only after the clean test succeeds:

Rename-Item "$env:USERPROFILE\.wslconfig.bak" ".wslconfig"
          wsl --shutdown

Launch Ubuntu again, then confirm your configured memory and CPU limits:

free -h
          nproc

If WSL breaks only after restoring .wslconfig, the repair worked and the configuration is a separate problem. Do not mix those two diagnoses.

Back up WSL properly once it is working

Finding a large ext4.vhdx is reassuring, but it is not a backup. Once the distro is healthy, WSL has a supported export command:

wsl --shutdown
          wsl --export Ubuntu "D:\WSL-Backups\Ubuntu-2026-07-13.tar"

Microsoft also supports --vhd when you want a VHDX export of a WSL2 distro. A full export can be enormous, so I would combine occasional full exports with smaller, more frequent backups of the files that cannot simply be downloaded again.

• Commit and push tracked project files to a remote Git repository.
• Remember that Git does not protect uncommitted changes, ignored files, local databases, model data, or secrets.
• Back up dotfiles, configuration, and local databases separately.
• Encrypt any backup containing SSH keys, GPG keys, tokens, or credentials.

Microsoft also warns against modifying or moving WSL's AppData files with normal Windows tools. Use wsl --export or access a running distro through \\wsl$ instead of treating ext4.vhdx like an ordinary folder.

Frequently asked questions

Does ERROR_FILE_NOT_FOUND mean my Ubuntu files were deleted?

Not necessarily. In this error chain, WSL failed while creating the WSL2 virtual machine. First check whether the distro remains listed by wsl --list --verbose and whether its ext4.vhdx still exists. A present VHDX is reassuring, but only successfully mounting and reading the filesystem confirms its contents are usable.

Should I run wsl --unregister and reinstall Ubuntu?

No—not as an early troubleshooting step. Microsoft warns that unregistering a distro permanently deletes its associated data, settings, and software. Repair the Windows-side WSL installation first when the distro and virtual disk still exist.

Does WSL2 require HypervisorPlatform?

WSL2 requires virtualization and the Virtual Machine Platform feature. Windows Hypervisor Platform is a separate optional feature and is not the feature Microsoft's WSL installation guide tells you to enable for WSL2.

What does HCS code 0xC0370103 mean?

Microsoft's Host Compute Service source maps 0xC0370103 to an operation-pending state. It can show that compute-system creation did not complete normally, but it does not prove that the hypervisor is missing or unavailable.

Why did repairing the WSL MSI fix it?

An MSI repair rechecks and repairs the installed WSL package's files and registration. Because that restored WSL without replacing Ubuntu, the evidence points toward a damaged or inconsistent Windows-side WSL installation rather than a deleted distro. It does not reveal the exact file or registration entry that originally failed.