Tweet
Este TIP entiendo que solo tendrá validez durante la beta de Windows 10 - 20H1 pero puede servir de ayuda para le futuro ya que en Microsoft muchas veces los problemas son reiterativos, o bien puede servir para ver como investigar errores de este tipo.
El problema surge cuando tenemos activo WSL 2. Recordemos que si usamos WSL 2, los Linux que instalemos en Windows Subsystem Linux se ejecutan en un container en modo totalmente nativo (y rapidísimo).
Se observa que si instalamos docker, a veces, no siempre, al arrancar un Linux en WSL 2 falla con un error 0xffffffff. El mismo fallo da al arrancar Windows Sandbox, o bien si tenemos instalado y arrancamos en el navegador el modo protegido de Application Guard.
El fallo no es siempre, es aleatorio, por lo que parece que hay algún servicio del propio docker que si arranca antes que otros del sistema pudiera ser el causante. Si ponemos el servicio docker como arranque manual, el problema nunca sucede por lo que parece que es el causante,
Para verificarlo, vemos con cports https://www.nirsoft.net/utils/cports.html los puertos que usa docker. Ver imagen:
Podemos observer que docker está usando el puerto 53 (DNS) escuchando en una direccion especifica, pero tambien que un svchost está lanzando algun servicio del sistema que tambien escucha para todas las IP (0.0.0.0) en el mismo puerto. Esto es la causa... si docker arranca antes que ese servicio del sistema imnpedirá que la escucha del servicio del sistema sea correcta.
Es necesario determinar que servicio es. Para ello con procexp de Sysinternals https://docs.microsoft.com/en-us/sysinternals/, analizamos uno a uno los svchost, propiedades, pestaña TCP hasta que localizamos quien está usando el puerto 53 (domain).
Localizamos que es el servicio SharedAccess, es decir el servicio ICS (Internet Connection Shared). De él además, si tenemos instalado Application Guard (servicio hvsics) será su dependiente.
Ya solo por tanto nos queda poner una dependencia para que docker arranque en automatico pero dependiento de los anteriores.
Si no tenemos instalado Application Guard, lo hacemos depende del ISC. Para ello en una consola en modo administrativo:
Y si lo tuviésemos instalado lo hacemos depender de él:
Solucionado,.
Al menos este TIP sirve para ver como podemos investigar con una pocas herramientas lo que está pasando
El problema surge cuando tenemos activo WSL 2. Recordemos que si usamos WSL 2, los Linux que instalemos en Windows Subsystem Linux se ejecutan en un container en modo totalmente nativo (y rapidísimo).
Se observa que si instalamos docker, a veces, no siempre, al arrancar un Linux en WSL 2 falla con un error 0xffffffff. El mismo fallo da al arrancar Windows Sandbox, o bien si tenemos instalado y arrancamos en el navegador el modo protegido de Application Guard.
El fallo no es siempre, es aleatorio, por lo que parece que hay algún servicio del propio docker que si arranca antes que otros del sistema pudiera ser el causante. Si ponemos el servicio docker como arranque manual, el problema nunca sucede por lo que parece que es el causante,
Para verificarlo, vemos con cports https://www.nirsoft.net/utils/cports.html los puertos que usa docker. Ver imagen:
Podemos observer que docker está usando el puerto 53 (DNS) escuchando en una direccion especifica, pero tambien que un svchost está lanzando algun servicio del sistema que tambien escucha para todas las IP (0.0.0.0) en el mismo puerto. Esto es la causa... si docker arranca antes que ese servicio del sistema imnpedirá que la escucha del servicio del sistema sea correcta.
Es necesario determinar que servicio es. Para ello con procexp de Sysinternals https://docs.microsoft.com/en-us/sysinternals/, analizamos uno a uno los svchost, propiedades, pestaña TCP hasta que localizamos quien está usando el puerto 53 (domain).
Localizamos que es el servicio SharedAccess, es decir el servicio ICS (Internet Connection Shared). De él además, si tenemos instalado Application Guard (servicio hvsics) será su dependiente.
Ya solo por tanto nos queda poner una dependencia para que docker arranque en automatico pero dependiento de los anteriores.
Si no tenemos instalado Application Guard, lo hacemos depende del ISC. Para ello en una consola en modo administrativo:
Código:
sc config com.docker.service depend=SharedAccess
Código:
sc config com.docker.service depend=hvsics
Al menos este TIP sirve para ver como podemos investigar con una pocas herramientas lo que está pasando
Comentario