wsl --update --pre-release fails with Error 1603 (WSLService could not be stopped) and wsl --shutdown hangs
- Dominant language
- C++
- Stars
- 33.7k
- Forks
- 1.8k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 116
Description
### Windows Version
Windows 10.0.22631.6199
### WSL Version
2.7.10.0
### Are you using WSL 1 or WSL 2?
- [x] WSL 2
- [ ] WSL 1
### Kernel Version
6.18.33.2-2
### Distro Version
Ubuntu 20.04 (WSL2)
### Other Software
Docker Desktop (with WSL2 backend integration)
### Repro Steps
Run an active WSL2 background engine context using Docker Desktop integration.
Attempt to trigger a core subsystem preview update by executing:
PowerShell
wsl --update --pre-release
The installer detects preview version 2.9.3, but terminates abruptly with an explicit service-stop failure.
Try to clean up the environment manually by initiating a subsystem halt:
PowerShell
wsl --shutdown
The terminal hangs indefinitely on the execution of the shutdown command.
### Expected Behavior
The updater should safely trigger an inner component intercept, signal active distributions to store runtime cache, stop WSLService gracefully, apply the version update payload (2.9.3.0), and wsl --shutdown should close all background VM endpoints within a few seconds without locking up the terminal.
### Actual Behavior
The installer fails with an immediate execution denial:
```
Service 'WSL Service' (WSLService) could not be stopped. Verify that you have sufficient privileges to stop system services.
Update failed (exit code: 1603).
Error code: Wsl/UpdatePackage/ERROR_INSTALL_FAILURE
```
Subsequent calls to wsl --shutdown hang indefinitely, indicating that an internal deadlock is maintaining persistent handles on the virtualization layers and preventing WSLService from unmounting.
### Diagnostic Logs
According to the verbose installer trace from wsl-install-logs.txt:
```
=== Verbose logging started: 4/7/2026 14:49:55
Product: C:\Users\gabtz\AppData\Local\Temp\wsl.2.9.3.0.x64.msi
Installation success or error status: 1603.
MainEngineThread is returning 1603
```
The installer engine trips during the transaction context sequence when background host workers or Docker desktop handles fail to safely detach from the operational stack, throwing a hard 1603 block.
Contributor guide
Research direction
Reproduce the reported environment with Windows 10.0.22631.6199, WSL 2.7.10.0, Ubuntu 20.04, and Docker Desktop's WSL2 backend. Run `wsl --update --pre-release` and `wsl --shutdown`, then inspect `wsl-install-logs.txt`; done means the preview update completes and shutdown returns within a few seconds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100