You reboot Windows, open your Ubuntu terminal, and nothing starts. Every distro throws the same wall of text: WSL CreateVm ERROR_FILE_NOT_FOUND. This guide shows you why it happens and how to get your distros back without losing a single file. The setup here is WSL2 with Ubuntu on Windows 11, and the fix commands run in Windows PowerShell because the broken pieces live on the Windows side of WSL.
The full error looks like this:
The system cannot find the file specified.
Error code: Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND
Press any key to continue...What this error actually means
WSL2 runs your Linux distros inside a tiny, lightweight virtual machine (think of
it as a small computer that Windows boots up in the background just for Linux).
To start that machine, WSL needs a few disk image files. If one of those files is
missing, the machine can’t power on, and Windows reports ERROR_FILE_NOT_FOUND.
The giveaway is that the error hits every distro, not just one.
If only a single distro failed, the problem would be that distro’s own data. When
all of them fail at the CreateVm stage, the shared engine is the
suspect, not your Ubuntu files.
What causes it
When the WSL virtual machine boots, it attaches two disk image files (files
ending in .vhd, which are virtual hard disks). If either one goes
missing, the boot fails:
| File | Where it lives | What it is |
|---|---|---|
system.vhd |
C:\Program Files\WSL\system.vhd |
The WSL system image (about 374 MB) |
modules.vhd |
C:\Program Files\WSL\tools\modules.vhd |
The Linux kernel modules image (about 167 MB) |
Here’s the common way these go missing: a WSL update runs in the background and
asks for a restart to finish swapping files. If that restart gets put off for a
while, the update can be left half-done. On the next boot, the old copies of
system.vhd and modules.vhd are removed, but the new
copies never land. The result is exactly this error. It is not a virus and not a
failing disk, just an update that did not finish cleanly.
Here is what that timeline looked like in a real case, pieced together from the Windows Application log:
| When | What happened |
|---|---|
| A few days earlier | WSL engine files (wsl.exe and friends) updated normally. No problem yet. |
| Evening, a WSL update ran | The installer logged events 1029 and 1038 (restart required, restart deferred). The large .vhd files were queued to be replaced on the next boot. |
| Next restart | The queued swap did not finish: the old system.vhd and modules.vhd were removed, but the new ones never got written. |
| First launch after reboot | Every distro failed with CreateVm/HCS/ERROR_FILE_NOT_FOUND. |
If you want to confirm the same story on your machine, check the installer events in your Application log:
Get-WinEvent -FilterHashtable @{ LogName='Application'; ProviderName='MsiInstaller' } |
Where-Object { $_.Message -match 'Subsystem for Linux' } |
Select-Object -First 10 TimeCreated, Id, Message | Format-List
Look for a restart required entry (event 1038) that was never
followed by a clean completion. Worth knowing: in this case Windows Defender
logged no threat detections and no quarantines for these files, which rules out
antivirus as the cause.
Environment used in this guide
Here are the exact versions this fix was tested on. The fix is not tied to these specific numbers, so it works on other recent builds too. The one rule that matters: the installer you pull the files from must match your installed WSL version (covered in the steps below).
| Component | Version |
|---|---|
| Windows edition | Windows 11 Pro |
| Windows feature version | 25H2 (build 10.0.26200.8390) |
| WSL | 2.7.8.0 |
| WSL kernel | 6.18.33.1-1 |
| WSLg | 1.0.73.2 |
| MSRDC | 1.2.6676 |
| Linux distro | Ubuntu 24.04.1 LTS (Noble Numbat) |
How to check your own versions
Run these so you know what you are working with before you start.
WSL, kernel, and WSLg versions (in Windows PowerShell):
wsl --versionYour Windows edition and feature version:
(Get-CimInstance Win32_OperatingSystem).Caption
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").DisplayVersionYour Ubuntu version:
wsl -d Ubuntu-24.04 cat /etc/os-releasewsl --version: prints the WSL, kernel, and WSLg versions in one go(Get-CimInstance Win32_OperatingSystem).Caption: shows your Windows edition (for example Windows 11 Pro)wsl -d Ubuntu-24.04 cat /etc/os-release: prints the distro name and version (swap in your own distro name)
Prerequisites
- WSL2 with a distro already installed (if you are starting fresh, see How to Install Ubuntu 22.04 in WSL2 on Windows)
- Administrator access on Windows (the files live under
C:\Program Files) - An internet connection to download the matching WSL installer
Step-by-Step Guide
Step 1: Confirm the files are actually missing
Open Windows PowerShell and check whether the two files exist:
Test-Path "C:\Program Files\WSL\system.vhd"
Test-Path "C:\Program Files\WSL\tools\modules.vhd"
If either prints False, you have found the problem. The kernel
(C:\Program Files\WSL\tools\kernel) is usually still there, which is
why wsl --version still works even though no distro will start.
Step 2: Download the matching WSL installer
The cleanest source for these two files is the official WSL installer. The easiest
way to grab it is with winget, the built-in Windows package manager.
First check your installed version so you download the exact match:
wsl --versionThen fetch the installer:
winget install --id Microsoft.WSL --force --accept-source-agreements --accept-package-agreements --disable-interactivity--id Microsoft.WSL: targets the official WSL package--force: re-downloads even if WSL is already present--accept-source-agreements --accept-package-agreements: skips the interactive prompts
The install step itself will likely fail with exit code 1603. That is
expected: if you installed WSL from the Microsoft Store, the standalone installer
refuses to install on top of it. You can ignore the failure, because all you need
is the downloaded file, which now sits at a path like
%LOCALAPPDATA%\Temp\WinGet\Microsoft.WSL.2.7.8\wsl.2.7.8.0.x64.msi.
Step 3: Extract the two files from the installer
Instead of installing, unpack the installer into a temporary folder. The
/a flag runs an administrative extract, which just copies the files
out without registering anything:
$msi = "$env:LOCALAPPDATA\Temp\WinGet\Microsoft.WSL.2.7.8\wsl.2.7.8.0.x64.msi"
$ext = "$env:TEMP\wsl_extract"
msiexec /a "$msi" /qn TARGETDIR="$ext"
After it finishes, the files are at
$ext\PFiles64\WSL\system.vhd and
$ext\PFiles64\WSL\tools\modules.vhd. Adjust the version number in the
path to match what wsl --version reported.
Step 4: Copy the files into place
Run PowerShell as Administrator for this step, since the
destination is under C:\Program Files:
Copy-Item "$env:TEMP\wsl_extract\PFiles64\WSL\system.vhd" "C:\Program Files\WSL\system.vhd" -Force
Copy-Item "$env:TEMP\wsl_extract\PFiles64\WSL\tools\modules.vhd" "C:\Program Files\WSL\tools\modules.vhd" -ForceStep 5: Restart WSL and test
Shut WSL down fully so it picks up the restored files, then launch your distro:
wsl --shutdown
wsl -d Ubuntu-24.04 -- echo "WSL is back"wsl --shutdown: stops the WSL virtual machine so it reloads cleanlywsl -d Ubuntu-24.04 -- echo "WSL is back": starts your distro and runs a quick test command (replace the name with your own distro)
If you see WSL is back, you are done. Your files were never touched,
because each distro keeps its data in a separate package under
%LOCALAPPDATA%\Packages, away from the engine you just repaired. You
can reopen your projects in your editor right away, for example with
VS Code connected to WSL2.
How to confirm the cause for yourself
If you want proof before you start copying files, it helps to rule out the usual suspects first. In most cases of this specific error, all of the following are already fine, which points straight at the missing disk files:
- The hypervisor is running:
(Get-CimInstance Win32_ComputerSystem).HypervisorPresentreturnsTrue - The required Windows features are on: check with
dism /online /get-featureinfo /featurename:VirtualMachinePlatformin an elevated prompt - The kernel and your distro disk both still exist on disk
One thing worth knowing: wsl --update will say it is already
up to date and will not bring the missing files back. It only
compares version numbers, it does not repair deleted files. That is why copying
the files in by hand is the fix.
How to prevent it next time
- When WSL or Windows asks for a restart after an update, reboot soon rather than putting it off for days. A long-delayed restart is what leaves the update half-applied.
- If WSL breaks right after a reboot, check
system.vhdandtools\modules.vhdfirst, before trying a full reinstall. - Always restore files from an installer that matches your installed version, so the disk images line up with your kernel.
Conclusion
The CreateVm/HCS/ERROR_FILE_NOT_FOUND error looks scary, but it
usually comes down to two disk image files that an interrupted update left behind.
Restore system.vhd and modules.vhd from the matching WSL
installer, restart WSL, and your distros come straight back with all your data
intact. If you run into other WSL hiccups after this, take a look at
resolving internet connection issues in WSL2
or
fixing high VSCode memory usage on WSL2.
