Docker Desktop trabado con WSL2 en Windows 11: la solución

En pocas palabras: Cuando Docker Desktop con WSL2 queda trabado en “Loading” o “Installing” en Windows 11, un desarrollador documentó un script de PowerShell de 8 pasos que mata procesos colgados (wsl.exe, wslhost.exe, com.docker.backend.exe) y reinicia los servicios vmcompute, hns y WSLService sin borrar distribuciones ni contenedores.

Docker Desktop con WSL2 en Windows 11 se traba en estado “Loading” o “Installing” por procesos huérfanos de WSL, el servicio HNS colgado en START_PENDING o el daemon de Docker sin responder al backend Linux. Un desarrollador documentó en un script de PowerShell que reinicia servicios sin borrar distribuciones ni contenedores.

Docker Desktop con WSL2 es la combinación que usa Windows 11 para correr contenedores Linux: Docker Desktop es la interfaz y el daemon, WSL2 es la capa de virtualización que ejecuta el kernel Linux por debajo. Cuando algún componente de esa cadena (WSL, HNS, vmcompute o el propio Docker Desktop.exe) queda en un estado inconsistente, ves la app trabada sin poder levantar contenedores. Lo interesante del caso que analizamos acá no es solo el script en sí, sino el criterio para decidir cuándo usar cada nivel de reset, porque no todos los cuelgues se resuelven de la misma forma.

¿Qué síntomas muestra Docker Desktop cuando WSL2 falla en Windows 11?

Los síntomas más comunes son tres: la interfaz de Docker Desktop queda trabada en “Loading” indefinidamente, el comando wsl -l -v muestra docker-desktop con estado “Installing” en lugar de “Running”, y el cliente Docker devuelve un error de conexión apuntando a dockerDesktopLinuxEngine.

El autor del script publicado mantiene dos entornos de desarrollo, uno Linux y uno Windows 11, y nota que en Linux este tipo de problema es mucho menos frecuente. En Windows, en cambio, la combinación Docker Desktop más WSL2 depende de una cadena de servicios de Windows (HNS, vmcompute, el servicio de WSL) que puede quedar en estados intermedios.

En uno de los casos documentados, intentar acceder directamente a la distribución con wsl -d docker-desktop devolvió el error Wsl/Service/WSL_E_DISTRO_NOT_FOUND. También reportó al servicio HNS colgado en START_PENDING o STOP_PENDING. En esos casos, ni wsl --shutdown ni reiniciar Docker Desktop desde la bandeja alcanzaban para destrabar el entorno.

Qué hace el script de reset de PowerShell para Docker Desktop y WSL2

El script corre en ocho pasos: mata procesos colgados, reinicia servicios de Windows en orden y valida el estado final con los comandos nativos de Docker. Se ejecuta como PowerShell con privilegios de administrador (#requires -RunAsAdministrator) y no borra distribuciones ni volúmenes. Lo explicamos a fondo en el proceso de instalación paso a paso.

Primero termina con taskkill.exe /F los procesos wsl.exe, wslhost.exe, wslservice.exe, VmmemWSL.exe, Docker Desktop.exe y com.docker.backend.exe, además de matar el svchost.exe asociado al servicio HNS cuando queda atascado. Ponele que tenés el ícono de Docker girando en la bandeja hace diez minutos: ese primer bloque libera los handles que están bloqueando todo.

Después, detiene y vuelve a levantar varios servicios en secuencia: WSLService o LxssManager (según la versión de WSL instalada), vmcompute (el motor de máquinas virtuales que usa WSL2 por debajo) y hns (Host Network Service, encargado de la red virtual que comparten WSL y Docker). Entre medio, el script corre sc.exe queryex hns y sc.exe queryex vmcompute para mostrar el estado detallado de cada servicio antes de reiniciarlo, algo útil para diagnosticar sin adivinar.

El último tramo abre Docker Desktop.exe desde $env:ProgramFiles\Docker\Docker\, espera 15 segundos y valida con docker version, docker info y docker context ls. Si esos tres comandos responden sin error, el backend Linux está operativo.

Ejemplo hipotético: seguir el diagnóstico paso a paso

Nota: lo que sigue es un ejemplo hipotético, armado para ilustrar cómo se aplicaría el razonamiento del script en un escenario distinto al que documentó el autor original, no un caso real reportado por nadie.

Imaginate que estás en medio de un deploy local y de repente Docker Desktop deja de responder a mitad de un docker compose up. Antes de tirarte de cabeza al script completo de ocho pasos, tiene sentido ir de menor a mayor:

• Paso 1 — Diagnóstico mínimo. Corrés wsl -l -v y docker info por separado. Si WSL muestra todo en Running y Docker responde, el problema no es de infraestructura: puede ser tu docker-compose.yml o un puerto ocupado, y ahí el script no te sirve de nada.
• Paso 2 — Reinicio suave. Si docker info tira timeout pero WSL se ve sano, probás primero con wsl --shutdown y reabrís Docker Desktop desde el ícono. Es el equivalente a “apagar y prender” antes de sacar la artillería.
• Paso 3 — Reset completo. Si el paso anterior no destrabó nada y además ves docker-desktop en estado “Installing” en wsl -l -v, recién ahí tiene sentido correr el script completo: mata procesos, reinicia servicios de Windows y valida con docker info al final.
• Paso 4 — Último recurso. Solo si después del reset completo seguís viendo WSL_E_DISTRO_NOT_FOUND al intentar wsl -d docker-desktop, evaluás el --unregister puntual sobre esa distribución, nunca sobre las tuyas de trabajo.

La idea de este ejemplo no es que sigas los cuatro pasos literales cada vez, sino que internalices el criterio: cuanto más invasiva es la acción, más específico tiene que ser el síntoma que la justifica. Un script de ocho pasos para un puerto ocupado es matar una mosca a cañonazos.

“WSL sano” no es lo mismo que “daemon de Docker sano”

Un WSL con todos sus servicios en Running puede convivir con un Docker Desktop que sigue sin arrancar: son dos capas independientes que hay que verificar por separado, no una sola cosa. Te puede servir nuestra cobertura de las diferencias entre Microsoft y Github.

El autor documentó exactamente ese caso: tras correr el script, hns, vmcompute y WSLService quedaron en estado Running, señal de que la capa de virtualización estaba recuperada. Sin embargo, wsl -l -v seguía mostrando docker-desktop Stopped y el ejecutable de Docker Desktop no estaba en la ruta que el script esperaba. El resultado: hubo que iniciarlo a mano.

La lección práctica es simple: si después de correr un reset WSL responde bien pero Docker sigue sin levantar contenedores, el problema no está en la capa de virtualización, está en el binario o en la configuración de Docker Desktop en sí. Buscá el ejecutable manualmente y abrilo, eso suele resolver ese último tramo.

¿Cuándo usar wsl –unregister docker-desktop y por qué es riesgoso?

wsl --unregister docker-desktop elimina por completo la distribución WSL asociada a Docker, no la reinicia. El autor lo separa del script principal porque, dependiendo de la configuración, puede borrar datos y afectar el estado interno de Docker de forma permanente.

La condición específica en la que lo usa es puntual: cuando docker-desktop queda trabado en “Installing” de forma persistente y, al intentar wsl -d docker-desktop, el sistema devuelve Wsl/Service/WSL_E_DISTRO_NOT_FOUND. En ese escenario, la distribución quedó en un limbo donde ni existe del todo ni se puede reparar, así que forzarle una reinstalación limpia con --unregister es la única salida razonable. Aun así, el propio autor lo trata como último recurso, no como paso de rutina.

Hay una regla que el autor marca con intención, aunque no la escriba en mayúsculas: jamás correr wsl --unregister sobre Ubuntu ni Ubuntu-22.04. Esas son las distribuciones de desarrollo reales, con proyectos, dependencias y configuración acumulada. El comando de desregistro solo aplica a la distribución interna que usa Docker Desktop para su propio backend, nunca a un entorno de trabajo. Antes de tipear el comando, fijate dos veces qué nombre estás escribiendo: no hay ctrl+z para esto.

Criterios para elegir qué nivel de reset aplicar

Más allá del script puntual, sirve tener en la cabeza una regla de proporcionalidad entre síntoma y acción:

• Docker responde lento pero contesta: no toques nada del sistema. Revisá primero tu propio compose o los recursos asignados en .wslconfig.
• Docker no responde pero WSL se ve sano en wsl -l -v: alcanza con wsl --shutdown más reabrir Docker Desktop desde el ícono.
• Docker no responde y docker-desktop aparece en “Installing” o “Stopped” de forma persistente: ahí se justifica el script completo de los ocho pasos.
• Persiste el error WSL_E_DISTRO_NOT_FOUND después del reset completo: recién en ese punto se evalúa --unregister sobre la distribución interna, nunca antes y nunca sobre las de trabajo.

Este orden de menor a mayor invasividad no está explicitado como tabla en la fuente original, pero se desprende directamente de cómo el propio autor secuencia sus intentos: primero el script, después el --unregister solo como excepción documentada.

Límites del script: qué no soluciona automáticamente

El script no es un procedimiento oficial de Docker ni de Microsoft. Es, en palabras del propio autor, un “personal recovery playbook” basado en los problemas puntuales que fue encontrando en su entorno de Windows 11.

Eso tiene una consecuencia directa: no garantiza que Docker Desktop arranque solo al final de la ejecución. Como vimos en la sección anterior, puede pasar que todos los servicios de Windows queden sanos y aun así haga falta abrir el ejecutable a mano porque no estaba en la ruta esperada por el script.

Tampoco resuelve problemas de licenciamiento, de configuración de recursos (CPU, RAM asignada a WSL2) ni fallas de red más profundas que un HNS colgado. Es una herramienta de primer auxilio para el escenario específico de procesos trabados, no un diagnóstico integral. Si el problema persiste después de correrlo, probablemente esté en otra capa: drivers de virtualización, actualizaciones pendientes de Windows o configuración manual de .wslconfig. En opciones gratuitas si buscás alternativas profundizamos sobre esto.

Errores comunes al reiniciar Docker Desktop con WSL2

• Correr wsl –unregister sobre la distribución de trabajo por apuro. Confundir docker-desktop con Ubuntu o Ubuntu-22.04 borra proyectos y configuración real, no solo el backend de Docker.
• Asumir que reiniciar Docker Desktop desde el ícono alcanza. Si HNS o vmcompute están en estado START_PENDING, un simple restart de la app no toca esos servicios de Windows y el problema vuelve enseguida.
• No correr PowerShell como administrador. El script requiere #requires -RunAsAdministrator para ejecutarse; sin ese privilegio, los pasos que dependen de detener y levantar servicios de Windows pueden no completarse correctamente.
• Dar por sentado que WSL sano implica Docker sano. Como vimos arriba, son capas independientes. Verificá siempre con docker info después de confirmar el estado de WSL.
• Saltar directo al script sin diagnóstico previo. Correr ocho pasos invasivos para un problema que se resolvía con wsl --shutdown es tiempo perdido y, en máquinas compartidas, un riesgo innecesario.

Preguntas Frecuentes

¿Por qué Docker Desktop se queda trabado en “Loading” en Windows 11?

Porque algún componente de la cadena WSL2 (el servicio HNS, vmcompute o el propio proceso wsl.exe) queda en un estado intermedio como START_PENDING, y el daemon de Docker nunca termina de conectar con el backend Linux. El error típico que devuelve el cliente es dockerDesktopLinuxEngine.

¿Cómo reinicio WSL2 sin perder mis distribuciones de Linux?

Matando los procesos colgados (wsl.exe, wslhost.exe, VmmemWSL.exe) y reiniciando los servicios de Windows vmcompute, hns y WSLService, sin usar en ningún momento wsl --unregister sobre las distribuciones de trabajo. Ese es exactamente el enfoque del script documentado por el autor: recuperar servicios, no borrar datos.

¿Qué significa que docker-desktop aparezca como “Installing” en wsl -l -v?

Significa que la distribución interna que usa Docker Desktop para su backend no terminó de inicializarse correctamente. Si además wsl -d docker-desktop devuelve WSL_E_DISTRO_NOT_FOUND, la distribución quedó en un estado que un reinicio normal no puede reparar.

¿Es seguro usar wsl –unregister docker-desktop?

Solo si se aplica exclusivamente a la distribución interna docker-desktop y como último recurso ante el error WSL_E_DISTRO_NOT_FOUND persistente. No es un comando de reinicio: elimina la distribución y puede afectar el estado interno de Docker, por lo que nunca debería correrse sobre distribuciones de desarrollo como Ubuntu.

¿Cómo saber si el problema es de WSL o del daemon de Docker?

Corriendo wsl -l -v y wsl --status por un lado, y docker version más docker info por otro. Si WSL muestra los servicios en Running pero Docker sigue sin responder o el ejecutable no arrancó, el problema está en Docker Desktop, no en la capa de virtualización.

Conclusión

El caso documentado deja algo claro: Docker Desktop con WSL2 en Windows 11 depende de una cadena de servicios de Windows que puede desincronizarse, y el fix no siempre está en la app de Docker. Tener un script guardado que reinicie servicios en el orden correcto (matar procesos, parar servicios, levantarlos, validar con docker info) te ahorra repetir la misma secuencia manual cada vez que aparece el problema. Pero antes de tirarte al script completo, vale la pena aplicar el criterio de proporcionalidad que repasamos arriba: no todo cuelgue de Docker necesita ocho pasos de PowerShell.

Eso sí: antes de correr cualquier comando destructivo como wsl --unregister, confirmá con wsl -d [nombre] qué distribución específica está fallando. Un --unregister sobre la distribución equivocada no tiene vuelta atrás. Si tu entorno de desarrollo corre sobre contenedores en producción, vale la pena tener también un plan de infraestructura fuera del equipo local: para eso, servicios de cloud como donweb.com sacan la dependencia de que tu Windows local esté sano para que el servicio siga arriba.

Fuentes

• Docker Desktop + WSL2 on Windows 11: My Strongest Reset – dev.to, script completo y casos documentados por el autor