Docker Desktop won't start on Windows 11? Diagnose it safely

Start by naming the layer that failed

The same startup screen can appear while different parts of the stack are in different states. Put the machine in the narrowest group you can support:

• Interface-only: Docker Desktop stays on its startup screen, but the Docker command line reaches the server and containers still respond.
• Engine unavailable: the interface opens, but the command line cannot reach the Docker server.
• WSL unavailable or incomplete: Windows cannot report a healthy WSL version or the expected distributions are stopped, missing, or on an unexpected generation.
• Backend or install-mode mismatch: the configured WSL 2 or Hyper-V path does not match the installation mode, Windows edition, container type, or expected configuration.
• Update-specific: the problem began during an identifiable Docker Desktop update and includes a precise installer error.
• Host-wide: Windows itself is freezing, storage is failing, virtualization is disabled, or several unrelated apps and services fail.

A visible spinner does not prove WSL corruption. An unavailable command line does not prove your images or volumes are gone. Record the state before you change it.

Save the facts you can still reach

Record the exact startup message and when it began. Include the Docker Desktop version, Windows edition and build, recent Docker, WSL, Windows, security, VPN, or policy changes, and whether the installation uses its default location or a custom directory on another drive.

In PowerShell, these read-only commands can show whether the client, server, and WSL layers answer:

docker version
docker info
wsl --version
wsl --status
wsl -l -v

Run them from the same Windows account that normally uses Docker Desktop. Copy the exact result, including an error, but remove private usernames, registry hosts, project names, and paths before sharing it. Do not repeatedly restart services between commands; you want one coherent snapshot.

If the engine answers, inventory important state before broader action. Save your Compose files, Dockerfiles, source repositories, environment-file locations, contexts, and any local-only database or volume that matters. Commands such as docker context show, docker compose ls, docker volume ls, and docker image ls can help when the server is available. A list is not a backup, so confirm any export or copy can actually be restored.

If the interface is stuck but the engine answers

Look at docker version. If it returns both client and server sections, the engine is reachable through the current context even if the Desktop window still spins. Test a container you already understand rather than downloading an unknown image just to prove activity.

Save the interface screenshot, current context, server response, and any failed Dashboard action. Then use Docker Desktop’s ordinary quit and start path once. If the command line stays healthy while only the interface fails, keep the support report on the Desktop interface instead of resetting the engine or WSL.

If one application window is frozen while the rest of Windows works, the app not responding guide can help separate a window or process hang from a system-wide problem. Do not let a stuck Dashboard turn into an automatic data purge.

If the engine is unavailable, check WSL state next

Docker’s current WSL 2 guidance requires WSL 2.1.5 at minimum and recommends the latest WSL version. The wsl --version result should therefore be recorded, not guessed. The wsl -l -v result shows each distribution’s state and generation.

Save work inside every running WSL distribution before restarting the subsystem. Microsoft documents these maintenance commands:

wsl --update
wsl --shutdown

wsl --update brings WSL through Microsoft’s supported update path. wsl --shutdown stops all running WSL distributions and the WSL 2 virtual machine, so it can interrupt terminals, editors, services, and unsaved work. Use it once as a controlled restart only after saving work. Then start Docker Desktop and rerun the same state checks.

Success means the original engine and workload checks pass afterward. A one-time start does not prove why the failure happened. If WSL itself reports an error, keep that exact error and move to Microsoft’s WSL troubleshooting path instead of deleting distributions.

Check the installation mode before changing backends

Docker Desktop can use different Windows backends and installation modes. Current Docker documentation treats WSL 2 as the supported backend for per-user installs, while all-users installations can have different WSL 2, Hyper-V, and Windows-container choices. Windows edition and hardware virtualization also matter.

Record the current installation mode, selected backend, Linux or Windows container mode, Windows edition, WSL state, and Docker data location. Do not switch WSL 2 to Hyper-V—or back—just because a forum reply says it worked. A backend change can alter where data lives, which features are available, and which workloads can run.

Docker also warns that a separate Docker Engine or CLI installed directly inside a WSL distribution can conflict with Docker Desktop. Inventory what is installed before removing anything. Similar names do not prove a conflict.

Match the release-note fix to the failure

Check the installed version before updating. Docker Desktop 4.92.0 has a known WSL integration failure when a distribution sets [automount] root=/ in wsl.conf, or after a container bind-mounts a non-drive path under /mnt, such as /mnt/wslg. The matching error says Docker timed out while waiting for the path to be automounted.

Docker's documented options for that exact 4.92.0 failure are to return to 4.91.0 or remove the matching root setting, then run wsl --shutdown. Save work in every WSL distribution first because that command stops them all. Do not change wsl.conf, remove a bind mount, or change versions when the error and path do not match. On a managed PC, use the administrator's Docker and WSL process.

Docker Desktop 4.91.0 was released on September 14, 2026. Its Windows notes cover a specific case where Desktop stays on "Starting..." because WSL cannot access the disk image location. Version 4.91.0 reports the access failure with guidance instead of a generic WSL error. The same release also fixes startup failures caused by a corrupt Docker network database after an abrupt shutdown and an interface restart loop tied to some graphics-driver problems.

If the message, shutdown history, or display problem matches one of those cases, preserve the diagnostics and follow Docker's supported update path to 4.91.0 or a current later release. Retry the same startup once. Do not delete the disk image, network database, or Docker data folders by hand. These fixes do not make 4.91.0 a universal repair for every startup failure.

Docker Desktop 4.90.0 was released on September 7, 2026. It fixes a Windows startup hang after a WinGet upgrade when engine settings conflict in install-settings.json. It also carries the stuck-socket startup correction for an ungraceful shutdown. Record whether WinGet or a forced shutdown came immediately before the failure. Do not edit the settings file or socket by hand.

Docker Desktop 4.87.0 was released on August 17, 2026. Docker says it fixes an in-app update failure that reported “Source and destination path must have identical roots” when Desktop was installed in a custom directory on another drive. It also fixes repeated “file exists” update failures after an earlier update failed.

If your history and exact error match one of those cases, preserve the installer message, current version, installation directory, and earlier update attempt. Then use Docker’s current supported installer and release guidance. Do not move or delete the existing data directory by hand.

If none of those conditions match, return to the interface, engine, WSL, and host checks above. A newer release and a fix for your specific failure are different facts.

Collect Docker diagnostics before a reset or reinstall

Docker documents diagnostics from the terminal for cases where the Dashboard cannot start. In current Docker Desktop builds, the supported command is:

docker desktop diagnose

Let collection finish. Save the diagnostic ID and archive path. If the command is unavailable, use the current Docker troubleshooting page for the installation-specific diagnostic tool path rather than downloading a replacement from another site.

Review the archive before sharing it. Diagnostics can include usernames, file paths, environment details, container names, registry hosts, networks, and project metadata. Docker directs signed-in subscribers to support and other users to the public issue tracker; redact private details before using a public report.

If the whole Windows host is unstable

When Windows freezes, storage errors appear, virtualization disappears from firmware or Windows features, or unrelated applications fail, Docker may be one visible casualty. Keep the scope on the host.

Use the Windows 11 freezing guide for system-wide hangs. If the failure began after a Windows update, use the Windows Update guide to separate download, install, restart, and rollback states. If a driver change clearly preceded the failure, keep that evidence in the driver update recovery path.

Do not disable antivirus, endpoint protection, firewall, VPN controls, Credential Guard, virtualization-based security, or device management as a generic Docker test. On a managed computer, use the approved administrator path.

Avoid the fixes that erase the evidence

• do not use Clean / Purge data or factory reset as the first diagnostic step
• do not unregister docker-desktop or any WSL distribution from a forum command
• do not delete Docker’s AppData, ProgramData, WSL, VHDX, volume, or settings paths
• do not switch WSL 2 and Hyper-V without recording compatibility and data location
• do not disable security or organization policy to make the startup screen disappear
• do not remove Windows updates, edit services or the registry, or reinstall Windows for a generic Docker symptom
• do not call the issue fixed until the interface, engine, expected containers, and important data all pass a live check

A reset or reinstall may eventually be appropriate, but it is a recovery decision. It needs a verified backup, a clear target, a rollback plan, and a check that the original workload works afterward.

Build a useful escalation record

• Windows edition, version, build, and management state
• Docker Desktop version, installation mode, backend, container mode, and install location
• exact startup or installer message
• docker version, docker info, wsl --version, wsl --status, and wsl -l -v results
• whether the interface, client, server, WSL distributions, and existing workloads respond
• recent Docker, WSL, Windows, VPN, security, virtualization, or policy changes
• diagnostic ID and a redacted archive
• important projects, volumes, images, contexts, and local-only data that must survive
• each reversible test and its verified result

This record lets support work on the failed layer instead of asking you to erase everything and start over.

Where OmniMend fits

OmniMend on a supported Windows PC can help keep the Windows build, recent changes, process state, storage evidence, exact errors, and troubleshooting results together. It does not run Docker’s repair tools for you, bypass organization policy, inspect every container configuration, restore deleted volumes, or guarantee a cause.

Review what OmniMend can and cannot inspect, use the help center, or browse the evidence-first guide library. Protect important data before persistent changes and review every diagnostic file before sharing it.