La pantalla azul con el código 0x00000139 (KERNELSECURITYCHECK_FAILURE) en Windows Server 2022 indica corrupción de estructuras de kernel críticas. Este artículo profundiza en las causas, los métodos de diagnóstico y las acciones correctivas, desde el hardware hasta la depuración avanzada, para devolver la estabilidad a su servidor.
¿Qué indica el bug check 0x00000139?
Cuando se produce este bug check el validador interno del kernel detecta que una o varias estructuras esenciales (listas enlazadas, descriptores de objetos, cadenas de seguridad, etc.) han sido dañadas o alteradas de forma inesperada. Para evitar una escalada de corrupción, el sistema se detiene y genera un volcado de memoria (MEMORY.DMP) con la información que permite identificar al responsable.
Síntomas asociados en Windows Server 2022
- Reinicio inesperado con BSOD 0x00000139 durante carga de servicios o bajo carga intensiva.
- Eventos de tipo Kernel‑Power 41 seguidos de errores críticos en el Visor de sucesos.
- Al reanudar, el Server Manager muestra “can’t read server list xml file” y, al inspeccionar, el XML está vacío o corrupto.
- Posibles bloqueos intermitentes de servicios dependientes de archivos de configuración XML cargados al arranque (por ejemplo, roles IIS, Hyper‑V Manager o herramientas de backup).
- Alertas WHEA con indicios de fallos de hardware o contraseñas de memoria ECC (Machine Check Events).
Flujo de diagnóstico integral
Para resolver un bug check de este tipo conviene seguir un orden que minimice falsos positivos y reduce el tiempo de inactividad:
- Descartar hardware con pruebas offline.
- Validar controladores y firmware.
- Revisar integridad del sistema operativo.
- Analizar volcados para aislar el módulo culpable.
- Verificar servicios que manipulan XML en el arranque.
- Monitorizar a largo plazo tras cada cambio.
Soluciones propuestas
| Área a revisar | Acciones recomendadas |
|---|---|
| Hardware | Ejecute diagnósticos exhaustivos (RAM, CPU, almacenamiento, controladora RAID/NVMe). Compruebe cableado, disipadores y temperaturas con la estación fuera de producción. Sustituya componentes con errores repetitivos, incluso si “pasaron” pruebas cortas. |
| Controladores | Instale versiones firmadas WHQL compatibles con Server 2022. Habilite Driver Verifier de forma escalonada (red, almacenamiento, chipset, etc.) para identificar filtrados de memoria o llamadas IRQL indebidas. Deshabilite temporalmente drivers de terceros no esenciales para acotar el fallo. |
| Sistema y archivos | Ejecute sfc /scannow y, de ser necesario, DISM /Online /Cleanup-Image /RestoreHealth. Aplique el CU (Cumulative Update) más reciente y revise si existen KB específicos que mencionen 0x139. |
| Memoria | Pase Windows Memory Diagnostic con la opción exhaustiva + ECC test (si aplica). En BIOS/UEFI, inspeccione el contador de Correctable ECC Errors. Un incremento sostenido suele ser preludio de bloques defectuosos. |
| Software y servicios | Audite instalaciones recientes de roles o aplicaciones. Quite o regrese a versiones anteriores si coinciden con la aparición del BSOD. En entornos virtualizados, valide integraciones (VMware Tools, Hyper‑V Integration Services). |
| Seguridad y malware | Ejecute un análisis completo con Microsoft Defender (modo offline si es posible). Confirme que no existan controladores rootkit que enganchen al kernel. |
| Registro/XML | Localice en el Visor de sucesos el servicio que produce la alerta “can’t read server list xml file”. Verifique permisos NTFS del XML y la cuenta de servicio implicada. Restaure el XML desde backup o regenérelo con el asistente del rol. |
Análisis forense del volcado MEMORY.DMP
Con WinDbg Preview es posible identificar rápidamente el origen:
!analyze -v
lmvm <em>DriverName</em>
Revise las etiquetas FAILUREBUCKETID, DRIVERVERIFIERDETECTEDVIOLATION y MODULENAME. Si el módulo señalado es un controlador de red de terceros, pruebe la versión sugerida por el fabricante o vuelva a la nativa de Microsoft.
Uso seguro de Driver Verifier
verifier /standard /driver <NombreDriver.sys>
shutdown -r -t 0
Empiece con el conjunto “Standard + 2 GB Pool Limit” en entornos de producción para evitar reinicios de bucle. Si el sistema no arranca, inicie en Safe Mode y ejecute verifier /reset.
Indicadores de éxito
- Ausencia de nuevas capturas 0x139 tras 72 h de carga típica.
- Registros ECC estables.
- El XML de Server Manager se genera y persiste correctamente tras cada reinicio.
Automatización de pruebas con PowerShell
El siguiente script programa diagnósticos periódicos y envía alertas por correo:
# Diagnóstico automatizado – guardar como HealthCheck.ps1
$StartTime = Get-Date
$LogFile = "C:\Logs\HealthCheck$($StartTime.ToString('yyyyMMddHHmm')).txt"
function Write-Log (\$msg) {
\$msg = "\$(Get-Date -Format u) - \$msg"
\$msg | Tee-Object -FilePath \$LogFile -Append
}
Write-Log "=== Comprobaciones de hardware ==="
Get-WmiObject -Class Win32\_TemperatureProbe | Write-Log
Get-WmiObject -Class Win32\_MemoryArray | Write-Log
Write-Log "=== SFC y DISM ==="
sfc /scannow | Write-Log
DISM /Online /Cleanup-Image /ScanHealth | Write-Log
Write-Log "=== Eventos recientes 0x139 ==="
Get-WinEvent -FilterHashtable @{LogName='System';ID=1001;StartTime=\$StartTime.AddDays(-1)} |
Where-Object {$\_.Message -like '0x00000139'} | Write-Log
Alerta (simplificada)
Send-MailMessage -To '[itops@example.com](mailto:itops@example.com)' -From '[server2022@example.com](mailto:server2022@example.com)' -SmtpServer 'smtp.example.com' \`
-Subject "Health Report Server 2022" -Body (Get-Content \$LogFile -Raw) Pruebas de estrés y monitorización
Aplique Prime95 o OCCT para CPU, CrystalDiskMark para almacenamiento y MemTest86 para RAM. Combine los resultados con un agente de monitorización (Azure Monitor, Nagios, Zabbix) y configure alertas proactivas sobre:
- Tasa de errores de disco > 0.05 %.
- ECC Correctable Errors por encima de 50 en 24 h.
- Aumento del contenedor
\Memory\Pool Nonpaged Bytes.
Buenas prácticas tras la reparación
- Documente la versión exacta de cada controlador y firmware que mostró estabilidad.
- Implemente Device Health Attestation para bloquear controladores sin firma.
- Establezca backups de configuración XML con retención de 30 días.
- Programe
sfc /scannowsemanal con corrección automática.
Preguntas frecuentes
¿Un controlador firmado puede seguir causando 0x139?
Sí. La firma garantiza autenticidad, no calidad. Errores lógicos o fugas de memoria en versiones recientes siguen provocando corrupción de estructuras de kernel.
¿Desactivar temporizadores C‑State o P‑State ayuda?
En algunos servidores, inestabilidad de firmware provoca problemas de latencia. Desactivar C‑States profundos puede estabilizar sistemas que generan 0x139 bajo cargas variables, pero aumentará el consumo eléctrico.
¿Conviene formatear y reinstalar?
Solo si el análisis forense señala corrupción masiva de sistema y los controladores correctos no resuelven el problema. Un formateo sin identificar la causa raíz suele posponer el BSOD, no eliminarlo.
Conclusión
El BSOD 0x00000139 en Windows Server 2022 rara vez es aleatorio; suele apuntar a un controlador inestable, RAM defectuosa o firmware obsoleto. Con un enfoque metódico —diagnóstico de hardware, verificación de drivers, análisis de volcados y supervisión constante— es posible restaurar la operatividad y evitar que el mensaje “can’t read server list xml file” vuelva a aparecer.