Docker Desktop silently stops responding at runtime, no crash trace in logs (Windows 11, WSL2 backend, recurring 7 times over ~7 weeks)

[ilCosmico]

Description

Docker Desktop periodically stops responding on my Windows 11 server after
days of stable, unattended operation. All containers become unreachable
(connections actively refused) and the Docker Desktop.exe process is no
longer running. There is no system reboot in between, and in most
occurrences no error or exception is recorded anywhere (not in Docker
Desktop's own logs, not in the Windows Event Log).

Environment

• Docker Desktop 4.85.0 (previously 4.83.0, upgraded hoping it would help,
  see below)
• Windows 11 Pro, build 26200
• WSL2 backend
• Runs unattended most of the time (family home server), so failures are
  usually noticed hours later via an external health check, not caught live

History (7 occurrences since 2026-07-01)

Date	Notes
2026-07-01	Only occurrence with an identifiable cause: initializing Inference manager error on a corrupted dockerInference socket file after an unclean Windows restart. Fixed by disabling the Docker AI / Inference Manager feature entirely.
2026-07-30	Silent stop, no trace in Docker logs or Windows Event Log.
2026-08-03	Same pattern; log ends with exit code 0xffffffff.
2026-08-06/07	Log simply stops being written (last entry hours before, no error), resumes only after a manual restart.
2026-08-18	Same silent-stop pattern, now on 4.85.0 (upgraded after the previous occurrence specifically hoping it was fixed).
2026-08-22	This time the backend log (monitor.log) shows continuous, normal activity with no gap right up to the moment of manual intervention, yet Docker Desktop.exe was already not running and containers were refusing connections.

None of these coincided with a Windows reboot or update (verified via
Win32_OperatingSystem.LastBootUpTime each time) except the first, which
had its own distinct, already-identified cause.

What I've already ruled out / tried

• Upgrading 4.83.0 → 4.85.0: did not stop the pattern from recurring.
• Disabling Docker AI / Inference Manager: fixed the one occurrence that
  was actually caused by it, irrelevant to the other 6.
• Checked Windows Event Log around each failure time: nothing relevant.
• Checked %LOCALAPPDATA%\Docker\log\host\monitor.log and rotated
  versions each time: usually just stops, no exception; the most recent
  occurrence shows no gap at all despite the process being gone.

What fixes it (every time)

Manually starting Docker Desktop again. It then runs fine for days to
weeks before the next occurrence.

Question

Has anyone else seen Docker Desktop silently stop like this on 4.85.x
(or earlier 4.8x builds) on Windows 11 x64, with no exception logged
anywhere? Is there another log source (WER, ETW) worth checking that
might capture what Docker Desktop's own logs don't?

[ilCosmico]

Update: an 8th occurrence just happened (2026-08-28), same version (4.85.0), same pattern as the others: no reboot in between (verified via LastBootUpTime), Docker Desktop.exe process gone, containers unreachable. Fixed again by manually restarting Docker Desktop.

Still no error or exception found anywhere before the process disappeared.

[bsousaa]

Can you test this scenario with the Docker VMM virtualization option?

[ilCosmico]

Tried Docker VMM as suggested, after first updating to 4.89.0 (from 4.85.0).

Hit a couple of issues getting there:

• Initial "path is not shared from the host" errors for bind-mounted volumes until adding the drive under Settings > Resources > File Sharing.
• After that, applying the Docker VMM setting got stuck indefinitely on "Applying settings" / "Turning off the Docker Engine...", completely unresponsive (docker ps timed out, GUI spinner never resolved). Had to force-kill all Docker Desktop and com.docker.* processes and relaunch to recover.

After relaunching, it came back on WSL2 (the settings file already had the VMM flag reverted to false, but the engine itself was stuck regardless). All containers came back up cleanly with no data loss (volumes are host bind mounts, not Docker-managed).

Given Docker VMM was unstable just switching to it on this machine, I haven't been able to actually test whether it avoids the original silent-crash pattern this issue is about. Staying on WSL2 for now. Will report back if I get a stable enough VMM run to compare.

[bsousaa]

thanks @ilCosmico can you please share a diagnostics id to investigate those issues?

[ilCosmico]

Diagnostics ID: A584FB4B-9A5D-4E61-A789-958543715434/20260902231314

[ilCosmico]

Update: a 9th occurrence just happened (2026-09-07), still on WSL2 (stayed there after the Docker VMM attempt got stuck, see earlier comment). No reboot in between (verified via LastBootUpTime). Fixed again by manually restarting Docker Desktop.

This time RemoteControl (an unrelated Python process on the same machine) also stopped responding around the same time with no reboot, though I don't have enough evidence yet to say the two are related rather than coincidental.