Reinicios por BugCheck en Windows Server 2019 (0xC0000005): diagnóstico y solución paso a paso

¿Tu Windows Server 2019 se reinicia con eventos “BugCheck” y parámetro 0xC0000005? Aquí tienes una guía práctica y exhaustiva para capturar el volcado correcto, analizarlo con WinDbg, aislar el controlador o hardware defectuoso y aplicar la corrección definitiva en el menor tiempo posible.

Índice

Qué significa BugCheck 0xC0000005 en Windows Server 2019

El valor 0xC0000005 señala una violación de acceso en modo kernel. En la práctica, un hilo del sistema intentó leer o escribir memoria a la que no debía acceder. Suele aparecer asociado a bugchecks como:

0x3B (SYSTEMSERVICEEXCEPTION)
0x7E (SYSTEMTHREADEXCEPTIONNOTHANDLED)
También puede verse con 0x50, 0xA, 0x1E, 0xD1 cuando el origen es un controlador o corrupción de memoria.

En entornos de servidor, la causa más frecuente se agrupa en tres ejes:

Controladores de terceros: red, almacenamiento/RAID/HBA, antivirus/EDR, backup, deduplicación, cifrado.
Hardware: RAM con errores intermitentes, módulos DIMM mal asentados, discos/SSD deteriorados, fallos en controladoras.
Integridad del sistema: archivos de sistema dañados, filtros de minifiltro (fltmc) conflictivos.

Resumen de la situación

Servidor Windows Server 2019 reiniciando cada pocos días con evento BugCheck. Param1 = 0xC0000005. Ya se actualizaron controladores del fabricante (servidor Fujitsu). La meta es obtener un volcado útil, mapear la instrucción fallida y confirmar si el culpable es software o hardware.

Flujo de trabajo recomendado

Configurar un volcado de memoria aprovechable

Necesitas un volcado que contenga el contexto del kernel y de los controladores. El “volcado de memoria del kernel” es un excelente equilibrio entre detalle y tamaño.

Abre Inicio → sysdm.cpl → pestaña Opciones avanzadas → Inicio y recuperación → Configuración.
En Escritura de información de depuración, selecciona Volcado de memoria del kernel (o Automático).
Asegúrate de que el pagefile de C: esté administrado por el sistema.
Marca Escribir evento en el registro del sistema y verifica la ruta: %SystemRoot%\MEMORY.DMP.
(Opcional) Activa minivolcados: carpeta C:\Windows\Minidump.

También puedes dejarlo listo por directiva o script:

# Habilitar crash dumps de kernel y minidumps
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Force | Out-Null
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' CrashDumpEnabled 2       # 2 = Kernel dump
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' LogEvent 1
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' MinidumpDir 'C:\Windows\Minidump'

Analizar el próximo DMP con WinDbg

Instala WinDbg (Preview) en una estación de trabajo y abre el MEMORY.DMP o el minivolcado más reciente. Ejecuta:

!analyze -v
lm

Si en el evento del Visor de eventos viste una dirección de fallo (por ejemplo, 0xFFFFF802`7D446F87), mapea esa dirección a un módulo y a una función:

ln 0xFFFFF802`7D446F87

Interpretación de resultados:

Se nombra un driver de tercero (por ejemplo, de red, HBA, backup, EDR): comprueba versión y fecha; considera actualizar o revertir al último paquete estable recomendado por el fabricante del servidor.
Solo aparece ntoskrnl.exe o “memory_corruption”: el volcado no es concluyente; continúa con pruebas de RAM/almacenamiento y ejecuta Driver Verifier de forma controlada.

Actualizar sistema, firmware y controladores críticos

Windows Update: aplica la última Servicing Stack Update y Cumulative Update para Windows Server 2019.
Firmware: BIOS/UEFI, controladora RAID/SAS, NIC (Intel/Broadcom/Mellanox), backplane, SSD/HDD.
Herramientas del fabricante: en Fujitsu, actualiza iRMC y utilidades ServerView para revisar alertas y sensores.

Consejo: mantén un snapshot de versiones (antes/después) para correlacionar cambios con los incidentes.

Comprobar hardware de forma metodológica

RAM: ejecuta mdsched.exe con prueba extendida en una ventana de mantenimiento. Idealmente, usa MemTest86 con arranque independiente.
Discos/RAID: revisa atributos SMART con herramientas del fabricante; ejecuta pruebas extendidas. En Windows: # Escaneo en línea del sistema de archivos chkdsk /scan Programar reparación (requiere mantenimiento/reinicio) chkdsk C: /f
Logs del BMC (iRMC/iLO/iDRAC): busca eventos ECC, desalineación de DIMM, fallos de PSU, thermal throttling.

Verificar integridad del sistema y filtros

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
fltmc filters

Revisa especialmente filtros de antivirus/EDR, backup, deduplicación, cifrado o DLP. Los controladores de filtro defectuosos son una fuente habitual de 0xC0000005 en el kernel.

Correlacionar eventos antes del apagón

En el Visor de eventos (Aplicación y Sistema) busca patrones alrededor del tiempo del reinicio:

1001 (BugCheck), 41 (Kernel-Power), 6008 (apagado inesperado).
Filtros/Roles: VSS, Hyper-V, SQL Server, antivirus/backup lanzando operaciones intensivas justo antes del fallo.

Usa el Monitor de confiabilidad (perfmon /rel) para ver la línea temporal de errores y actualizaciones.

# Extrae eventos de Sistema y Aplicación 30 min antes/después del BugCheck más reciente
$lastCrash = Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=41 or EventID=1001 or EventID=6008)]]" -MaxEvents 1
$start = $lastCrash.TimeCreated.AddMinutes(-30)
$end   = $lastCrash.TimeCreated.AddMinutes(30)
Get-WinEvent -FilterHashtable @{LogName='System','Application'; StartTime=$start; EndTime=$end} |
  Sort-Object TimeCreated |
  Format-Table TimeCreated, Id, ProviderName, LevelDisplayName, Message -Auto

Driver Verifier con control

Solo habilítalo en una ventana de mantenimiento. Forzará a los controladores a comportamientos estrictos y, si hay defectos, provocará un BSOD inmediato que apunta al culpable.

Ejecuta verifier → Crear configuración estándar → Seleccionar automáticamente todos los controladores instalados (mejor: solo terceros).
Reinicia; reproduce la carga habitual del servidor.
Analiza el nuevo DMP. Para desactivar: verifier /reset y reinicia.

Expectativa: rendimiento degradado temporalmente y posible aumento de BSOD mientras dure la prueba.

Tablas rápidas para acelerar el diagnóstico

Relación de bugchecks frecuentes y sospechosos comunes

Bugcheck	Descripción	Sospechosos típicos	Acción inmediata
0x3B	SYSTEMSERVICEEXCEPTION	Drivers de red/backup/filtrado	Actualizar/revertir drivers, ejecutar `!analyze -v`, `lm`
0x7E	SYSTEMTHREADEXCEPTIONNOTHANDLED	Controladores HBA/RAID/antivirus	Firmware HBA, revisar filtros con `fltmc`
0x50	PAGEFAULTINNONPAGEDAREA	RAM defectuosa, drivers de almacenamiento	MemTest, reseat DIMM, `chkdsk`
0xA / 0xD1	IRQLNOTLESSOREQUAL / DRIVERIRQLNOTLESSOR_EQUAL	NIC, filtros NDIS, EDR	Deshabilitar temporalmente o actualizar EDR/NIC
0x1E	KMODEEXCEPTIONNOT_HANDLED	Drivers variados o corrupción de memoria	Verifier; si persiste: hardware

Checklist esencial

[ ] Volcado de kernel y minivolcados habilitados
[ ] Windows Server 2019 y firmware actualizados
[ ] Análisis WinDbg ejecutado (!analyze -v, lm, ln <dirección>)
[ ] Pruebas de RAM y discos completadas
[ ] sfc/DISM sin errores
[ ] Driver Verifier aplicado y luego desactivado (verifier /reset)

Guía paso a paso ampliada

Capturar y validar el volcado

Tras un nuevo reinicio por BugCheck, confirma que se generó C:\Windows\MEMORY.DMP o un archivo en C:\Windows\Minidump. Si no existe, revisa:

Espacio libre en C:
Pagefile activo y dimensionado automáticamente
Permisos del sistema en la ruta del dump

WinDbg: comandos que marcan la diferencia

!analyze -v
.reload /f
kv
lmvm NOMBREDELDRIVER
!thread
!irpfind
!verifier 3

Buenas prácticas:

Comprueba el stack de la excepción y busca módulos de terceros arriba en la pila.
Si hay referencia a pool corruption, inspecciona con !pool y !verifier.
Usa !pte para fallos de página (0x50) si sospechas de memoria o mapeos I/O.

Actualizar sin introducir inestabilidad

Realiza cambios de uno en uno y documenta:

Actualiza BIOS/iRMC.
Actualiza controladora RAID/SAS (firmware y driver).
Actualiza NIC/NDIS.
Reinicia y observa 72 horas.

Si el fabricante (Fujitsu) dispone de un service pack o ISO de actualización, úsalo bajo mantenimiento y toma una imagen de respaldo previa.

Pruebas de RAM que no engañan

Si el error es infrecuente pero persistente, prueba por módulos o canales alternando bancos para aislar DIMMs.
Revisa BIOS por opciones de ECC, XMP/velocidad y latencias; restaura defaults si hubo ajustes.
Reasienta físicamente los DIMM y limpia contactos si es viable.

Almacenamiento y RAID

Comportamientos típicos cuando el fallo es de almacenamiento:

Errores intermitentes de timeout en controladoras SAS/SATA/HBA.
Eventos de consistency check o predictive failure en discos.
BSOD bajo carga de backup, VSS, o verificación antivirus.

Acciones:

Verifica firmware y driver de la controladora (LSI/Avago/Broadcom, etc.).
Ejecuta pruebas largas de la marca del disco/SSD.
Inspecciona cables/backplane si hay errores de enlace.

Identificar filtros problemáticos

Lista rápida de minifiltros y evaluación:

fltmc filters | Sort-Object -Descending Instances | Format-Table Name, Altitude, Instances

Sospecha de componentes que interceptan I/O a bajo nivel: antivirus/EDR, backup continuo, cifrado en disco, deduplicación. Prueba temporalmente deshabilitando o excluyendo la ruta de datos afectada para validar hipótesis.

Correlación avanzada de eventos con PowerShell

# Obtiene el último BugCheck (1001) y muestra los parámetros
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 1 |
  Select-Object TimeCreated, Message

Línea de tiempo de 2 horas alrededor del BugCheck

\$crash = Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 1
\$start = \$crash.TimeCreated.AddHours(-1)
\$end   = \$crash.TimeCreated.AddHours(1)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=\$start; EndTime=\$end} |
Sort-Object TimeCreated |
Format-Table TimeCreated, Id, ProviderName, LevelDisplayName, Message -Auto

Plantillas útiles para acelerar el análisis

Guion de análisis en 15 minutos

Verifica que hay MEMORY.DMP o Minidump.
Ejecuta !analyze -v y guarda el reporte.
Ejecuta lm y captura versiones de drivers de terceros.
Si hay dirección de fallo, haz ln <direccion>.
Si no concluye: sfc /scannow, DISM, fltmc.
Planifica MemTest y pruebas de disco.

Árbol de decisión

WinDbg apunta a un driver → Actualiza/revierte → Observa.
WinDbg no concluye + errores de ECC/SMART → Ruta hardware.
WinDbg no concluye + sin eventos hardware → Verifier con terceros → Volcado nuevo → Concluye.

Ejemplos prácticos de interpretación de WinDbg

Ejemplo de stack que delata un filtro de antivirus/EDR:

BugCheck 3B, {c0000005, fffff8027d446f87, fffffe8c3b2cf180, 0}
Probably caused by : edrfilter.sys ( edrfilter+6f87 )

STACK\_TEXT:
nt!KiSystemServiceCopyEnd
edrfilter!SomeInterceptedIoPath+0x1a7
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
nt!IofCallDriver+0x55
...

Acción: actualizar o retirar temporalmente el agente EDR; si el fallo desaparece, confirmar con el proveedor.

Ejemplo de indicio de corrupción de memoria:

Probably caused by : memory_corruption
DEFAULTBUCKETID:  CODE_CORRUPTION
PROCESS_NAME:  System

Acción: ejecutar MemTest; revisar DIMM, BIOS y temperatura; si aparece bajo carga de I/O, considerar controladora/SSD.

Buenas prácticas de cambio y contención

Implementa cambios uno a la vez y documenta fechas/horas.
Define exclusiones en antivirus/EDR para carpetas de datos críticos y rutas de backup temporales.
Configura alertas en iRMC para ECC corregido y temperaturas.
Planifica una ventana de mantenimiento semanal corta para aplicar CU/firmware gradualmente.

Comandos adicionales de utilidad

# Versiones de drivers firmados instalados
Get-WmiObject Win32_PnPSignedDriver | 
  Where-Object {$_.DriverProviderName -notmatch 'Microsoft'} |
  Select-Object DeviceName, DriverVersion, DriverProviderName, DriverDate | 
  Sort-Object DriverDate -Descending | Format-Table -Auto

Información de BIOS/UEFI

Get-CimInstance -ClassName Win32\_BIOS | Select-Object SMBIOSBIOSVersion, ReleaseDate, Manufacturer

Estado del almacenamiento (resumen)

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus, FirmwareVersion

Errores comunes que retrasan la resolución

No tener dumps por falta de pagefile o espacio insuficiente.
Actualizar “todo a la vez”, perdiendo la trazabilidad de la causa.
Ignorar los filtros de terceros (fltmc) que interceptan I/O.
Asumir que “ntoskrnl.exe” es culpable: suele ser un síntoma, no la raíz.

Caso particular: servidores Fujitsu

En plataformas Fujitsu, revisa:

iRMC: exporta registros de sistema y eventos de memoria/temperatura.
ServerView: aplica paquetes de firmware recomendados en bloque (BIOS, RAID, NIC).
Backplane/RAID: verifica cableado y consistency checks programados que puedan coincidir con los reinicios.

Resultados esperados y cierre

Siguiendo este plan, el próximo volcado debería permitirte identificar el módulo o componente responsable de la violación de acceso 0xC0000005. Con esa evidencia:

Software/driver: actualiza, revierte o desinstala el componente conflictivo.
Hardware: sustituye DIMM/SSD/disco o la controladora; valida con pruebas posteriores.

Una vez estabilizado el servidor, conserva el DMP, el reporte de WinDbg y un inventario de versiones como material probatorio y para auditoría interna.

Checklist operativa final

[ ] Dump de kernel y minidumps activados, espacio en C: verificado
[ ] Última CU/SSU de Windows Server 2019 instalada
[ ] Firmware BIOS/RAID/NIC/SSD actualizado
[ ] !analyze -v, lm y ln <direccion> ejecutados
[ ] MemTest extendido y discos verificados
[ ] sfc y DISM sin anomalías
[ ] Driver Verifier aplicado sobre terceros y luego deshabilitado
[ ] Eventos correlacionados con perfmon /rel y Get-WinEvent

Preguntas frecuentes

¿Por qué ya actualicé drivers y sigue fallando?
Puede persistir si el problema es de hardware, si el driver actualizado sigue teniendo un bug, o si otro filtro/rol (backup/EDR) dispara la condición rara. Necesitas el volcado correcto y correlación de eventos para granularity.

¿Puedo borrar el MEMORY.DMP?
Sí, una vez analizado y documentado. Asegúrate de retener al menos el último volcado útil para auditoría.

¿Debo activar Verifier en producción?
Solo en ventana de mantenimiento y focalizado a terceros. Puede generar más BSOD mientras esté activo.

Plantilla de informe post mortem

Resumen: Reinicios BugCheck 0xC0000005 en WS2019.
Causa raíz: [Driver/Hardware específico].
Evidencia: DMP [timestamp], WinDbg (!analyze -v), stack apunta a [módulo].
Corrección: [Actualizar/Revertir/Retirar] [Reemplazo de hardware].
Verificación: 7 días sin incidentes, pruebas RAM/Disco OK, eventos limpios.
Lecciones: [Excluir rutas en EDR] [Programa de firmware] [Monitoreo iRMC].

Conclusión

BugCheck con 0xC0000005 en Windows Server 2019 no tiene por qué ser una caja negra. Con un volcado bien configurado, análisis disciplinado en WinDbg, actualización controlada de firmware/controladores y pruebas de RAM/almacenamiento, podrás cerrar la incidencia con evidencia y prevenir recurrencias.

Resultado esperado: con el próximo volcado y el análisis (!analyze -v + mapeo de la dirección del evento), identificarás el driver o componente que provoca la violación de acceso y aplicarás la corrección (actualizar, revertir o retirar), o confirmarás un problema de hardware para su reemplazo.

Checklist rápida

[ ] Volcado de kernel y minivolcados habilitados
[ ] Windows y firmware actualizados
[ ] Análisis WinDbg realizado (!analyze -v, lm, ln <dirección>)
[ ] Pruebas de RAM y discos completadas
[ ] sfc/DISM sin errores
[ ] Verifier (si procede) ejecutado y luego desactivado (verifier /reset)

Con esto tendrás un camino claro y reproducible para aislar si el origen es software (driver) o hardware y aplicar la solución definitiva.