BSOD 0xc000021a tras instalar KB5034768 en Windows Server 2019

Un reinicio rutinario de parcheo puede convertirse en una pesadilla cuando la máquina entra en un bucle de pantallas azules que impide el arranque. Eso es exactamente lo que sucede a algunos administradores al aplicar la actualización acumulativa KB5034768 en Windows Server 2019 con SQL Server 2014: tras instalar el parche, el servidor vuelve una y otra vez al código de detención 0xc000021a hasta que irrumpe el Entorno de Recuperación de Windows (WinRE). A continuación encontrarás una guía exhaustiva —basada en casos reales y pruebas de laboratorio— para entender el origen del problema, recuperar la VM sin pérdida de datos y, sobre todo, evitar que el incidente se repita.

Contexto y alcance del incidente

El fallo se presenta en hosts que cumplen las siguientes condiciones habituales:

• Windows Server 2019 Standard o Datacenter en build 17763.5329 (llamado comúnmente «patch Tuesday de febrero»).
• SQL Server 2014 instalado con servicios en modo AlwaysOn o stand‑alone.
• Protección avanzada de endpoints (EDR/antivirus) activa —se han documentado conflictos con controladores de terceros como edrdrv.sys de Xcitium/Comodo.
• El resto de servidores idénticos pero sin SQL, o sin el agente EDR, actualizan correctamente.

Por qué aparece la pantalla azul

El código 0xc000021a STATUSSYSTEMPROCESS_TERMINATED indica que un proceso de usuario crítico (normalmente winlogon.exe o csrss.exe) se ha detenido de forma inesperada. En este escenario, dos causas confluyen:

1. KB5034768 reemplaza componentes de sesión y autenticación; si alguna DLL queda sin actualizar por un controlador bloqueante, se produce incoherencia en la pila Win32.
2. Un driver de terceros compila ganchos en modo usuario; al reiniciarse el kernel con binarios nuevos, el driver no «desengancha» correctamente y provoca la detención forzada del proceso de sesión.

La combinación dispara la pantalla azul antes de que Windows complete la fase WinLogon Init, de modo que el sistema nunca registra el suceso en el Event Viewer y apenas deja migas de pan más allá del archivo MEMORY.DMP.

Soluciones comprobadas en la comunidad

Enfoque	Pasos principales	Comentarios / pruebas
Excluir temporalmente la actualización	Instalar el resto de parches de seguridad desde PowerShell: Install-WindowsUpdate -NotKB KB5034768	Permite mantener al día el sistema sin exponerse al BSOD.
Desinstalar la actualización fuera de línea	Arrancar en Repair your computer → Troubleshoot → Command Prompt. Identificar la partición con la carpeta Windows. Ejecutar DISM /Image:D:\ /Cleanup-Image /RevertPendingActions Si persiste el fallo, listar y quitar paquetes recientes: DISM /Image:D:\ /Get-Packages DISM /Image:D:\ /Remove-Package /PackageName:PackageforKB5034768	Revierte KB5034768 sin restaurar una copia de seguridad completa.
Eliminar el controlador conflictivo (caso con EDR)	Entrar en modo seguro. Habilitar Windows Installer: REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /VE /T REG_SZ /F /D "Service" REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer" /VE /T REG_SZ /F /D "Service" Desinstalar el agente Xcitium/Comodo en «Programas y características». Reiniciar en modo normal.	Resuelve el BSOD cuando el stop code secundario alude a DRIVERUNLOADEDWITHOUTCANCELLINGPENDING_OPERATIONS.
Esperar un hotfix de Microsoft	Monitorizar la página oficial del parche y volver a probar cuando aparezca una revisión firmada.	Recomendado si el software de terceros es crítico y no puede retirarse.

Paso a paso: desinstalación de KB5034768 cuando el sistema no arranca

A continuación se detalla un procedimiento completo que combina la reversión de acciones pendientes y la eliminación selectiva de paquetes:

1. Inicia la VM desde el medio de instalación de Windows Server y selecciona Repair your computer.
2. Abre la consola y ejecuta diskpart; usa list vol para localizar la unidad de sistema.
3. Monta la partición, por ejemplo assign letter=D, y sal de diskpart.
4. Lanza la reversión:
   DISM /Image:D:\ /Cleanup-Image /RevertPendingActions
5. Si no basta, obtén la lista de actualizaciones:
   DISM /Image:D:\ /Get-Packages /Format:Table
6. Identifica el parche problemático y elimínalo:
   DISM /Image:D:\ /Remove-Package /PackageName:PackageforKB5034768~31bf3856ad364e35~amd64~~17763.5329.1.20
7. Escribe exit, reinicia y comprueba que el sistema arranca.

En entornos VMWare o Hyper‑V, este proceso es incluso más rápido si se monta el VHD/VMDK desde otra VM de mantenimiento.

Método para bloquear la actualización automáticamente

Una vez recuperado el servidor, bloquea la distribución automática del parche para evitar reincidencias:

Import-Module PSWindowsUpdate
Get-WindowsUpdate -KBArticleID KB5034768 -Hide -Verbose

En WSUS o Microsoft Endpoint Configuration Manager, basta con mover KB5034768 al contenedor »Declined« y programar un nuevo software update group que excluya ese boletín.

Cómo identificar drivers responsables

El archivo MEMORY.DMP suele pesar varios cientos de megabytes, pero un vistazo rápido con WinDbg da pistas:

!analyze -v
lmvm edrdrv

Si el stack trace muestra un módulo de seguridad de terceros, actualiza o desinstálalo. Las versiones problemáticas reportadas incluyen:

• Xcitium/Comodo EDR 3.3.0.866 (firmware de enero)
• Versiones antiguas de driver de backup VSS
• Antivirus con motor legacy sin certificación SHA‑2

Buenas prácticas para evitar imprevistos

Los siguientes consejos reducen el riesgo de pantallas azules en futuras ventanas de mantenimiento:

1. Validar software de terceros. Revisa las notas de versión de tus agentes EDR, antivirus o backup y verifica que soportan la build publicada.
2. Probar en un clon o snapshot. Crea un checkpoint de la VM y aplica los parches en el entorno de pruebas; si el inicio es estable durante un par de ciclos, procede en producción.
3. Documentar un plan de reversión. Guarda siempre un script con comandos DISM y la lista de KB que debes retirar; la agilidad marca la diferencia durante una caída crítica.
4. Actualizar controladores propios. Fabricantes de RAID, HBA y NIC publican parches específicos tras cada «patch Tuesday». Mantenerlos al día mitiga la incompatibilidad de símbolo.
5. Supervisar los foros de Microsoft y el Health Dashboard. Allí aparecen rápidamente los hilos que confirman o desmienten si un parche es seguro.

Preguntas frecuentes

¿Puedo instalar parches posteriores sin que se reinstale KB5034768?

Sí. Con WSUS o PowerShell basta con ocultar la KB. Las acumulativas futuras incluirán los mismos archivos, por lo que Microsoft suele publicar una revisión; cuando eso ocurra libera la exclusión y prueba de nuevo.

¿Desinstalar KB5034768 deja el servidor sin protección?

Retira las versiones actualizadas de win32k.sys y otras DLL, pero aún puedes aplicar parches de defensa vertical (por ejemplo, Standalone servicing stack) y las definiciones de Defender. Es un compromiso aceptable mientras esperas el hotfix.

¿Merece la pena actualizar SQL Server antes de parchear?

Actualizar a SQL Server 2019 o 2022 no elimina el bug, pero reduce la probabilidad de drivers heredados y mejora la compatibilidad con librerías firmadas SHA‑2. Si el salto entra en tu hoja de ruta, adelantarlo simplifica el mantenimiento futuro.

Conclusión

El BSOD con 0xc000021a tras KB5034768 no es un fallo irrecuperable: con las herramientas integradas como DISM y un buen plan de snapshots, la VM vuelve a estar en línea en minutos. Lo esencial es bloquear el parche problemático, investigar los controladores implicados y aplicar una política de laboratorio que permita probar cada boletín antes de que llegue al entorno de producción.