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.
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.
- Abilita la combinazione “CrashOnCtrlScroll”:
- 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
esfc/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
eDISM
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.