Problema

En entornos con Windows Server 2019, es posible encontrarse con un patrón de fallos que impide que los controladores de dominio (DC) arranquen después de aplicar una actualización acumulativa. El síntoma típico es un BSOD que muestra el código de error CRITICAL_SERVICE_FAILED (0x5A) acompañado del estado 0xC0000428 (STATUS_INVALID_IMAGE_HASH). El equipo entra en un bucle de reinicio y nunca completa el proceso de arranque.

Aunque el problema se reporta con mayor frecuencia en DCs, también puede aparecer en cualquier servidor que cargue controladores críticos al inicio, como servicios de red o de almacenamiento. La característica común es que la falla ocurre durante la fase de carga de drivers y está vinculada a la verificación de firmas digitales introducida por la actualización.

Causa

1. Validación de firmas de drivers tras actualizaciones acumulativas

Los paquetes de actualización de Windows Server 2019 incluyen cambios en el subsistema de firma de drivers. Si una actualización introduce un nuevo archivo de driver o modifica uno existente, el proceso de arranque vuelve a validar su firma. Cuando la firma no coincide (por ejemplo, por una corrupción del archivo, una versión no firmada o una incompatibilidad con Secure Boot), el kernel genera el error 0xC0000428 y aborta el arranque con CRITICAL_SERVICE_FAILED.

2. Drivers específicos de AD DS y componentes de red

Los controladores de dominio cargan varios drivers de bajo nivel (NTDS, DNS, DHCP, Netlogon). En algunos builds, una actualización de .NET Framework o de componentes de red desplaza versiones de estos drivers, provocando que la firma esperada ya no coincida con la que está en disco. El problema se vuelve visible solo en los DCs porque los servidores miembro no cargan esos componentes críticos durante el arranque.

3. Interferencia de software de seguridad o de virtualización

Herramientas como Sophos, agentes de endpoint o extensiones de Hyper‑V pueden inyectar filtros de driver. Cuando la actualización reemplaza una DLL o un driver subyacente, el filtro pierde su firma válida y el kernel lo rechaza. Aunque el software de seguridad sea idéntico en todos los nodos, la combinación de Secure Boot + firma de driver puede generar el fallo exclusivamente en los DCs, que usan rutas de carga diferentes.

4. Estado inconsistente del almacén de componentes (Component Store)

Si la instalación previa de una actualización quedó a medio aplicar (por ejemplo, por un reinicio inesperado), el Component Store (WinSxS) puede quedar corrupto. Al intentar cargar los nuevos archivos durante el arranque, la verificación de hash falla y el sistema se detiene.

Solución

El objetivo es restaurar un entorno de arranque coherente sin perder los parches críticos. La estrategia se divide en tres fases: diagnóstico, reversión controlada y prevención.

1. Diagnóstico rápido con WinDbg o el visor de eventos

  • Extrae MEMORY.DMP y busca el driver que genera el código 0xC0000428. La línea nt!IopLoadDriver suele indicar el nombre del archivo (<driver>.sys).
  • Revisa Event Viewer > System para el evento 1001 con el bugcheck 0x5A. El campo Bugcheck Parameter2 contiene el hash fallido y, a veces, el nombre del driver.
  • Si el driver pertenece a un paquete de actualización (por ejemplo, KB5120238), anótalo para la reversión.

2. Reversión segura mediante DISM

El comando DISM /image:C:\ /cleanup-image /revertpendingactions elimina los paquetes pendientes y vuelve al estado anterior al parche. Este paso es la forma más fiable de volver a arrancar sin perder la configuración del DC.

dism /image:C:\ /cleanup-image /revertpendingactions

Después de ejecutar el comando, reinicia el servidor. Windows debería iniciar normalmente y el controlador de dominio volverá a estar operativo.

3. Aplicar la actualización de forma selectiva

Una vez que el servidor arranca, procede a:

  1. Desinstalar el paquete problemático usando wusa /uninstall /kb:5120238 (reemplaza el número de KB).
  2. Reinstalar solo los componentes críticos (por ejemplo, .NET Framework) mediante el instalador independiente, verificando que la firma sea válida.
  3. Desactivar temporalmente Secure Boot en la VM o en el hardware, aplicar la actualización y volver a habilitarla. En muchos casos, la desactivación permite que el driver se registre sin la restricción de firma, y luego se vuelve a firmar correctamente al reiniciar con Secure Boot activo.

4. Reparar el Component Store (si está corrupto)

Ejecuta:

dism /online /cleanup-image /restorehealth

Este proceso descarga los archivos correctos desde Windows Update y repara el almacén. Después, vuelve a intentar la instalación del paquete.

5. Validar la integridad de los drivers antes de la próxima actualización

  • Usa sigcheck (Sysinternals) para listar los hashes de los drivers críticos (ntds.sys, dnsapi.sys, dhcpsrv.sys).
  • Compara los resultados con los valores publicados en el Catálogo de Microsoft. Si detectas diferencias, reemplaza el driver con la versión firmada oficial antes de aplicar la actualización.

Cuándo aplicar esta solución

  • Síntomas: BSOD con CRITICAL_SERVICE_FAILED (0x5A) y STATUS_INVALID_IMAGE_HASH (0xC0000428) justo después de una actualización acumulativa; el servidor no supera la fase de carga de drivers.
  • Entorno: Windows Server 2019 (build 17763) en máquinas físicas o virtuales, con roles de AD DS, DNS, DHCP u otros servicios críticos cargados en arranque.
  • No aplica: Si el error ocurre en un servidor que no carga drivers críticos (por ejemplo, un servidor de archivos sin AD DS) o si el bugcheck es diferente (por ejemplo, 0x7B). En esos casos, la causa suele ser otra y la reversión de pending actions no resolverá el problema.

Verificación

  1. Arranque limpio: Después de la reversión, verifica que el servidor arranca sin BSOD y que los servicios de AD DS se inician automáticamente.
  2. Estado de los paquetes: Ejecuta dism /online /get-packages | findstr /i "KB512" para confirmar que el paquete problemático está ausente.
  3. Integridad de firmas: Con sigcheck -q -c C:\Windows\System32\drivers\*.sys revisa que todos los drivers críticos tengan una firma válida.
  4. Prueba de actualización: Aplica la actualización de forma manual (no a través de MECM) en un entorno de pruebas. Si el arranque es exitoso, la solución está validada.

Notas adicionales

  • Mantener una copia de seguridad del Component Store (C:\WinSxS) antes de aplicar grandes acumulados facilita la recuperación.
  • En entornos con Secure Boot, considera crear una política de firma de driver personalizada que incluya los paquetes de Microsoft y los firmantes de terceros (por ejemplo, Sophos).
  • Cuando uses MECM, habilita la opción “Retry on failure” y configura una ventana de mantenimiento que permita una reversión automática si el servidor no completa el arranque en 15 minutos.
  • Documenta siempre el número de KB que causa el fallo; Microsoft suele publicar correcciones en los siguientes acumulados.

Con este enfoque puedes diagnosticar rápidamente la raíz del error CRITICAL_SERVICE_FAILED, revertir la actualización de forma segura y volver a aplicar los parches sin comprometer la disponibilidad de los controladores de dominio.