Windows Server 2019 RDS: come risolvere Kernel‑Power Event ID 41 su VM Virtuozzo/OpenStack

Due session host Windows Server 2019 in un pool RDS si riavviano più volte al giorno con Kernel‑Power Event ID 41 e nessun bugcheck. L’ambiente gira su Virtuozzo/OpenStack (SeaBIOS 2014, CPU AMD EPYC, 64 GB RAM, User Profile Disks dinamici) e i crash sono iniziati dopo un ripristino da backup.

Indice

Scenario e sintomi

Hai due session host Windows Server 2019 in un pool Remote Desktop Services (broker e gateway separati) che subiscono riavvii improvvisi più volte al giorno. Nel Registro di sistema compare ripetutamente Kernel‑Power – Event ID 41 (task 63, keywords 0x8000400000000002), con BugcheckCode 0 e parametri a zero. Questo dettaglio è cruciale: indica che Windows non ha avuto il tempo di generare una schermata blu (BSOD) e il conseguente dump.

Le VM girano su piattaforma Virtuozzo/OpenStack con SeaBIOS datato (2014), CPU AMD EPYC, 64 GB di RAM e User Profile Disks (UPD) dinamici. I problemi sono comparsi immediatamente dopo un ripristino da backup, suggerendo potenziali inconsistenze a livello di storage/driver o corruzioni nei VHDX dei profili utente.

Perché compare Kernel‑Power Event ID 41 senza bugcheck

L’evento 41 non è un errore autonomo, ma un “marcatore” che Windows emette all’avvio quando rileva che l’arresto precedente non è stato pulito. Quando BugcheckCode = 0, significa che il kernel non ha registrato alcun codice di bugcheck; in altre parole, il sistema non ha eseguito la consueta routine di crash dump. Nella pratica, ciò accade di frequente quando:

la VM viene resettata dall’hypervisor (watchdog, NMI inject, power‑off/force‑reset);
si verifica una perdita di alimentazione o un fault lato host storage/CPU;
un deadlock a livello di driver o stack I/O blocca il guest e l’host interviene con reset;
ci sono problemi ACPI/energia (transizioni di stato scorrette in ambienti virtualizzati).

Mappa delle cause probabili

Ambito	Elementi da verificare	Motivo
Hardware / Hypervisor	Log host Virtuozzo/OpenStack (power loss, watchdog, NMI); firmware/BIOS obsoleti; over‑commit CPU/RAM; latenza e fault del backend storage	Event 41 con BugcheckCode 0 indica spesso un reset esterno alla VM.
Driver e aggiornamenti	Versioni di VirtIO (storage/rete/balloon); agenti guest Virtuozzo; patch Windows Server 2019; firmware controller storage dell’host	Driver obsoleti/incompatibili dopo il restore possono generare hang e reset lato host.
Dischi dinamici utenti / file system	Integrità VHDX UPD dopo ripristino; errori NTFS (ID 55/57/130), cluster danneggiati	Corruzioni dei profili causano blocchi nelle fasi di logon/logoff e I/O intensivo.
Energia / risparmio	Piano “Bilanciato” in VM; fast‑startup/ibernazione attivi; impostazioni C‑State virtuali aggressive	Transizioni ACPI errate in VM possono innescare freeze e reset.

Procedura consigliata passo‑passo

Raccogliere informazioni utili al debugging

Prima di cambiare qualunque cosa in produzione, assicurati di poter catturare un crash dump o di poter dimostrare che il reset arriva dall’host.

Disattiva il riavvio automatico su errore e imposta il dump di memoria: Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name AutoReboot -Value 0 Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Value 3 # 3 = Small dump Facoltativo: per dump kernel (richiede pagefile adeguato) Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Value 2 Verifica che il pagefile sia gestito dal sistema e presente sul volume di boot.
Forza un crash controllato per testare la pipeline dei dump (fuori orario o su VM clone):
- Abilita la combinazione “CrashOnCtrlScroll”: reg add HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f reg add HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f Dopo il riavvio, premi Ctrl + Scroll Lock due volte nella console della VM.
- In alternativa, se l’hypervisor lo supporta, invia un NMI alla VM: dovrebbe causare un bugcheck manuale e generare il dump.
Se non ottieni alcun dump ma l’Event 41 persiste, è molto probabile che il reset sia imposto dall’host.

Aggiornare in sicurezza l’intera piattaforma

Molti problemi spariscono con un allineamento coerente di firmware, hypervisor e driver. Esegui snapshot/backup, poi procedi:

Host: aggiorna BIOS/UEFI, microcodice CPU, hypervisor Virtuozzo/KVM, driver storage/NIC, firmware dei controller e del backend storage. SeaBIOS 2014 è fortemente obsoleto: valuta migrazione a OVMF/UEFI se supportato dal provider.
Guest (Windows Server 2019): applica l’ultima Cumulative Update, aggiorna VirtIO (viostor/scsi, netkvm, balloon, vioserial) e gli eventuali agenti Virtuozzo. Verifica con: pnputil /enum-drivers | findstr /i "viostor netkvm vioserial balloon virtio" Get-PnpDevice | Where-Object FriendlyName -Match "VirtIO|Red Hat" | Format-Table -Auto
Se la scheda video è “Microsoft Basic Display Adapter”, installa comunque un driver GPU compatibile fornito dall’hypervisor o disabilita componenti superflui.

Convalidare file system e VHDX

Dopo un restore, gli UPD dinamici sono candidati forti a causare I/O bloccanti. Esegui verifiche offline dove possibile:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
chkdsk C: /f /r

Per gli User Profile Disks, effettua test e riparazioni fuori linea:

# Esegui i test dei VHDX (da host Windows o VM di manutenzione)
Get-VHD -Path "D:\UPD\UVHD-*.vhdx" | Test-VHD

Monta, controlla e smonta un singolo UPD

Mount-VHD -Path "D:\UPD\UVHD-UserA.vhdx" -ReadOnly
$vol = (Get-Disk | Where-Object IsOffline -eq $false | Get-Partition | Get-Volume | Where-Object FileSystem -eq 'NTFS' | Select-Object -First 1).DriveLetter
chkdsk ${vol}: /f
Dismount-VHD -Path "D:\UPD\UVHD-UserA.vhdx"

Se trovi Event ID 55/57/130 su NTFS o UPD con errori non riparabili, ricrea i dischi dei profili (migra i dati utili e rigenera gli UVHD).

Stress test mirati e riproducibilità

Riprodurre il problema su richiesta accelera la diagnosi:

Memoria: mdsched.exe nella VM; se possibile memtest86 sull’host durante una finestra di manutenzione.
Storage: DiskSpd con pattern simili al carico reale (I/O random 4K in lettura/scrittura, code depth 8‑32).
CPU: Prime95/stressapptest nel guest per saturare scheduler e verificare stabilità.

Se sotto carico il sistema si resetta e registri un nuovo Event 41 senza dump, la pista hypervisor/storage diventa prioritaria.

Impostazioni di alimentazione raccomandate per VM

Nei server virtualizzati, elimina le transizioni energetiche inutili:

powercfg /setactive SCHEME_MIN          # High Performance
powercfg -h off                         # Disattiva ibernazione/fast-startup

Controlla anche le opzioni avanzate della NIC (temporaneamente per test): disattiva LRO/LSO, RSS/RSO e offload che possano interagire negativamente con driver VirtIO obsoleti; riattivali quando l’ambiente è aggiornato.

Raccolta e analisi dati approfondita

Estrazione rapida degli eventi rilevanti

# Eventi Kernel-Power 41, ultime 48 ore
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41; StartTime=(Get-Date).AddHours(-48)} |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -Auto

Eventi storage critici (StorPort, NTFS, Disk)

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName=@('disk','storahci','stornvme','Ntfs'); StartTime=(Get-Date).AddHours(-48)} |
Select-Object TimeCreated, ProviderName, Id, Message | Sort-Object TimeCreated

Conferme lato host

Chiedi al provider o verifica in autonomia i log dell’host (IPMI, BMC, dmesg, libvirtd, qemu-kvm, storage array) cercando corrispondenze temporali con l’Event 41 della VM. Parole chiave utili: watchdog, NMI injected, reset, virtio-blk error, I/O error, qemu quit.

Verifica che i dump possano essere scritti

Controlla la chiave HKLM\System\CurrentControlSet\Control\CrashControl (CrashDumpEnabled, DumpFile, MinidumpDir, AutoReboot).
Assicurati che il pagefile sul volume di boot sia sufficiente e non soggetto a quote.
Evita volumi di dump su VHDX o percorsi di rete: mantieni il dump sul disco di sistema per affidabilità.

Casi tipici e come riconoscerli

Reset host per watchdog: Event 41 con BugcheckCode 0; nessun dump; nei log host vedi “reset” o “NMI”. Spesso appare in coincidenza con picchi di latenza storage o CPU steal time.
Driver storage VirtIO difettoso o obsoleto: Eventi Storport 129/153; freeze I/O che precede il reset; miglioramento dopo l’aggiornamento del driver.
UPD corrotti: errori NTFS su file di profilo, sessioni RDS che restano appese, blocchi durante logon/logoff; si risolve ricreando i dischi profilo.
Problemi ACPI/energia: freeze casuali senza pattern I/O; mitigati da profilo High Performance e aggiornamenti firmware/BIOS.

Piano di azione pratico

Applica gli step nell’ordine seguente per massimizzare l’impatto e ottenere segnali diagnostici puliti.

Allineamento update e driver

Installa l’ultima Cumulative Update di Windows Server 2019 sui due session host.
Aggiorna i pacchetti VirtIO (viostor/scsi, netkvm, balloon, vioserial) e gli agenti Virtuozzo nella VM.
Richiedi al provider l’aggiornamento del BIOS/UEFI dell’host e valuta migrazione a OVMF/UEFI; verifica lo stato dei firmware storage.

Sanity check dello storage

Esegui chkdsk e sfc/DISM sul disco di sistema.
Ispeziona gli UPD: se trovi errori ricorrenti o tracce di corruzione, rigenerali. Mantieni temporaneamente quote di crescita più conservative sui VHDX dinamici.

Hardening energetico e rete

Imposta profilo High Performance e disattiva fast‑startup/ibernazione.
Per test, disabilita temporaneamente LRO/LSO/Checksum Offload sulla NIC VirtIO; verifica la stabilità, poi riattiva dopo l’aggiornamento.

Acquisizione e correlazione eventi

Crea un Data Collector Set con contatori: LogicalDisk Avg. Disk sec/Read/Write, PhysicalDisk Current Disk Queue Length, Processor % Interrupt Time, System Processor Queue Length, RDS Sessions. Campionamento 15s.
Su host, acquisisci log IPMI/BMC, dmesg e metriche storage. Punta alla correlazione temporale con gli Event 41.

Strumenti e comandi che accelerano la diagnosi

Obiettivo	Comando	Note
Disattivare riavvio automatico	`Set-ItemProperty … CrashControl\AutoReboot 0`	Evita loop silenziosi; consente di vedere eventuale BSOD in console.
Impostare dump	`CrashDumpEnabled = 3` o `2`	Small o Kernel; assicurati di avere pagefile sufficiente.
Forzare crash	`CrashOnCtrlScroll` + Ctrl+ScrollLock x2	Conferma che la pipeline dei dump è funzionante.
Elenco driver VirtIO	`pnputil /enum-drivers \| findstr /i virtio`	Confronta le versioni tra i due host.
Eventi storage critici	`Get-WinEvent` filtrato	Cerca 129/153 Storport, 55/57/130 NTFS.
Verifica VHDX	`Get-VHD \| Test-VHD`	Esecuzione offline per affidabilità.

Pattern decisionali per isolare la causa

               ┌───────────────────────────┐
               │  Event 41 (Bugcheck=0)?   │
               └──────────────┬────────────┘
                              │Sì
                              ▼
                  ┌──────────────────────┐
                  │ Dump generato?       │
                  └───────┬──────────────┘
                          │No
                          ▼
         ┌───────────────────────────────────────────┐
         │ Probabile reset lato host/hypervisor       │
         │→ Verifica log host, storage, watchdog      │
         └───────────────────────────────────────────┘
                          │
                          │Sì (dump presente)
                          ▼
        ┌────────────────────────────────────────────┐
        │ Analizza bugcheck:                          │
        │ 0x9F → driver power/energia                 │
        │ 0x124 → WHEA/hardware                       │
        │ 0x7E/0xD1 → driver di terze parti          │
        └────────────────────────────────────────────┘

Ottimizzazioni specifiche per RDS e UPD

Sessioni sporche e UPD bloccati possono amplificare la latenza di I/O all’accesso. Implementa script di pre‑logon per validare spazio libero e stato del VHDX, e policy per il cleanup dei profili temporanei.
Evita UPD troppo frammentati: pianifica una deframmentazione o ricreazione periodica, soprattutto dopo restore massivi.
Monitora rdpclip.exe e i servizi RDS: se noti hang frequenti, valuta di disabilitare temporaneamente il reindirizzamento di alcune periferiche per test.

Buone pratiche di stabilità su Virtuozzo/OpenStack

Preferisci controller SCSI VirtIO moderni e modelli di NIC recenti; evita combinazioni legacy miste (IDE + SATA + VirtIO).
Controlla il NUMA topology esposta alla VM: assegna vCPU e RAM in modo contiguo per ridurre latenza e cross‑node penalties.
Evita eccessivo over‑commit su host (CPU/RAM/IOPS). Anche senza contatori VMware, puoi inferire contention osservando Processor Queue Length e latenza disco nel guest.
Valuta migrazione live dei due host RDS su un altro nodo fisico: se il problema non segue la VM, l’hardware originario è sospetto.

Checklist rapida

[ ] Dump di memoria configurato e verificato con crash manuale
[ ] Host/hypervisor aggiornati (BIOS/UEFI, Virtuozzo/KVM, firmware storage)
[ ] Driver VirtIO e agenti guest aggiornati
[ ] chkdsk, sfc e DISM senza errori
[ ] UPD testati con Test‑VHD o ricreati in caso di corruzione
[ ] Profilo energetico High Performance e offload NIC verificati
[ ] Stress test storage/CPU eseguiti, con esito stabile
[ ] Correlazione Event 41 ↔ log host/IPMI/journald completata

FAQ per tecnici

Perché dopo un restore compaiono reset improvvisi?
Backup/restore a livello blocco possono ripristinare VHDX in stato “pulito” ma con metadata incongruenti (journaling incompleto, bitmap di allocazione). Alla prima ondata di I/O degli utenti, NTFS/UPD possono incappare in tempi di risposta anomali, innescando hang lato guest e watchdog lato host.

Basta aggiornare i driver VirtIO?
Spesso aiuta, ma senza un firmware/BIOS aggiornato sull’host e senza confermare lo stato del backend storage, il problema può ripresentarsi. L’allineamento di tutta la catena è la strategia più solida.

Il piano “High Performance” fa davvero la differenza in VM?
Sì: riduce le transizioni C/P‑state e certe logiche di sospensione che in ambienti virtualizzati possono introdurre latenze o bug nei driver power‑aware.

Se trovo WHEA nel log?
Eventi WHEA‑Logger (errori macchina) puntano a problemi hardware: CPU, RAM, interconnessioni o persino firmware. In questi casi indaga l’host con priorità.

Conclusioni operative

Event ID 41 con BugcheckCode 0 su Windows Server 2019 in ambienti RDS e Virtuozzo/OpenStack è quasi sempre un riavvio non pulito imposto dall’esterno o un hang che non riesce a produrre dump. Per arrivare rapidamente alla radice, lavora su due binari in parallelo: abilita e testa la cattura dei dump nel guest e correla i log dell’hypervisor con i timestamp dei reset. Nel frattempo, allinea firmware, hypervisor e driver, controlla e, se necessario, rigenera gli UPD, imposta il profilo energetico corretto e sottoponi la piattaforma a stress test. Con questo approccio otterrai dati diagnostici affidabili, ridurrai le cause più frequenti e stabilizzerai gradualmente i tuoi session host.

Approfondimenti utili

Event ID 41 è un indicatore di riavvio imprevisto: non sostituisce il crash dump né lo genera; serve come indizio per correlare il momento dell’anomalia.
Bugcheck tipici: 0x9F (stati energia/driver), 0x124 (WHEA/hardware). La strategia d’indagine varia di conseguenza.
Migrare temporaneamente la VM su un host diverso è un test rapido ad alto valore per separare cause guest da cause host.

Seguendo la sequenza proposta—dump, update coordinati, sanità del file system/UPD, hardening energetico e correlazione dei log—ridurrai drasticamente il tempo medio alla risoluzione e otterrai una piattaforma RDS più prevedibile e resiliente.