Background update via MSI/Store (version 2.7.12.0) breaks WSL auto start

[SOndrejcik]

Windows Version

Microsoft Windows [Version 10.0.19045.7663]

WSL Version

2.7.12.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #7663-Microsoft Sat Aug 08 10:24:00 PST 2026

Distro Version

Debian

Other Software

WBS script for the WSL autostart "start_invisible.vbs" called via "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Repro Steps

1. Have an active WSL session running background processes (managed via VBScript or Startup Registry "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run").
2. Windows Update / Windows Store triggers a silent background update of the WSL subsystem (specifically upgrading to version 2.7.12.0 via "wsl.msi" / AppX bundle).
3. The "RestartManager" attempts to restart "wsl.exe" and "wslhost.exe" to apply files but encounters a security/session lock.
4. The system attempts to run a startup VBScript calling "wsl.exe" right after login or during this event.

• the user is not notified why his WSL tools are currently offline,
• the user is not asked to reboot the PC or restart the service.

Expected Behavior

The update installer should safely defer the update until system shutdown, or notify the user via a standard Windows Action Center GUI notification that WSL has been updated and a machine restart is required to use Linux applications again.

Actual Behavior

The update silently bricks the WSL subsystem. All commands (wsl -l -v) report the distros as Stopped and subsequent execution attempts fail silently or crash. No user-facing warning is shown, making the application stack look broken to end-users (in our case, automated car service workstations) until a manual machine reboot is performed.

Diagnostic Logs

Event Viewer captured the following entries during the failure:

• MsiInstaller: Windows Installer started transaction: C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.7.12.0_x64__8wekyb3d8bbwe\wsl.msi. Client Process ID: 8616.
• RestartManager: Application 'C:\Program Files\WSL\wsl.exe' (pid 9896) cannot be restarted - Application SID does not match Conductor SID.
• RestartManager: Application 'C:\Program Files\WSL\wslhost.exe' (pid 10548) cannot be restarted - Application SID does not match Conductor SID.
• RestartManager: Machine restart is required.

20082026_WSL_UPDATE_LOGS.zip

[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

[SOndrejcik]

I did not run the log collection script because the subsystem was already recovered via a hard reboot. The issue is fully described by the Event Viewer logs provided in the attachment of the original report, showing the RestartManager SID mismatch during the background MSI update.

[chemwolf6922]

Hi Stanislav Ondrejčík (@SOndrejcik) .
According to the discussions here: #40786 (review). The plan is to deprecate the MSIX / store distribution path in the future. Which should avoid this problem.
For now, you could try follow the instructions here to disable the auto update: #12675 (comment)

[SOndrejcik]

Hi SOndrejcik . According to the discussions here: #40786 (review). The plan is to deprecate the MSIX / store distribution path in the future. Which should avoid this problem. For now, you could try follow the instructions here to disable the auto update: #12675 (comment)

Hi. Thank You for Your comment and for Your help. I see now there are reports of multiple variations of situations when the update silently breaks the service.

[SOndrejcik]

I am currently testing the below workaround entered into Windows PowerShell as Administrator.

# 1. Create the MSI registry key only if it does not exist (prevents data loss)
if (-not (Test-Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Lxss\MSI")) {
    New-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Lxss\MSI" | Out-Null
}

# 2. Disable automatic WSL upgrades via MSIX/Store
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Lxss\MSI" -Name "AutoUpgradeViaMsix" -Type DWord -Value 0

[embeddedinho]

Hi all, not sure if the following description below directly relate to this issue, but I experienced with this latest release a fail to boot WSL and restrictive access to the distro folder from the explorer.

Problems

Booting the distro in terminal fail

Das System kann die angegebene Datei nicht finden.
Failurecode: Wsl/Service/CreateInstance/CreateVm/HCS/ERROR_FILE_NOT_FOUND Press any key to continue...

for that failure I found out that my system was running the most updated version from WSL

PS C:\WINDOWS\system32> wsl --version
WSL-Version: 2.7.12.0
Kernelversion: 6.18.33.2-2
WSLg-Version: 1.0.73.2
MSRDC-Version: 1.2.7214
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.26200.9168

Distro folder lag of rights to access in explorer

when I tried to access the folder via File Explorer, there was a prompt that shows

Solution

The solution to this was to downgrade the version to the previos one manually
I downloaded the previous release x64.msi asset 2.7.11

PS C:\WINDOWS\system32> wsl --uninstall

-> Manually install the previous downloaded version and that solved my problem, I gain access to my file system from the Distro and it booted without any problems.

PS C:\WINDOWS\system32> wsl --version
WSL-Version: 2.7.11.0
Kernelversion: 6.18.33.2-2
WSLg-Version: 1.0.73.2
MSRDC-Version: 1.2.7214
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.26200.9168
PS C:\WINDOWS\system32>

[chemwolf6922]

Hi embeddedinho .
This is another known issue. The fix is in the 2.9.x pre-release branch.