Arresti anomali ricorrenti VM Hyper‑V: Bug Check 0x109 (CRITICALSTRUCTURECORRUPTION) – guida completa

Se le VM Hyper‑V iniziano a bloccarsi più volte al giorno con Bug Check 0x109 (CRITICALSTRUCTURECORRUPTION) e riferimenti a ntoskrnl.exe, la causa è quasi sempre memoria o driver in modalità kernel. Questa guida fornisce un percorso pratico, dal test hardware al debugging con WinDbg.

Indice

Panoramica del problema

Scenario reale: host Hyper‑V Server 2016 completamente aggiornato con 6 VM (4 × Windows 10 Pro e 2 × Windows Server 2022). Tre VM (2 × Windows 10 e 1 × Server 2022) presentano arresti anomali ricorrenti, più volte al giorno.

Nei minidump appare costantemente ntoskrnl.exe+42* con bug check 0x109.
Nei log Hyper‑V compaiono gli stessi codici errore propagati dall’OS guest.

Questo pattern punta a una corruzione di strutture critiche del kernel, rilevata dal Kernel Patch Protection, spesso scatenata da RAM instabile o driver difettosi.

Segnali e sintomi

BSOD con dicitura CRITICALSTRUCTURECORRUPTION (0x109) su più VM dello stesso host.
Eventi ripetuti in Event Viewer: BugCheck (ID 1001), Kernel‑Power (ID 41), avvisi/ errori Hyper‑V‑Worker e Hyper‑V‑VMMS.
Reset improvvisi senza preavviso applicativo, con tracce di storvsp, vmswitch o VMBus prima del crash.

Cause probabili

RAM fisica difettosa o marginale (timing/voltaggi borderline, XMP/overclock aggressivo, DIMM mis‑matched).
Driver in modalità kernel (rete NDIS, storage SCSI, antivirus/backup con filtri file system) che corrompono strutture interne.
Firmware e driver host obsoleti (BIOS, chipset, RAID/NVMe, schede di rete) che amplificano condizioni di race o DMA errato.
Configurazioni Hyper‑V non uniformi (memoria dinamica, vTPM, Secure Boot, versione di configurazione VM) che stressano in modo diverso lo stack.

Percorso di risoluzione consigliato

Nella tabella seguente trovi i passaggi emersi dal Q&A, con azioni concrete e perché funzionano.

Passaggio	Dettagli operativi	Perché è utile
1. Test RAM dell’host	Avvia Windows Memory Diagnostic o MemTest86; se possibile esegui anche un test memoria in‑guest.	Il codice 0x109 è spesso conseguenza di corruzione in memoria fisica.
2. Aggiorna / reinstalla driver critici	Rete (vEthernet/NDIS), storage (controller SCSI), VM Bus e Integration Components.	Driver in modalità kernel difettosi possono corrompere strutture interne del sistema.
3. Disattiva overclock	Ripristina impostazioni CPU/RAM standard nel BIOS/UEFI.	Overclock evoluti amplificano errori di memoria e race‑condition nei guest.
4. Analizza Event Viewer	Percorso: Applications & Services Logs → Microsoft → Windows → Hyper‑V‑VMMS e Hyper‑V‑Worker.	Aiuta a capire se il crash nasce nel layer host (es. controller dischi) o nel guest.
5. Debug con WinDbg	Carica i dump e segui la guida “Bug Check 0x109” per tracciare il driver preciso.	Fornisce la prova definitiva del modulo responsabile.

Procedura dettagliata

Test RAM dell’host

La priorità è escludere la RAM fisica. Anche una singola cella difettosa può generare 0x109 randomici su più VM.

Windows Memory Diagnostic: esegui mdsched.exe con riavvio e test esteso.
MemTest86: crea una chiavetta avviabile, esegui almeno 4 pass completi. Se emergono errori, isola il banco difettoso (slot‑swapping).
WHEA: controlla Event Viewer → Windows Logs → System per WHEA‑Logger (ID 1, 17, 18, 19, 20) che indichino errori corretti/fatali.
ECC: se disponibile, verifica che ECC sia attivo in BIOS/UEFI e monitora i contatori di correzione.

Comandi utili sul guest per individuare pattern (ripetere durante i crash):

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger' } -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Get-EventLog -LogName System -Source BugCheck -Newest 10

Aggiornamento o reinstallazione dei driver critici

Gli stack più sensibili sono rete, storage e VMBus. Procedi così:

Rete: verifica driver NDIS dell’host e delle NIC fisiche; allinea firmware. Sulle VM, reinstalla la scheda di rete sintetica (evita l’adattatore legacy salvo test) e aggiorna Integration Services.
Storage: per VHDX su SCSI è la scelta raccomandata; controlla driver del controller (storvsp) e del back‑end (RAID/NVMe). Evita filtri di terze parti non indispensabili.
VM Bus e Integration Components: su Windows 10 e Server 2022 arrivano da Windows Update; verifica uniformità delle versioni tra le VM.

Verifiche rapide con PowerShell sull’host:

# Versioni componenti di integrazione delle VM
Get-VM | ForEach-Object {
  Get-VMIntegrationService -VMName $_.Name |
    Select-Object VMName, Name, Version
}

Adattatori virtuali e funzionalità avanzate rilevanti

Get-VMNetworkAdapter -VMName * |
Select-Object VMName, Name, MacAddress, IovQueuePairsRequested, VmqWeight

Versioni delle VM (utile per coerenza)

Get-VM | Select-Object Name, State, Version

Tip: come prova, disabilita temporaneamente VMQ, RSS, RSC, LSO sulla NIC fisica dell’host e rifai i test. Se la stabilità migliora, hai un indizio forte sullo stack rete.

Disattivazione dell’overclock

Ripristina le impostazioni default di CPU e RAM nel BIOS/UEFI (disattiva XMP/DOCP, PBO, undervolt, BCLK). Anche overclock “leggero” può compromettere i margini della RAM in carichi di virtualizzazione intensivi.

Analisi con Event Viewer

Traccia la catena causale attorno al crash:

Hyper‑V‑VMMS/Admin e Hyper‑V‑Worker/Operational: errori nel piano di controllo (allocazione memoria, I/O, VMBus).
System: cerca BugCheck, Kernel‑Power, WHEA‑Logger, Disk, storvsp, vmswitch.
Application: prodotti di backup o antivirus che installano driver filtro possono loggare anomalie prima del BSOD.

Filtri PowerShell utili per l’host:

# Eventi Hyper-V più rilevanti nelle ultime 24 ore
$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-Hyper-V-VMMS/Admin'; StartTime=$since } |
  Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-Hyper-V-Worker/Operational'; StartTime=$since } |
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Debug con WinDbg

Quando i minidump indicano 0x109, il debugging conferma la sorgente. Procedura rapida:

Apri il dump in WinDbg (x64) e imposta i simboli, quindi ricarica.

!symfix
.reload
!analyze -v
k
lm

Interpretazione degli output:

!analyze -v riporta i parametri del bug check e spesso nomina il modulo sospetto (ad es. un driver NDIS o un filtro file system).
k mostra lo stack: se compaiono routine di rete/storage a ridosso di ntoskrnl, indaga quei driver.
lm elenca i moduli caricati: verifica versioni, date e firme digitali.

Per aumentare il valore diagnostico, imposta nei guest un Kernel memory dump invece del solo minidump (impatto disco accettabile nella maggior parte dei casi):

# Eseguito nel guest con privilegi elevati
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name AlwaysKeepMemoryDump -Value 1

Nota: usa Driver Verifier solo come ultima spiaggia e preferibilmente in ambienti di test; può rendere più frequenti i crash ma svela driver non conformi.

Raccomandazioni supplementari

Aggiorna le Integration Services delle VM
Per Windows 10 e Server 2022 arrivano tramite Windows Update; verifica che le versioni siano uniformi su tutte le VM.
Confronta configurazioni delle VM stabili e instabili
Verifica memoria dinamica, vTPM, Secure Boot, versione di configurazione VM. Differenze qui sono spesso decisive.
Verifica firmware e driver dell’host
Aggiorna BIOS/UEFI, chipset, controller RAID/NVMe e NIC. Una catena I/O marginale nell’host può propagare instabilità ai guest.
Escludi software guest con filtri kernel
Antivirus/EDR, DLP, backup, criptazione disco con driver datati sono noti per causare 0x109. Disabilitali temporaneamente per test A/B.
Test di migrazione
Sposta una VM “problematic” su un altro host. Se scompare il problema, l’hardware o i driver del nodo originario sono i principali indiziati.
Quando tutto fallisce
Apri un ticket con il supporto Microsoft allegando dump e log Hyper‑V; hanno simboli e strumenti per diagnosi avanzate.

Confronto pratico tra VM stabili e instabili

Compila una matrice come questa e verifica dove divergono le configurazioni.

Parametro	VM stabile	VM instabile	Note/azione
Memoria	Fissa	Dinamica	Prova a disattivare la memoria dinamica sulla VM instabile.
vTPM / Secure Boot	Disabilitati	Abilitati	Test con Secure Boot off (solo per diagnosi).
Versione configurazione VM	Allineata all’host	Legacy	Aggiorna alla versione massima supportata dall’host.
Tipo disco	VHDX fisso	VHDX dinamico	Converti a fisso per escludere colli di I/O e frammentazione.
NIC virtuale	Sintetica, VMQ off	Sintetica, VMQ on	Allinea VC/VMQ/RSS e rifai i test.

Prove mirate sullo stack di rete

Disabilita VMQ/RSS/RSC/LSO sull’host e sulla NIC virtuale della VM problematica; osserva la stabilità per 24‑48 ore.
Cambia vSwitch: crea uno switch esterno nuovo e collega lì la VM.
Riduci offload avanzati sulla NIC fisica (Checksum Offload, Large Send Offload) per scartare anomalie DMA.
Prova adapt legacy solo per diagnosi (prestazioni ridotte, ma aiuta a isolare il problema dallo stack sintetico).
Allinea firmware NIC e driver NDIS host con l’ultima versione stabile del vendor.

Prove mirate sullo storage

Sposta i VHDX della VM su un datastore diverso (altro array/volume) per escludere saturazioni o latenze anomale.
Disabilita write‑back caching sul controller RAID per test (se la policy lo consente) e confronta i crash.
Converti VHDX dinamico in fisso sulla VM instabile per ridurre frammentazione e variazioni di latenza.
Controlla i contatori: % Disk Time, Avg. Disk Queue Length sull’host; se anomali durante il pre‑crash, indaga driver/firmware storage.
Verifica settaggi TRIM/UNMAP in presenza di SSD/NVMe, specialmente con thin provisioning su SAN.

Controlli di firmware e driver dell’host

BIOS/UEFI: aggiorna alla release stabile più recente; ripristina i default, poi riattiva solo ciò che serve a Hyper‑V (virtualization extensions, IOMMU).
Chipset/ME: driver e firmware aggiornati riducono bug a basso livello che si manifestano come corruzioni aleatorie.
RAID/NVMe: usa driver e firmware supportati dal vendor per l’OS host; verifica lo stato della cache e delle batterie BBU.
NIC: allinea driver/firma/firmware; se usi SR‑IOV, verifica coerenza tra BIOS, driver e switch.

Esclusione software a livello guest

Molti prodotti endpoint introducono driver filtro in kernel mode. Azioni mirate:

Metti in bypass temporaneo antivirus/EDR/DLP/backup sul guest problematico (o usa un profilo senza protezioni attive).
Elenca driver caricati e versioni:

driverquery /v /fo table | more
sc query type= driver state= all

Se il crash scompare con i filtri disattivati, pianifica aggiornamenti o sostituzioni del prodotto.

Migrazione e prove incrociate

Live migration o esporta/importa la VM su un altro host. Se la VM diventa stabile, il focus torna sull’hardware/driver del primo nodo.
Replica inversa: porta una VM stabile sull’host problematico; se inizia a crashare, conferma il bias dell’host.

Checklist operativa pronta all’uso

RAM host testata a fondo (MemTest86 ≥ 4 pass) e WHEA pulito.
BIOS/UEFI, chipset, RAID/NVMe, NIC aggiornati e settaggi conservativi (no OC, no XMP).
Driver rete/storage/VMBus aggiornati su host e guest; Integration Services uniformi.
Memoria dinamica disattivata temporaneamente sulle VM instabili per verifica.
VMQ/RSS/RSC/LSO disabilitati per test, con monitoraggio stabilità.
Event Viewer analizzato su host e guest; raccolti ID 41/1001 e log Hyper‑V.
Kernel dump abilitato sui guest; WinDbg usato con !analyze -v e lm.
Test di migrazione su host alternativo completato.

Raccolta dati per il supporto

Prima di aprire un ticket, prepara questo pacchetto:

Kernel dump e minidump delle VM con 0x109.
Log Hyper‑V‑VMMS e Hyper‑V‑Worker dell’host (esporta in EVTX).
System e Application EVTX di host e guest per la finestra temporale dei crash.
Report systeminfo / msinfo32 (dove disponibile) di host e guest.
Elenco driver caricati su host e guest, con versioni e timestamp.

Sintesi operativa

Bug Check 0x109 indica corruzione di strutture critiche del kernel. Nella pratica è quasi sempre legato a RAM difettosa/marginale oppure a driver in modalità kernel che scrivono in aree non consentite. Applica l’ordine di lavoro che massimizza la probabilità di soluzione con il minimo tempo speso:

Test hardware (RAM e WHEA) e configurazione BIOS conservativa.
Aggiornamento driver/firmware di rete, storage, VMBus e Integration Services.
Analisi log su host/guest per correlazione temporale degli errori.
Debug WinDbg con kernel dump per attribuzione precisa al modulo.

Se dopo questi step i crash persistono, coinvolgi il supporto Microsoft condividendo dump e log: con i simboli privati e la telemetria dei driver possono chiudere il caso in modo definitivo.

Appendice: script d’ispezione rapido per l’host

Puoi usare questo snippet PowerShell per una fotografia veloce dell’ambiente:

# Snapshot Hyper-V host & VM health (run as admin)
$report = [ordered]@{}

$report.HostOS = (Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber)
$report.VMs = Get-VM | Select-Object Name, State, Version, MemoryStartup, AutomaticStartAction

$report.VMNet = Get-VMNetworkAdapter -VMName * |
Select-Object VMName, Name, MacAddress, IsSriovEnabled, VmqWeight

$report.VMInt = Get-VM | ForEach-Object {
Get-VMIntegrationService -VMName $_.Name |
Select-Object VMName, Name, Enabled, Version
}

$report.NICs = Get-NetAdapter | Select-Object Name, InterfaceDescription, DriverVersion, DriverDate, VmqEnabled, RssEnabled

$report.Disks = Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus, Size

$report | Format-List

Con questi dati a portata di mano, l’analisi diventa più rapida e ripetibile, soprattutto quando confronti host o ricrei il problema su ambienti paralleli.

Conclusione

Gli arresti a raffica delle VM Hyper‑V con 0x109 non sono “misteriosi”: con un approccio strutturato — hardware prima, driver poi, log e infine debug — si arriva quasi sempre alla radice. Documenta ogni modifica, effettua test A/B e mantieni uno runbook delle prove: ti aiuterà a chiudere il caso e a prevenire ricadute.

Buon troubleshooting e ambienti stabili!