Docker Desktop 4.95.0 / WSL2: intermittent startup failure (0xc00000fd) and unexplained backend errors #767

Bug report

Bug description

Docker Desktop intermittently fails to initialize its WSL2 backend on Windows 10 Pro.

The original failure occurred on October 19, 2026, with the following error:

DockerDesktop/Wsl/ExecError

wsl.exe -d docker-desktop -u root -e wsl-bootstrap run ...

Exit status: 0xc00000fd

Windows Event Viewer recorded two wslservice.exe crashes with exception 0xc00000fd.

Approximately one minute before these crashes, Windows recorded committed memory usage of 99.95% (48,965,365,760 / 48,989,851,648 bytes).

Memory pressure may have contributed to the incident, but the exact cause has not been established.

Steps to reproduce

The issue is intermittent and cannot currently be reproduced reliably without risking the existing Docker environment.

1. Run Docker Desktop 4.95.0 with the WSL2 backend on Windows 10 Pro.
2. Start Docker Desktop normally with an existing Docker WSL data disk.
3. During the affected startup, WSL bootstrap fails and Docker Desktop displays a WSL execution error.

The failure involved wsl-bootstrap and a warning about /opt/docker-desktop/componentsVersion.json.

However, this warning was also present during an earlier working configuration, so it should not be assumed to be the root cause.

Expected behavior

Docker Desktop should initialize its WSL2 backend, start Docker Engine and make existing containers and volumes accessible without data loss or unexpected initialization.

Actual behavior and subsequent observations

After reducing Windows memory pressure, one controlled startup successfully brought Docker Engine 29.8.2 online in approximately 27.5 seconds.

The four existing container IDs were visible.

However, complete container and volume verification was not obtained because our external monitoring and inventory tools interrupted subsequent checks. Those interruptions do not establish additional Docker Engine failures.

During a later controlled attempt on October 21, filtered Docker backend logs showed:

• 14 diagnostics involving missing or null sessionId context.
• Exit code 1 from vpnkit-bridge.
• Exit code 1 from wsl-bootstrap.

A backend stop request preceded the two exit-code-1 events, so they may be shutdown-related. Their exact meaning has not been established.

No recurrence of the original 0xc00000fd exception was confirmed during that observation.

System information

• Operating system: Windows 10 Pro 22H2
• Windows build: 19045.6466
• Docker Desktop: 4.95.0 (242831)
• Docker Engine: 29.8.2 (observed during a successful startup)
• WSL version: 3.0.3.0
• WSL kernel: 6.18.54.1-1
• Backend: WSL2
• Windows Virtual Machine Platform: Enabled

The original incident occurred before Docker Desktop was updated to 4.95.0. Therefore, the update is not being identified as the cause of the initial crash.

Questions for the Docker team

1. Are missing or null sessionId backend diagnostics known or expected in Docker Desktop 4.95.0?
2. Can vpnkit-bridge and wsl-bootstrap exit with code 1 during a normal shutdown?
3. Could severe Windows commit-memory pressure contribute to the observed WSL bootstrap failure and 0xc00000fd crashes?
4. Which non-destructive diagnostics would you recommend to distinguish startup failures from shutdown-related backend messages?
5. Is there a safe way to verify existing containers and volumes without triggering a storage migration, initialization or reset?

Existing Docker virtual disks have been backed up in encrypted form, but application-level restoration has not yet been tested.

We would like to preserve the existing environment and avoid factory reset, purge, WSL distribution unregister or destructive reinstallation.

A sanitized timeline and filtered diagnostics can be provided if needed.

Platform

Windows

Version information

OS: Windows 10 Pro 22H2 (build 19045.6466)
Architecture: x86_64 / amd64
Docker Desktop: 4.95.0 (242831)
Docker Engine: 29.8.2 (observed during successful startup)
WSL: 3.0.3.0
WSL kernel: 6.18.54.1-1
Backend: WSL2
Virtual Machine Platform: Enabled

Diagnostics ID

No response