WSL 2.7.3 fails to start with ERROR_FILE_NOT_FOUND - missing system.vhd and modules.vhd

[Geol2]

Please check out #40488 for solution, root cause and follow up.

---

Environment

• WSL Version: 2.7.3.0 (downgraded to 2.6.3.0 as workaround)
• Windows Version: Windows 11 Pro 25H2 (OS Build 26200.8457)
• Architecture: x64

Problem

After updating to WSL 2.7.3, all distributions fail to start with the following error:
Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND

Reproduction Steps

1. Install WSL 2.7.3 via winget install --id Microsoft.WSL --force
2. Reboot Windows
3. Run wsl -d Ubuntu-22.04
4. Error occurs immediately

Investigation

wsl --update reports already up to date — this is not fixable via update:
업데이트 확인 중입니다.
Linux용 Windows 하위 시스템 최신 버전이 이미 설치되어 있습니다.

C:\Windows\System32\lxss\tools contains only bsdtar, kernel file is missing:
Mode LastWriteTime Length Name

-a---- 2026-01-05 858800 bsdtar

C:\Program Files\WSL\ is missing system.vhd and tools\modules.vhd:
Expected (working state per #40318):
C:\Program Files\WSL\system.vhd
C:\Program Files\WSL\tools\kernel
C:\Program Files\WSL\tools\modules.vhd
Actual (under 2.7.3):
C:\Program Files\WSL\tools\bsdtar (only this file present)

WSL Kernel AppX package is not installed separately:

Get-AppxPackage | Where-Object { $_.Name -like "*WSL*" }
# Returns only MicrosoftCorporationII.WindowsSubsystemForLinux
# No separate kernel package found

Note on Windows Build

Issue #40318 reported this on build 26200.8246.
This issue reproduces on 26200.8457 as well — confirming it is not fixed in newer Windows builds.

Workaround

Downgrading to WSL 2.6.3 resolves the issue:

msiexec /i wsl.2.6.3.0.x64.msi /quiet

After downgrade, system.vhd and modules.vhd are restored and all distributions start normally.

Additional Context

Installation was interrupted (system shutdown during update).
WSL 2.7.3 was marked as installed, but critical files were missing.
No recovery mechanism exists:

• wsl --update reports already up to date
• Reinstalling 2.7.3 via winget --force does not restore missing files
• Only workaround is downgrading to 2.6.3

Related

• 2.7.3 #40318 - Similar report of missing system.vhd and modules.vhd under 2.7.3

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Geol2]

wsl-install-log.zip

Attaching the WSL logs as requested.

However, please note that these logs were collected after downgrading to 2.6.3 as a workaround, so they do not capture the actual failure state under 2.7.3. Reproducing the issue again would require reinstalling 2.7.3, which I'd prefer to avoid given the instability.

The wsl-install-log.txt may still be useful — it shows the full install history including the 2.7.3 → 2.6.3 downgrade sequence, and an MSI result code of 1641 (reboot required) during the 2.7.3 installation.

[github-actions]

No logs.etl found in the archive. Make sure that you ran collect-wsl-logs.ps1 as administrator and that the logs.etl file is in the archive.

Diagnostic information

appxpackage.txt not found
optional-components.txt not found
No logs.etl found in archive.
Error while parsing the logs. See action page for details

[Geol2]

WslLogs-2026-05-21_13-02-58.zip

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

Detected appx version: 2.6.3.0
Found no WSL traces in the logs

[Geol2]

The issue was caused by a system shutdown during the 2.7.3 installation,
which left WSL in a broken state with missing files (system.vhd, modules.vhd, kernel).

Since the failure was caused by an interrupted installation,
I'm unable to reliably reproduce it without intentionally
interrupting another installation — which risks data loss.

The wsl-install-log.txt in the previously attached archive shows
the install history, including MSI result code 1641 (reboot required)
during the 2.7.3 installation sequence.

The core issue I'd like to highlight is that there is no recovery mechanism:
reinstalling 2.7.3 via winget --force did not restore the missing files,
and wsl --update reported already up to date.
The only working solution was downgrading to 2.6.3.

[matthewcieplak]

I think I had this same issue. WSL1 systems worked while WSL2 containers failed to install or open with an error Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/ERROR_FILE_NOT_FOUND after downloading the distro file.

Downgrading to a prior WSL version (wsl.2.4.13.0.x64) caused a different error ("catastrophic failure E_UNEXPECTED"). Upgrading to 2.7.3.0 again after that resolved the issue for me. Seems like the update process from ~2.6 may not preserve all the files needed.

[Geol2]

Related note: another user reports a similar issue where
WSL2 containers failed with the same ERROR_FILE_NOT_FOUND,
but re-upgrading to 2.7.3 resolved it for them —
whereas downgrading to 2.6.3 was the only working solution in my case.

This suggests the file corruption may occur during the update process
itself (not just on interrupted installs), and the recovery path
differs depending on the environment.

[chemwolf6922]

Hi Kory (@Geol2) , This is the same issue as #40488. To help people find the workaround easier. I'll update your description to link to that issue and close this one as duplicate. Thanks.