WSL 2.7.1.0 pre-release update forces system restart via msiexec without user consent, then fails with unhelpful ERROR_FILE_NOT_FOUND when HypervisorPlatform is not enabled

[syed-dawood]

Two issues with WSL 2.7.1.0 pre-release update

Issue 1: Forced system restart during update without user consent

When updating from WSL 2.7.0.0 to 2.7.1.0 (pre-release) while WSL was actively running, the update process:

1. Forcibly killed all active WSL sessions using ForceApplicationShutdownOption, ForceTargetApplicationShutdownOption (no warning or prompt)
2. Initiated an automatic system restart via msiexec.exe just 1 second after the package registration completed — without any user consent dialog

This caused immediate data loss risk and disrupted work in progress.

Issue 2: Unhelpful error message after reboot

After the forced reboot, WSL 2.7.1.0 fails to start with:

Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND

The actual underlying error is 0xC0370103 ("Hypervisor not available") — the system has VirtualMachinePlatform enabled but NOT HypervisorPlatform. WSL 2.7.0.0 worked fine with only VirtualMachinePlatform.

The error message ERROR_FILE_NOT_FOUND is completely misleading and does not tell the user what to do. The MessageEnableVirtualization string in WSL's resources only mentions "Virtual Machine Platform" — it never mentions HypervisorPlatform.

Environment

• Windows version: 10.0.26200.8037
• WSL version: 2.7.1.0 (pre-release, updated from 2.7.0.0)
• Kernel version: 6.6.114.1-1

Windows Optional Features State

Feature	State
VirtualMachinePlatform	Enabled
HypervisorPlatform	Disabled (never was enabled)
Microsoft-Hyper-V-All	Disabled
Microsoft-Windows-Subsystem-Linux	Disabled

Evidence from Windows Event Logs

AppX Deployment Events (March 25, 2026)

4:56:00 PM — WSL 2.7.0.0 deprovision starts

4:56:02 PM — Remove operation starts with ForceApplicationShutdownOption, ForceTargetApplicationShutdownOption:

Started deployment Remove operation on a package with main parameter
MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.0.0_x64__8wekyb3d8bbwe

4:56:35 PM — Old WSL package moved to Deleted folder

4:56:36 PM — WSL 2.7.1.0 staging begins

4:56:37 PM — Registration with forced shutdown flags:

Started deployment RegisterByPackageFamilyName operation on a package with main parameter
MicrosoftCorporationII.WindowsSubsystemForLinux_8wekyb3d8bbwe and Options
ForceApplicationShutdownOption,ForceTargetApplicationShutdownOption

4:56:38 PM — WSL 2.7.1.0 registration completed successfully

System Event Log — Forced Restart

4:56:39 PM — Event ID 1074:

The process msiexec.exe has initiated the restart of computer [REDACTED]
on behalf of user NT AUTHORITY\SYSTEM for the following reason:
No title for this reason could be found
Reason Code: 0x80030002
Shutdown Type: restart
Comment: The Windows Installer initiated a system restart to complete
or continue the configuration of 'Windows Subsystem for Linux'.

This is an automatic system restart initiated by SYSTEM — no user consent was requested.

HCS (Host Compute Service) Events — After Reboot

4:58:31 PM — HCS service started after reboot

5:01:57 PM — VM creation fails with 0xC0370103 (hypervisor not available):

Start compute system, result 0xC0370103

5:01:58 PM — Cascading errors:

Queue system notification: 6 / 0x80070002
Queue system notification: 3 / 0x80070002

Source Code Evidence

In src/windows/common/wslutil.cpp, UpdatePackageImpl() uses:

DeploymentOptions::ForceApplicationShutdown | DeploymentOptions::ForceTargetApplicationShutdown

This force-kills WSL sessions during update without any user notification.

Expected Behavior

1. WSL update should NOT force a system restart without user consent. At minimum, a dialog should warn: "WSL needs to restart your computer to complete the update. Save your work."
2. WSL update should NOT use ForceApplicationShutdown when WSL sessions are actively running — or at minimum warn the user first
3. If HypervisorPlatform is now required by 2.7.1.0, the error message should clearly state: "Please enable the 'HypervisorPlatform' Windows feature" instead of the misleading ERROR_FILE_NOT_FOUND
4. If the requirement changed from 2.7.0.0 → 2.7.1.0, the release notes should document this breaking change

Workaround

Manually enable HypervisorPlatform and reboot:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform

Steps to Reproduce

1. Have WSL 2.7.0.0 working with only VirtualMachinePlatform enabled (no HypervisorPlatform)
2. Have active WSL sessions running
3. Run wsl --update --pre-release
4. Observe: active sessions are forcibly killed, system reboots automatically
5. After reboot, try wsl -d Ubuntu
6. Observe: ERROR_FILE_NOT_FOUND error — no indication of what's actually wrong

[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'.

[syed-dawood]

The issue has been resolved on my end by manually enabling HypervisorPlatform and rebooting, so I can no longer reproduce the ERROR_FILE_NOT_FOUND / 0xC0370103 error to capture live WPR traces via collect-wsl-logs.ps1.

However, all the relevant evidence has been captured and included in the issue body above from Windows Event Logs collected at the time of the failure:

1. System Event Log (Event ID 1074) — Shows msiexec.exe initiated an automatic system restart at 4:56:39 PM on behalf of NT AUTHORITY\SYSTEM with comment: "The Windows Installer initiated a system restart to complete or continue the configuration of 'Windows Subsystem for Linux'"

2. AppX Deployment Events — Full timeline showing WSL 2.7.0.0 removal with ForceApplicationShutdownOption,ForceTargetApplicationShutdownOption flags, followed by WSL 2.7.1.0 staging/registration at 4:56:34-38 PM

3. HCS Operational Events — Shows Start compute system, result 0xC0370103 at 5:01:57 PM (after reboot), confirming the hypervisor was not available

4. Windows Feature State — VirtualMachinePlatform = Enabled, HypervisorPlatform = Disabled. WSL 2.7.0.0 worked with only VirtualMachinePlatform; 2.7.1.0 did not.

5. CBS Logs — Confirmed HypervisorPlatform was never enabled (always in "Staged" / "Default" state) prior to manually enabling it.

System info:

WSL version: 2.7.1.0
Kernel version: 6.6.114.1-1
Windows version: 10.0.26200.8037

The two core issues remain valid regardless of reproduction:

• WSL update triggered an automatic system restart via msiexec without any user prompt/consent
• The error message ERROR_FILE_NOT_FOUND is misleading when the actual problem is 0xC0370103 (hypervisor not available due to missing HypervisorPlatform feature)

[syed-dawood]

Supplementary Evidence

Since the issue was resolved by manually enabling HypervisorPlatform, I cannot reproduce for a live WPR trace. However, here is comprehensive evidence captured from Windows Event Logs, CBS logs, and system state that covers the same diagnostic ground the collection script would.

---

1. Complete Reboot Timeline (System Event Log)

4:56:39 PM — Event ID 1074 (User32) — MSI-initiated restart:

Process: msiexec.exe
User: NT AUTHORITY\SYSTEM
Reason Code: 0x80030002
Shutdown Type: restart
Comment: The Windows Installer initiated a system restart to complete
or continue the configuration of 'Windows Subsystem for Linux'.

4:56:52 PM — Event ID 6006 (EventLog) — Event Log service stopped (shutdown in progress):

The Event log service was stopped.

4:56:59 PM — Event ID 13 (Microsoft-Windows-Kernel-General) — OS shutting down:

The operating system is shutting down at system time 2026-03-25T21:56:59.110025200Z.

4:57:14 PM — Event ID 12 (Microsoft-Windows-Kernel-General) — OS started (boot):

The operating system started at system time 2026-03-25T21:57:13.500000000Z.

4:57:32 PM — Event ID 6009 (EventLog) — Boot info:

Microsoft (R) Windows (R) 10.00. 26200  Multiprocessor Free.

4:57:32 PM — Event ID 6005 (EventLog) — Event Log started:

The Event log service was started.

5:15:28 PM — Event ID 1074 (User32) — User-initiated restart (after experiencing the error, I manually rebooted):

Process: StartMenuExperienceHost.exe
Reason: Other (Unplanned)
Shutdown Type: restart

Key finding: Only 20 seconds elapsed between the msiexec restart request (4:56:39) and the OS shutdown (4:56:59). No user consent was possible in this window.

---

2. AppX Deployment Log — Full Update Sequence

The Microsoft-Windows-AppXDeploymentServer/Operational log shows the complete update flow:

4:56:00 PM — Deprovision of old WSL begins:

Started deployment DeprovisionPackageOperation on package
MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.0.0_x64__8wekyb3d8bbwe

4:56:02 PM — Remove with forced shutdown flags:

Started deployment Remove operation on package
MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.0.0_x64__8wekyb3d8bbwe

4:56:35 PM — Old package moved to Deleted:

Moving package folder MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.0.0_x64__8wekyb3d8bbwe
to \Deleted\...  Result: 0x0.

4:56:36-37 PM — New WSL 2.7.1.0 staged and registered:

Started deployment RegisterByPackageFamilyName operation with Options
ForceApplicationShutdownOption,ForceTargetApplicationShutdownOption

4:56:38 PM — Registration completed, 1 second before msiexec triggers reboot.

---

3. HCS (Host Compute Service) Events — Post-Reboot Failure

From Microsoft-Windows-Hyper-V-Compute-Admin log:

4:58:31 PM — HCS service started after reboot:

The Host Compute Service started successfully.

From Microsoft-Windows-Hyper-V-Compute-Operational log (captured before fix):

5:01:57 PM — VM creation attempted, hypervisor not available:

[61CC320F-6F21-41B6-87E6-980966D8855E] Start compute system, result 0xC0370103

5:01:57-58 PM — Cascading notification errors:

Queue system notification: 14 / 0x00000000
Queue system notification: 6 / 0x80070002
Queue system notification: 3 / 0x80070002

0xC0370103 = WHV_E_UNKNOWN_CAPABILITY / "The hypervisor is not present on this system" — but WSL reported this as ERROR_FILE_NOT_FOUND.

---

4. CBS Log — HypervisorPlatform Was NEVER Enabled

From C:\Windows\Logs\CBS\CBS.log at the time I manually enabled it (5:06 PM, after experiencing the error):

2026-03-25 17:06:39 CBS Update: Setting Install State,
  Package: Microsoft-Windows-HyperV-OptionalFeature-HypervisorPlatform-Disabled-Package,
  Update: HypervisorPlatform, current State: Default, new state: On

current State: Default = the feature was never enabled by the user or system.

The plan entries confirm all HypervisorPlatform packages were in Staged state (available but not installed):

Plan: Package: HyperV-HypervisorPlatform-Package~31bf3856ad364e35~amd64~~10.0.26100.7920,
  current: Staged, pending: Default, start: Staged, applicable: Installed

This confirms WSL 2.7.0.0 was functioning with VirtualMachinePlatform alone, and HypervisorPlatform was never part of the system configuration.

---

5. Windows Feature State (at time of failure)

Captured via Get-WindowsOptionalFeature -Online before applying the fix:

Feature	State
VirtualMachinePlatform	Enabled
HypervisorPlatform	Disabled
Microsoft-Windows-Subsystem-Linux	Disabled
Microsoft-Hyper-V-All	Disabled
Microsoft-Hyper-V-Hypervisor	Disabled

---

6. System Info

WSL version: 2.7.1.0
Kernel version: 6.6.114.1-1
WSLg version: 1.0.73
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8037

AppX Package: MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.1.0_x64__8wekyb3d8bbwe
Status: Ok
Install Location: C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.1.0_x64__8wekyb3d8bbwe

Default Distribution: Ubuntu
Default Version: 2

---

Summary

The evidence proves:

1. msiexec.exe force-rebooted the system at 4:56:39 PM as NT AUTHORITY\SYSTEM — 20 seconds later the OS was shutting down (4:56:59 PM). No user prompt/dialog appeared.
2. The reboot was triggered by WSL's MSI component during the 2.7.0.0 → 2.7.1.0 update, with the explicit comment: "The Windows Installer initiated a system restart to complete or continue the configuration of 'Windows Subsystem for Linux'"
3. After reboot, HCS failed with 0xC0370103 (hypervisor not present) but WSL surfaced this as ERROR_FILE_NOT_FOUND — a completely misleading error
4. HypervisorPlatform was never enabled (CBS logs: current State: Default, start: Staged) — WSL 2.7.0.0 worked without it

[shuaiyuanxx]

Thanks for the detailed report.

I attempted to repro this on a clean machine by updating WSL with active sessions running. The update completed successfully, but no system reboot was triggered. WSL started normally afterward.

Looking at the code, ForceApplicationShutdown in install.cpp only terminates WSL processes for the package update, and the MSI configuration does not include an explicit reboot action. The forced reboot you experienced may have been caused by something else, rather than by the WSL update itself.

For the ERROR_FILE_NOT_FOUND after reboot — this is a known issue when an MSI upgrade is interrupted. Running wsl --update or wsl --install --no-distribution should repair it.

If you can reproduce the forced reboot again, please upload diagnostic logs so we can investigate what triggered it on your system.

[benhillis]

HypervisorPlatform is not required to run Windows Subsystem for Linux. Only the "Virtual Machine Platform" optional component.

I suspect somehow on your machine the Hypervisor got disabled, and enabling the hypervisor platform OC re-enabled it.