Docker Desktop slow shutdown and startup (Win11, WSL2)

[knight-check]

Docker Desktop slow shutdown and startup on Windows 11 with WSL2

Summary

docker desktop stop takes 7 minutes to complete, even though all Docker processes and WSL distros stop within ~3-4 minutes. The remaining time is spent in a polling loop checking for already-exited processes. Additionally, graceful shutdown methods cause significantly slower subsequent startups compared to force-killing.

Environment

• OS: Windows 11 Pro (Build 26200)
• CPU: AMD Ryzen 9 7900X 12-Core (24 threads, 4.7GHz max)
• RAM: 128 GB
• Docker Desktop: 4.55.0 (213807)
• Docker Engine: 29.1.3
• Docker version output:

  Client:
   Version:           29.1.3
   API version:       1.52
   Go version:        go1.25.5
   Git commit:        f52814d
   Built:             Fri Dec 12 14:51:52 2025
   OS/Arch:           windows/amd64
   Context:           desktop-linux
  
  Server: Docker Desktop 4.55.0 (213807)
   Engine:
    Version:          29.1.3
    API version:      1.52 (minimum version 1.44)
    Go version:       go1.25.5
    Git commit:       fbf3ed2
    Built:            Fri Dec 12 14:49:51 2025
    OS/Arch:          linux/amd64
    Experimental:     false
   containerd:
    Version:          v2.2.0
    GitCommit:        1c4457e00facac03ce1d75f7b6777a7a851e5c41
   runc:
    Version:          1.3.4
    GitCommit:        v1.3.4-0-gd6d73eb8
   docker-init:
    Version:          0.19.0
    GitCommit:        de40ad0
  

• WSL distros: Ubuntu, docker-desktop (both WSL2)
• WSL version:

  WSL version: 2.3.26.0
  Kernel version: 5.15.167.4-1
  WSLg version: 1.0.65
  MSRDC version: 1.2.5620
  Direct3D version: 1.611.1-81528511
  DXCore version: 10.0.26100.1-240331-1435.ge-release
  Windows version: 10.0.26200.7462
  

• Kubernetes: Disabled
• Docker vhdx sizes:
  • docker_data.vhdx: 44 GB
  • ext4.vhdx (Docker main): 96 MB
  • ext4.vhdx (Ubuntu): 17 GB
• WSL config (.wslconfig):

  [wsl2]
  memory=16GB
  processors=12
  networkingMode=mirrored
  dnsTunneling=true
  
  [experimental]
  autoMemoryReclaim=gradual
  sparseVhd=true

Timing Data

Shutdown method	WSL stopped	Total shutdown	Next startup
Force kill (taskkill /F)	Instant	Instant	34s
System tray quit	61s	~61s	179s
docker desktop stop	222s	421s (7min)	142s

Issue 1: Excessive shutdown polling

Logs show the backend completes shutdown, but docker-desktop.exe continues polling with ~2 minute intervals:

[17:10:30] POST /app/quit: OK                              # Backend done
[17:12:26] no docker processes running                     # First check (116s later!)
[17:12:26] EnsureDockerFinished: looking for wsl.exe...
[17:14:15] no docker processes running                     # Second check (109s later!)

The processes are already gone at 17:10:30, but Docker Desktop waits until 17:14+ to confirm, burning ~4 minutes.

Issue 2: Graceful shutdown causes slow startup

Force-killing Docker Desktop results in 34-second startups. Both graceful methods (system tray, CLI) result in 140-180 second startups with network timeouts:

[17:30:31] unmarshalling modules manifest: Get "https://desktop.docker.com/modules/4.55/modules.json": context deadline exceeded
[17:31:26] Get "http://ipc/forwards/list": context deadline exceeded

The URL is accessible via curl — only Docker Desktop's backend times out.

Steps to Reproduce

Two bash scripts are attached to help reproduce and measure this issue. Run them in Git Bash.

Measuring startup time

Use time_docker_desktop_start.sh:

./time_docker_desktop_start.sh

This script force-kills any running Docker processes, then starts Docker Desktop and measures time until the engine is ready (verified via docker stats --no-stream).

Measuring shutdown time

1. Start watch_wsl_shutdown.sh in one terminal:

   ./watch_wsl_shutdown.sh

2. In another terminal, run:

   time docker desktop stop

The watch script reports when each WSL distro stops. Compare that timestamp to when docker desktop stop finally returns.

Reproduction steps

Test 1: Graceful shutdown + startup

1. Start Docker Desktop, wait for engine ready
2. Run time docker desktop stop (while watching with watch_wsl_shutdown.sh)
3. Observe 5-7 minute shutdown time, note WSL stops much earlier
4. Run ./time_docker_desktop_start.sh
5. Observe 140+ second startup

Test 2: Force kill + startup

1. Start Docker Desktop, wait for engine ready
2. Run taskkill /F /IM "Docker Desktop.exe" /T && wsl --shutdown
3. Run ./time_docker_desktop_start.sh
4. Observe ~34 second startup

Expected Behavior

• Shutdown should complete within seconds of WSL distros stopping
• Startup time should not depend on shutdown method

Workaround

Force-kill instead of graceful shutdown:

taskkill /F /IM "Docker Desktop.exe" /T
wsl --shutdown

However, this risks data loss if containers are actively writing.

Attached Files

• time_docker_desktop_start.sh — Measures startup time from cold boot to engine ready
• watch_wsl_shutdown.sh — Monitors WSL distro states during shutdown

[mrLexx]

I ran into the same issue after updating to version 4.56. Even installing previous versions didn't help.

You need to remove the docker_data.vhdx file. Please make a backup first.

Warning: This will delete all your images, containers, and volumes.

Windows: %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx
Mac: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
Linux: ~/.docker/desktop/vms/0/data/Docker.raw

[shivangrathore]

Found a solution to this problem in this forum https://bbs.archlinux.org/viewtopic.php?pid=2288995#p2288995

SOLVED!

Turns out

systemd-network-wait-online
was taking two minutes to timeout and failing every time. I noticed that docker.service had this as a dep by using the command:

systemctl list-dependencies docker.service
I have two network cards, ethernet and wireless. The default for systemd network wait is to make sure all interfaces are up. I only use ethernet this is a desktop that doesn't need a wireless connection. I would love to disable the wireless card (and bluetooth for that matter) but it turns out to be a well known firmware flaw on this MSI board that there is no option to do that.

so! I was able to update systemd to consider any interface to be up not ALL of them. weird default but whatever.

This ended up being really helpful in case anyone stumbled upon this in the future: https://unix.stackexchange.com/question … ne-failure

Thanks all!