Los administradores de servidores se topan a veces con reinicios súbitos que no dejan rastros evidentes en el Visor de eventos. Uno de los escenarios más desconcertantes es el del host con Windows Server 2022, rol de Hyper‑V y miembro de un clúster de conmutación por error que se apaga sin previo aviso y vuelve a arrancar por su cuenta.
Descripción del escenario
El host reinicia de forma inesperada mientras aloja cargas críticas. En el depurador, el minidump revela el código de detención BUGCHECK 0x23 (FATFILESYSTEM) y la función FatDeleteVcb aparece en la pila con el proceso vmms.exe activo. Todo apunta a un acceso fallido a un volumen FAT o exFAT, bien por corrupción de la tabla de asignación, por sectores defectuosos, por un controlador anticuado o por agotamiento del non‑paged pool.
Cómo diagnosticar un BUGCHECK 0x23
Interpretar el minidump
Un crash dump de tipo “Small memory” (256 KB) suele bastar para saber cuál fue la última operación en el sistema de archivos. Al abrirlo con WinDbg Preview y ejecutar !analyze -v, obtendrá la pila que implica a fastfat.sys. Si la traza muestra FatLookupFile o FatCheckFreeDirent, sospeche de corrupción lógica; si resalta MmBuildMdlForNonPagedPool, centre la mirada en el consumo de memoria no paginada.
Correlacionar con el Visor de eventos
Tras cada paro inesperado, el kernel escribe un evento Critical – Kernel‑Power (41). La hora exacta de ese evento es clave: busque inmediatamente antes advertencias Disk, errores StorPort o mensajes de fastfat que informen de identificadores de disco o rutas de dispositivo. Esa correlación le permitirá casar la unidad física con el volumen lógico afectado.
Causas frecuentes
Corrupción del sistema de archivos FAT/exFAT
La familia FAT carece de las protecciones de metadatos de NTFS o ReFS. Una desconexión brusca de un disco USB o un corte de luz puede dejar estructuras internas incoherentes. Cuando Hyper‑V intenta acceder a un respaldo o a un paquete de integración almacenado en ese volumen, se produce el bugcheck.
Problemas de hardware o firmware obsoleto
Una controladora RAID con firmware desactualizado puede traducir mal las operaciones SCSI passthrough. El resultado es la misma excepción que lanzaría un sector ilegible: Windows interpreta un fallo de I/O y el controlador fastfat.sys devuelve STATUSUNEXPECTEDIO_ERROR, lo que desemboca en la parada del sistema.
Fugas de non‑paged pool
Con decenas de máquinas virtuales y volúmenes CSV montados, el host reserva miles de objetos IRP y MDL en memoria que nunca puede paginar a disco. Si un controlador defectuoso no libera esas estructuras, el pool se agota. En ese punto, cualquier nueva solicitud al subsistema FAT provoca el bugcheck 0x23 con el subcódigo 0xD (POOL_FULL).
Controladores de almacenamiento incompatibles
Los controladores WHQL para Windows Server 2016 rara vez provocan errores en 2019, pero en 2022 el modelo de colas prioriza NVMe y multipath de forma distinta. Una simple incompatibilidad de la API StorPort puede corromper los bytes de la caché de escritura que luego fastfat.sys interpreta.
Plan de acción paso a paso
| Paso | Acción | Detalle |
|---|---|---|
| Reparar el sistema de archivos | Ejecutar chkdsk /f /r en todos los volúmenes FAT/exFAT; programar el análisis al reiniciar si la unidad está en uso. | |
| Actualizar controladores y firmware | Actualizar controladoras RAID/SAS/SCSI, HBA y NIC. Actualizar BIOS/UEFI y firmware de discos. Asegurarse de usar versiones certificadas para Server 2022 y compatibles con el clúster. | |
| Verificar hardware | Revisar logs de la controladora y S.M.A.R.T. Sustituir discos con sectores reasignados. Retirar dispositivos USB/FAT no esenciales. | |
| Comprobar integridad del SO | Ejecutar sfc /scannow.Ejecutar DISM /Online /Cleanup-Image /RestoreHealth si es necesario. | |
| Vigilar el non‑paged pool | Usar PerfMon → Memory\Pool Nonpaged Bytes. Si crece sin control, usar PoolMon para identificar el controlador con fuga. | |
| Analizar registros | Visor de eventos → errores Disk, StorPort, fastfat, Autochk o advertencias de I/O en la misma marca de tiempo que el bugcheck. | |
| Buenas prácticas Hyper‑V | Alojar VHDX, checkpoints y CSV en NTFS o ReFS, no en FAT. Mantener actualizadas las Integration Services dentro de las VM. Evitar discos «flash» como almacenamiento de producción. | |
| Pruebas de estabilidad | Tras las correcciones, ejecutar DiskSpd u otra carga de E/S durante varias horas y comprobar que el host no vuelve a emitir el bugcheck. Programar reinicios controlados para validar. |
Profundizando en cada acción
Reparar con CHKDSK sin perder datos
Antes de ejecutar chkdsk /f /r exporte los contenedores VHDX o copie las máquinas críticas fuera del volumen. El parámetro /r verifica cada sector físico y puede tardar horas en discos de varios terabytes. Planifique la ventana fuera de producción y añada un post‑checkpoint para que el clúster no intente migrar de nuevo sobre la misma unidad mientras se repara.
Actualizar firmware de forma segura
En clústeres, actualice firmware nodo por nodo: pause el nodo, opere el live migration, aplique el microcódigo UEFI, verifique la versión con Get-WmiObject Win32_BIOS y devuélvalo al clúster. Solo pase al siguiente nodo cuando el primero exhiba 24 h de estabilidad.
Validar hardware con pruebas SMART extendidas
Use smartctl -x para recoger los attributes. Un aumento lento de ReallocatedSectorCt o la aparición de CurrentPendingSector revela desgaste inminente en SSD TLC. Sustituya la unidad antes de que aparezca un Uncorrectable Error bajo carga de Hyper‑V.
Detectar y detener una fuga de pool
PoolMon agrupa por etiqueta de memoria. Si observa una etiqueta que crece a ritmo fijo (NDpE es típica de un driver de red que filtra), desactive temporalmente dicho controlador, vuelva a la versión inbox o pida al fabricante un hotfix. El objetivo es mantener el pool nonpaged por debajo del 30 % de la RAM física.
Lectura avanzada del visor de eventos
Cree una Vista Personalizada con filtro XML que combine <Level>2</Level> y las fuentes Disk, StorPort, fastfat, ntfs y clussvc. Así tendrá en un solo panel todas las anomalías de E/S y podrá correlacionarlas con los reinicios de Kernel‑Power 41.
Buenas prácticas preventivas para Hyper‑V en clúster
- Deshabilite el almacenamiento en unidades flash desmontables para los nodos críticos; use puertos USB solo para la consola.
- Configure los discos del clúster en NTFS con 64‑K de tamaño de clúster o en ReFS con integridad automática.
- Habilite Storage Spaces con paridad doble si usa cabinas JBOD; tendrá resiliencia ante fallos de disco al nivel del volumen, no solo al nivel de la VM.
- Active Live Dump (HKLM\System\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump = 1) para capturar dumps de memoria en caliente y no interrumpir el host.
- Sincronice parches mensuales a través de Windows Update for Business y distribuya la carga de reinicios con anillos tempranos/tardíos.
Pruebas de estabilidad y validación
Tras ejecutar los pasos correctivos, valide con:
- DiskSpd. Ejecute
diskspd -c10G -b64K -d300 -W0 -L \\?\Volume{GUID}\test.datpara estresar el volumen. Un bugcheck inmediato volvería a manifestarse si persiste la corrupción. - Test‑Cluster. Ejecute
Test-Cluster -Include "Storage","Inventory"para detectar discrepancias de firmware entre nodos. - Uptime monitor. Use
Get-ComputerInfo -Property CsLastBootUpTimecada hora y compare con un registro de texto plano. Cualquier reinicio inesperado debe sobresalir en rojo en su sistema SIEM.
Conclusiones
BUGCHECK 0x23 puede parecer un problema exclusivo de unidades USB, pero en entornos de producción con Hyper‑V y clúster de conmutación por error suele ser síntoma de un ecosistema más amplio: firmware fuera de fecha, controladores incompatibles y workloads que presionan el pool no paginado hasta el límite. Siga el plan paso a paso para cortar la raíz del problema y devuelva la estabilidad a su plataforma de virtualización.