WSL 2.7.12 → 2.7.13 automatic MSI upgrade leaves runtime VHDs pending deletion; ERROR_FILE_NOT_FOUND after reboot #41529

Windows Version

Windows 11 25H2, 10.0.26200.8037 (Hyper-V guest)

WSL Version

2.7.12.0 → 2.7.13.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2 (6.18.33.2-microsoft-standard-WSL2)

Distro Version

Ubuntu installed with wsl --install ubuntu; exact release not recorded

Other Software

Hyper-V with nested virtualization; PowerShell test clients. No Docker Desktop required.

Repro Steps

We reproduced a post-reboot failure after the packaged automatic updater upgraded WSL 2.7.12.0 to 2.7.13.0 while WSL clients were repeatedly starting. The detailed MSI log and registry/file snapshots show pending deletion of runtime VHDs surviving their replacement.

Environment: disposable generation-2 Hyper-V VM, nested virtualization enabled, 4 vCPUs, 4 GiB RAM. Start from a checkpoint with WSL 2.7.12.0 and a working WSL 2 distro named Ubuntu.

1. Download the official 2.7.13 MSIX bundle. SHA256: 3c481b5739a988b22cb81f21737d0f496473ee69bffb1885cc52a77a02ce9fa2.
2. Verify baseline Ubuntu starts with wsl.exe -d Ubuntu -u root --exec /bin/true.
3. In elevated guest PowerShell, set UpgradeLogFile (REG_SZ) under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI to an explicit log path, to retain the verbose MSI log. Set AutoUpgradeViaMsix (REG_DWORD) to 1.
4. Start three PowerShell jobs. Each runs wsl.exe -d Ubuntu -u root --exec /bin/sleep 1 repeatedly for 180 seconds, with 200 ms between calls. Each client has a 5-second timeout, after which only that wsl.exe client is killed.
5. Three seconds after starting the jobs, run Add-AppxPackage -Path <official-2.7.13.msixbundle>. Let the packaged WslInstaller service perform the MSI upgrade. No manual MSI fallback is used.
6. Wait for the automatic installer summary to report completion. Our failing run returned 3010. Before reboot, inspect PendingFileRenameOperations under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager and verify the runtime files still exist.
7. Normally shut down and start the guest, then run wsl. Both runtime VHDs are now absent and startup fails.

Scope and limitations: This invokes the packaged automatic installer via MSIX deployment; it does not reproduce Microsoft Store download/scheduling end to end. One complete failing upgrade run has been captured, with persistent failure after reboot; a deterministic minimal reproducer and repeated clean-baseline trials are still pending. During this run, additional interactive wsl --install ubuntu and wsl calls occurred. The host controller was temporarily paused before reboot to preserve evidence; the guest installer completed independently. The eventual reboot was normal guest shutdown/start, not forced power-off.

Controls from the same healthy baseline: (A) shutting down WSL then installing the official MSI returned 0 and worked before/after reboot; (B) shutting down WSL then deploying the same MSIX bundle also returned 0 and worked before/after reboot. In B, both startup probes exited 0 and the runtime files remained present.

The original host also failed after an automatic 2.7.12 -> 2.7.13 upgrade returning 3010; MSI Repair restored it. The attached detailed evidence is from the isolated VM, which has not been repaired.

Expected Behavior

WSL should retain its runtime VHDs and launch Ubuntu after upgrade and reboot.

Actual Behavior

Before reboot, WSL briefly displayed “WSL 正在完成升级...” and subsequently launched successfully. After reboot:

The system cannot find the file specified.
Error code: Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND

The MSI registry version remains 2.7.13.0, but C:\Program Files\WSL\system.vhd and C:\Program Files\WSL\tools\modules.vhd are missing. tools\kernel remains present.

Evidence in the attached verbose MSI log:

• Line 4628: Info 1903.Scheduling reboot operation: Deleting file C:\Program Files\WSL\system.vhd. Must reboot to complete operation.
• Line 4701: the same pending deletion for tools\modules.vhd.
• Lines 9140 and 9322: the new installation overwrites these same files.
• The automatic installer summary reports MSI upgrade result: 3010.
• state-before-reboot.json: both files exist, but both paths are still in PendingFileRenameOperations with empty destinations.
• state-after-reboot.json: both files are missing and PendingFileRenameOperations is empty.

This supports delayed deletion surviving replacement as the immediate failure mechanism. The exact race allowing the files to remain in use still needs investigation.

Potentially related: #40762, #40488 and #40625. This report adds an instrumented upgrade reproduction with before/after-reboot evidence; please link or consolidate if already covered. We have not tested whether the newer service-stop/uninstall changes cover upgrading from 2.7.12.

In 2.7.13 WslInstaller.cpp, 3010 is normalized to success, and default detailed logs are removed on success unless UpgradeLogFile is configured. Version-based upgrade detection also does not establish that the runtime VHDs remain present. These are observations, not a proposed fix.

Diagnostic Logs

Attached ZIP contains the sanitized verbose MSI log, installer summary/result, pending rename list, pre/post-reboot file and service snapshots, client activity, event excerpts, successful MSIX control results, and the original test script as text. The script documents the actual harness and requires adapting lab-specific paths/VM ID; it is not a standalone minimal reproducer. No credentials or host PowerShell transcripts are included. Personal identifiers were replaced; timestamps, Windows runtime paths and diagnostic entries were retained.

MSI timestamps and snapshot timestamps are UTC+08:00; automatic installer summary timestamps are UTC. No WSL ETW trace was captured in this run. A checkpoint of the failing VM is preserved.

Screenshot: actual post-reboot WSL startup error.

wsl-upgrade-repro-evidence.zip