Repository navigation
WSL 3.0.1 breaks Docker Desktop: iso9660 unavailable in docker-desktop distro (KernelModulesUnavailable) #41759
Description
Windows Version
10.0.19045.7725
WSL Version
3.0.1.0
Are you using WSL 1 or WSL 2?
- WSL 2
- WSL 1
Kernel Version
6.18.40.1 (bundled kernel from WSL 3.0.1.0, no custom kernel, no .wslconfig present)
Distro Version
docker-desktop (Docker Desktop system distro). Also installed: Ubuntu 20.04
Other Software
Docker Desktop v4.93.0 (WSL 2 backend)
Also a previous docker version. I first updated Docker, but that wasnt the problem.
Repro Steps
- Docker Desktop with WSL 2 backend working normally on WSL 2.7.x
- Microsoft Store automatically updates WSL to 3.0.1.0
- Start Docker Desktop
Expected Behavior
Docker Engine starts normally, as it did before the WSL update.
Actual Behavior
Docker Desktop fails to start the engine.
With an older Docker Desktop version (29.0.1 client, Nov 2025), the engine hangs indefinitely at "Engine starting" without any error in the UI. The backend log repeatedly shows:
still waiting for init control API to respond after 8m10s
/run/guest-services/socketforwarder-receive-fds.sock: does not exist yet, waiting for it to be created
After updating to the latest Docker Desktop, it reports an explicit error:
wsl-bootstrap: preparing environment: mounting cli-tools iso:
running mount -o ro,exec /mnt/docker-desktop-disk/isocache/entries/docker-wsl-cli.iso/9e001be3...
/mnt/host/wsl/docker-desktop/cli-tools: mount: unknown filesystem type 'iso9660'.
wslErrorCode: DockerDesktop/Wsl/KernelModulesUnavailable
Observations:
- No
.wslconfigexists, so the bundled kernel is used. - In the Ubuntu-20.04 distro,
/lib/modules/6.18.40.1-microsoft-standard-WSL2/is present and populated, so kernel modules seem available to regular distros but not to the docker-desktop distro. wsl --updatereported 3.0.1.0 as the latest version.
Workaround: Uninstalling WSL 3.0.1.0 and installing the 2.7.14 MSI from the releases page (kernel 6.18.33.2-2). <RESULT, e.g. "Docker Desktop starts normally again.">
Secondary issue during the downgrade: wsl --uninstall and the 2.7.14 installer both failed (exit code 1620 / Wsl/0x80070654) because the cached package C:\Windows\Installer\3460fd4b.msi was invalid ("Error 2219: Invalid Installer database format"). Re-caching with msiexec /i wsl.3.0.1.0.x64.msi REINSTALL=ALL REINSTALLMODE=vomus was required before the uninstall succeeded. This suggests the automatic Store update to 3.0.1 may have left a corrupted MSI cache.
Diagnostic Logs
Logs not collected via collect-wsl-logs.ps1, since the system was rolled back to 2.7.14 to restore a working setup.
Activity
github-actions commentedon Oct 1, 2026
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:
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 networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce 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 [email protected] 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'.
Windows: replace Docker Desktop with wslc; hold WSL at 3.0.1+
microsoft-github-policy-service commentedon Oct 8, 2026
This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.
Thank you!