Solución a reinicios aleatorios Kernel‑Power Event ID 41 en servidores RDS Windows Server 2019

¿Tus servidores RDS reinician sin previo aviso y el Visor de eventos solo muestra Kernel‑Power Event ID 41? Aprende a diagnosticar la causa raíz, capturar volcados de memoria y aplicar correcciones definitivas en entornos virtualizados Windows Server 2019 sobre Virtuozzo u OpenStack.

Índice

Descripción general del problema

El Kernel‑Power Event ID 41 (Task 63) se registra cada vez que Windows detecta que se apagó o reinició sin una secuencia de apagado limpia. Cuando los cuatro parámetros de BugcheckCode aparecen en 0x0, significa que no hubo pantalla azul ni volcado de memoria: el sistema perdió la energía de forma brusca o alguien lo forzó a través del hipervisor. Tras restaurar servidores de sesión RDS desde una copia de seguridad, ese síntoma sugiere:

Fallo físico en el nodo o en la alimentación.
Watchdog/timeout del hipervisor que resetea la VM.
Controlador de paravirtualización defectuoso o desactualizado.
Corrupción del sistema tras el restore o cambios en la configuración de energía.

Contexto del entorno afectado

Dos máquinas virtuales Windows Server 2019 Std (compilación 1809) actúan como Session Hosts y publican aplicaciones (Office 365 y “Merit”) a usuarios finales. Ambos servidores corren sobre nodos AMD EPYC dentro de clúster Virtuozzo 7 integrado en infraestructura OpenStack. Tras la restauración con el motor de backups integrado, los hosts empezaron a reiniciarse de forma aleatoria entre dos y seis veces al día.

Síntomas observados

Evento crítico 41 Kernel‑Power sin códigos de parada, inmediatamente después de un EventLog stopped.
Registro del hipervisor muestra reset-issued mas no shutdown.
Sin minidumps en %SystemRoot%\Minidump ni MEMORY.dmp porque la VM se apaga antes de generar el volcado.
Algunos usuarios pierden sus sesiones RDS y perfiles User Profile Disk se quedan en estado huérfano (.lok).

Matriz de acciones rápidas

Área	Acciones recomendadas	Objetivo
Hardware / hipervisor	Revisar eventos kernel y dmesg en el nodo. Consultar IPMI/ILO en busca de Power Loss o Thermal Trip. Correr pruebas de stress livianas (p. ej. `stress-ng --cpu 16 --timeout 1h`) y monitorizar temperatura.	Descartar cortes de energía o watchdogs que fuerzan el reset.
Firmware y controladores	Actualizar BIOS/UEFI del nodo y firmware de backplane y NIC físicas. Instalar la versión más reciente de Virtuozzo Guest Tools. Sustituir controladores Red VirtIO y SCSI VirtIO por el canal más reciente firmado por Microsoft.	Prevenir bugs de I/O y compatibilidad post‑restore.
Configuración de Windows	Deshabilitar Inicio rápido y hibernación híbrida: `powercfg /h off powercfg /setacvalueindex SCHEMEMIN SUBSLEEP HYBRIDSLEEP 0 powercfg /setactive SCHEME_MIN` Ejecutar `sfc /scannow` y `chkdsk /r`.	Evitar inconsistencias en estados de energía al restaurar.
Memoria y disco	Ejecutar Diagnóstico de memoria de Windows (modo extendido). Validar VHDX con `vhd-util check` o herramienta del hipervisor.	Detectar corrupción silenciosa.
Registro y volcados	Desmarcar “Reiniciar automáticamente” en sysdm.cpl. Configurar volcado de memoria completo y tamaño fijo de pagefile = RAM + 25 %.	Capturar BSOD para análisis en WinDbg.
Aplicaciones / RDS	Parchear Office 365 y reinstalar “Merit”. Desconectar temporalmente discos UPD y probar carga de sesión vacía.	Aislar disparadores de software.

Procedimiento detallado paso a paso

Validar la capa física y el hipervisor

Antes de sumergirte en Windows, asegúrate de que el problema no es un power‑off genuino:

Accede a la consola IPMI y descarga el System Event Log. Busca códigos 0x02 o 0x0C relacionados con pérdida de energía o sobretemperatura.
Consulta el /var/log/vzctl.log (Virtuozzo) o la cola de mensajes del nodo KVM (/var/log/libvirt/qemu/<vm>.log) para ver si se emitió un destroy o un reset manual.
Verifica que las fuentes de alimentación redundantes reportan voltaje nominal. Los sensores de IPMI deben estar entre ±5 % de la tensión esperada.

Actualizar firmware, BIOS y Guest Tools

Un 35 % de los incidentes con Event 41 en ambientes virtualizados provienen de drivers out‑of‑tree que no fueron firmados para la build de Windows que se está ejecutando. Sigue este orden:

Aplica firmware de BMC y BIOS que el fabricante marque como critical (especialmente en CPUs EPYC de primera y segunda generación donde las revisiones micro‑código corrigen machine check exceptions).
Actualiza los paquetes virtio-win.iso a la serie 0.1.240 o superior. Evita versiones de prueba que no estén en el catálogo de Windows Update.
Instala las qemu-ga (guest agents) dentro de la VM; corrigen desincronizaciones de reloj que a veces provocan watchdogs en clúster.

Comprobar integridad del sistema operativo

:: Escaneo de archivos protegidos
sfc /scannow

\:: Reparación de sectores defectuosos
chkdsk C: /r /f /x

\:: Verificar estado del registro de CBServicing
Dism /Online /Cleanup-Image /CheckHealth

Si Dism reporta “component store corrupt”, restaura desde install.wim:

Dism /Online /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:2 /LimitAccess

Establecer políticas de energía coherentes

En servidores RDS la latencia es prioritaria, por lo que se recomienda el plan Alto rendimiento. Comprueba que no haya group policies que reescriban los planes:

powercfg /l
gpresult /h energypolicies.html
start energypolicies.html

Asimismo, los temporizadores de suspensión híbrida deben quedar deshabilitados; de lo contrario la VM puede entrar en un estado S4 simulado que el hipervisor no siempre maneja correctamente.

Cómo capturar el próximo volcado de memoria

En sysdm.cpl > Advanced > Startup and Recovery selecciona Complete memory dump y desmarca “Automatically restart”.
Fija el pagefile con tamaño mínimo = máximo: wmic pagefileset where name="C:\\pagefile.sys" set InitialSize=<RAM125%>,MaximumSize=<RAM125%>.
Crea una tarea programada que ejecute shutdown /r /t 0 /f /c "Forzando BSOD" al presionar Ctrl+ScrollLock × 2 (atajo de prueba) y confirma que se genere MEMORY.dmp. Así validas la ruta de grabación sin interrumpir producción.

Cuando ocurra el próximo reinicio, analiza el dump con WinDbg Preview y el comando:

!analyze -v
lmv m HAL
!sysinfo machineid

Busca módulos Third‑party con timestamp de hace más de 18 meses: son candidatos a provocar Machine Check Exceptions que no quedan registradas.

Comprobaciones adicionales en la VM clonada

Clonar la VM y arrancarla en un host diferente es una prueba de oro:

Si la copia no reinicia en 48 h, el culpable es el nodo original: PSU, backplane, firmware o incluso el kernel RHEL que ejecuta Virtuozzo.
Si reinicia igual, la corrupción está dentro de Windows o un controlador ya instalado.

Monitorización continua y alertas

No esperes al próximo evento 41 para enterarte. Implementa:

Perfmon Data Collector Sets para Processor Information\%Interrupt Time y Thermal Zone Information\Temperature.
Alertas en Get-WinEvent -FilterHashtable @{LogName='System';ID=129} (timeout de controlador de disco) que usualmente preceden a un kernel crash.
Alarma en el hipervisor para eventos qemu: hardware error.

Buenas prácticas de mantenimiento preventivo

Aplica parches acumulativos de Windows el mismo mes de publicación; muchos fix para Storport y vIOSCSI se incluyen en “Quality Updates”.
Mantén saneados los backups: una imagen inconsistente restaurada varias veces perpetuará cualquier corrupción latente.
Estandariza la capa de drivers: evita mezclar controladores VirtIO de diferentes ramas.
Configura Reliability Monitor y exporta reportes semanales; su índice global inferior al 7/10 es señal de que algo requiere atención antes de que llegue a un crash.

Preguntas frecuentes

¿Kernel‑Power 41 siempre implica un fallo de hardware?

No. Significa que el apagado no fue controlado; puede ser hardware, watchdog del hipervisor, corte eléctrico o incluso un Stop-Computer -Force emitido por un script.

¿Por qué no se genera minidump si tengo habilitados volcados?

Porque el sistema no entra en rutina de apagado de emergencia: simplemente pierde energía. Al desmarcar “Reiniciar automáticamente” obligas a que la próxima excepción se quede en pantalla azul y se escriba el fichero.

¿El plan de energía “Equilibrado” puede causar un Event 41?

No directamente, pero la combinación de P‑states agresivos y temporizadores de suspensión híbrida sí puede dejar la VM en un estado que el hipervisor interpreta como stalled y termina reiniciándola.

Conclusión

Los reinicios aleatorios con Kernel‑Power Event ID 41 son frustrantes porque carecen de códigos de error, pero con un método estructurado es posible aislar su causa. Revisa primero la infraestructura (fuente eléctrica, BIOS y firmware), homogeneiza los controladores VirtIO y, sobre todo, habilita volcados de memoria completos. Con la evidencia de un único BSOD bastará para resolver lo que ahora es un misterio silencioso.