Des VM Hyper‑V (Windows 10 Pro et Windows Server 2022) redémarrent plusieurs fois par jour avec CRITICAL_STRUCTURE_CORRUPTION (0x109). Voici une méthode éprouvée, pas à pas, pour diagnostiquer, isoler puis corriger ces crashs récurrents.
Contexte et symptômes observés
- Hôte Hyper‑V Server 2016 à jour, hébergeant six machines virtuelles : quatre Windows 10 Pro et deux Windows Server 2022 Standard.
- Trois VM (deux Windows 10, une Windows Server 2022) s’arrêtent brutalement plusieurs fois par jour avec le code 0x109.
- Les journaux Hyper‑V reprennent l’ID d’arrêt invité et les quatre paramètres du bug check.
DISM /RestoreHealth,SFC /scannow,CHKDSK /R /Fne détectent aucune anomalie.- Les minidumps pointent vers ntoskrnl.exe à des offsets variables : signature typique d’une corruption mémoire causée en amont par un pilote tiers ou un défaut matériel.
Ce que signifie CRITICAL_STRUCTURE_CORRUPTION (0x109)
Ce bug check est déclenché quand le noyau détecte une altération de structures critiques : code en lecture seule, descripteurs de mémoire, listes internes, etc. Dans la pratique, les causes les plus fréquentes sont :
- Défaillance de RAM (invité ou hôte) ou de contrôleur mémoire.
- Pilote en mode noyau instable (filtre réseau, antivirus/EDR, cryptage, sauvegarde/VSS, pilote de stockage virtuel, anti‑cheat, outils d’overclocking).
- Corruption de stockage (VHDX, contrôleur virtuel, file system) ou délais/E/S anormaux.
Les paramètres d’un 0x109 aident à classer l’incident :
- P1 : catégorie de corruption (p. ex. modification de mémoire en lecture seule, MDL invalide, structure noyau incohérente).
- P2 : détail additionnel (souvent un code/flag), utile pour WinDbg.
- P3 : adresse de la structure touchée (indicateur précieux pour remonter au composant fautif).
- P4 : valeur complémentaire/réservée selon le cas.
Check‑list express de stabilisation
- Figer le contexte : désactiver toute forme d’overclocking (hôte et invités), vérifier que les VM ne sont pas sur‑allouées (CPU/RAM), et activer la génération de kernel dumps complets.
- Mettre à jour : BIOS/firmware hôte, pilotes de contrôleurs hôte (stockage/NIC), et Services d’intégration Hyper‑V dans chaque VM.
- Tester la mémoire : hôte via MemTest86/Windows Memory Diagnostic ; invités si possible hors production.
- Isoler les pilotes tiers : activer Driver Verifier ciblé sur non‑Microsoft, démarrer en clean boot dans les VM affectées.
- Contrôler le stockage : cohérence VHDX, latences, événements disque (storport, disk), et intégrité des contrôleurs virtuels.
- Corréler les journaux : Event Viewer Hyper‑V‑VMMS / Hyper‑V‑Worker, System, et minidumps via WinDbg.
Plan de diagnostic détaillé
Mesures immédiates côté invité
Assurez‑vous que chaque VM produit un kernel memory dump exploitable :
sysdm.cpl
> Avancé > Démarrage et récupération > Écriture des informations de débogage :
- Décharge de la mémoire du noyau
- Répertoire : %SystemRoot%\MEMORY.DMP
- Écraser tout fichier existant : coché
Activez la protection supplémentaire des prises mémoire et un tag de pool pour faciliter l’analyse :
gflags /r +ptg
Tester la mémoire (hôte et invités)
Même si plusieurs VM seulement plantent, un défaut RAM hôte peut être non déterministe et n’impacter que certaines pages mappées. Procédez comme suit :
- Hôte : exécuter un test prolongé (plusieurs passes) avec un outil dédié. Idéalement, planifier une fenêtre de maintenance et charger la RAM au maximum.
- Invités : si possible, arrêter l’un des invités affectés et exécuter un test mémoire depuis un ISO de diagnostic.
En parallèle, vérifiez la configuration Mémoire dynamique Hyper‑V :
| Paramètre | Recommandation | Impact |
|---|---|---|
| Minimum RAM | Éviter les valeurs < 1 Go pour des OS modernes | Ballooning agressif = fragmentation et pression mémoire |
| Maximum RAM | Ne pas dépasser la RAM physique disponible | Sur‑allocation = paging, contention, timeouts pilotes |
| Buffer | 10–20 % en production typique | Marges pour pics transitoires |
Mettre à jour composants critiques
- Services d’intégration / Guest Services : depuis Windows 10/Server 2016, ils sont inclus et mis à jour via Windows Update. Vérifiez dans chaque VM :
Get-Service vm* | Sort-Object Status,Name | Format-Table -Auto - Pilotes de stockage & réseau invités : réinstallez/actualisez :
- Filtres NDIS (agents EDR/IDS, QoS, pare‑feu tiers),
- Filtres de stockage (chiffrement, HSM, antivirus à accès direct),
- Agents de sauvegarde (VSS provider, CBT).
- Hôte Hyper‑V : appliquez microcodes CPU, BIOS/UEFI, pilotes NIC (RSS/VMQ/SR‑IOV), contrôleurs HBA/RAID.
Vérifier la charge et la sur‑allocation
Inspectez la pression CPU/RAM/stockage en continu :
# Hôte : liste RAM/CPU par VM
Get-VM | Select Name, State, CPUUsage, MemoryAssigned, Uptime | Format-Table -Auto
# Disques virtuels : IOPS, latence
Get-VMHardDiskDrive | Get-VHD | Select Path, VhdType, VhdFormat, FileSize, Size, FragmentationPercentage Surveillez les Event IDs typiques côté invité : 129/153/157 (storport/disk), 41 (Kernel‑Power), avertissements volsnap/VSS. Une latence élevée ou une fragmentation VHDX peut accentuer des timings qui exposent des pilotes fragiles.
Analyser les journaux Hyper‑V et Windows
Où chercher :
- Event Viewer > Applications and Services Logs > Microsoft > Windows > Hyper‑V‑VMMS et Hyper‑V‑Worker : erreurs corrélées au moment du bug check (arrêt invité, reset, watchdog).
- System : storport/disk/ntfs, miniport NIC, ACPI, WHEA (Machine Check).
Exemples PowerShell :
# Événements Hyper‑V autour des 2 dernières heures
$since=(Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Hyper-V-Worker-Admin'; StartTime=$since} |
Select TimeCreated, Id, LevelDisplayName, Message | Format-Table -Auto
# Disque/Storport
Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(129,153,157)} |
Select TimeCreated, ProviderName, Id, Message | Format-Table -Auto WinDbg : tirer parti des minidumps
Le fait que ntoskrnl.exe apparaisse avec des offsets divers n’innocente pas un pilote tiers ; cela signifie plutôt que la corruption s’est produite avant le crash pointé. Procédure type :
.symfix
.reload
!analyze -v
.bugcheck
kv
!thread
!process 0 1
!poolused 2
!memusage 1
lmtn
Points d’attention :
- !analyze -v : donne la classe de corruption (interprétez P1–P4) et liste souvent le pilote le plus suspect.
- lmtn : modules non Microsoft chargés (versions, timestamps) ; ciblez les plus récents ou non signés.
- !poolused : fuites et tags de pool anormaux (activez le pool tagging via
gflagssi besoin).
Activer Driver Verifier (ciblé)
Driver Verifier force les chemins d’erreur des pilotes instables. Activez‑le uniquement sur les pilotes non‑Microsoft des VM affectées, idéalement en créneau de maintenance car il peut provoquer des crashs volontaires révélateurs.
| Option Verifier | Pourquoi | Remarques |
|---|---|---|
| Special Pool | Détecte débordements/underruns de buffers | Très utile sur filtres NDIS/stockage |
| Force IRQL Checking | Signale l’usage d’API au mauvais IRQL | Expose rapidement les DPC mal gérés |
| Pool Tracking | Identifie leaks et free invalides | À combiner avec Special Pool |
| Security Checks | Vérifie structures/limites | Complémente 0x109/0x139 |
| DMA Verification | Pour pilotes faisant du DMA | Surveillez l’impact perf |
# Lister pilotes non‑Microsoft
pnputil /enum-drivers | findstr /I /V "Microsoft Windows"
# Activer Driver Verifier (sélectif)
verifier /standard /driver
# Vérifier l’état
verifier /querysettings
# Désactiver au besoin (mode sans échec si boot loop)
verifier /reset Comparer les VM touchées vs saines
Quand seules certaines VM plantent, inspectez ce qu’elles partagent :
- Mêmes agents : antivirus/EDR, sauvegarde, chiffrement, monitoring matériel, DLP.
- Mêmes chemins de stockage : même VHDX parent/diff, même CSV/LUN, même contrôleur virtuel.
- Même version d’OS : build, cumulative updates, pilotes in‑box.
Automatisez la comparaison :
# Export rapide de la liste de pilotes tiers
Get-WmiObject Win32_PnPSignedDriver |
Where-Object {$_.DriverProviderName -ne "Microsoft"} |
Select DeviceName, DriverProviderName, DriverVersion, DriverDate, InfName |
Export-Csv C:\Temp\drivers_non_ms.csv -NoTypeInformation
# Version de configuration VM et intégration
Get-VM | Select Name, Version
Get-VMIntegrationService -VMName | Select Name, Enabled, PrimaryStatusDescription Stockage : VHDX, contrôleurs, latence
- VHDX : convertir un différentiels enchaînés en VHDX consolidé (merge) et tester en taille fixe pour éliminer la fragmentation.
- Contrôleur virtuel : préférer SCSI pour disques de données (hot‑add, file‑trimming). Éviter d’empiler trop de VHDX sur un même contrôleur.
- Mesures : relevez IOPS/latences et corrélez à l’heure du bug check.
# Exemple : vérifier la fragmentation de VHDX
Get-VMHardDiskDrive -VMName <VM> | Get-VHD |
Select Path, FileSize, Size, FragmentationPercentage | Format-Table -Auto
Paramètres BIOS/UEFI et sécurité
- DEP/NX activé, VT‑x/AMD‑V et VT‑d/AMD‑Vi actifs, UEFI Secure Boot correct.
- Désactiver tout overclocking CPU/RAM/GPU sur l’hôte.
- Si des composants de sécurité noyau « hookent » la mémoire (anti‑cheat/anti‑rootkit), validez leur compatibilité avec les versions Windows en place.
Procédure d’isolement recommandée
- Clonage contrôlé : créer un checkpoint ou exporter une VM instable, la restaurer sur un autre hôte (si disponible). Si le problème disparaît, suspectez le matériel hôte/chemin de stockage ; s’il persiste, la cause est interne à l’invité.
- Clean boot invité :
msconfig > Services : Masquer les services Microsoft > Désactiver tout > Démarrage : Désactiver les éléments non essentiels redémarrer, puis réactiver par lots pour isoler l’agent fautif. - Driver Verifier ciblé sur les pilotes récemment ajoutés/mis à jour. Collecter immédiatement le dump généré, puis l’analyser dans WinDbg.
- Tests de charge : exécuter des charges réseau et disque (copie volumineuse, tests SMB, fio équivalent) pour déclencher le problème de manière reproductible.
- Régression : si aucune cause nette, désinstaller/mettre à jour les agents communs (EDR, sauvegarde, chiffrement) un par un, avec redémarrage et observation.
Interpréter les paramètres du bug check
Sans reproduire une table exhaustive, utilisez cette grille :
| Paramètre | Interprétation pratique | Action immédiate |
|---|---|---|
| P1 : catégorie | Modification mémoire en lecture seule / structure noyau incohérente / MDL invalide | Pointer les pilotes filtrant noyau (NDIS, stockage, sécurité) |
| P2 : flags | Code interne supplémentaire | Comparer entre crashs pour un motif récurrent |
| P3 : adresse | Structure affectée | Dans WinDbg : dd P3 l64, !pte, et !pool |
| P4 : réserve | Selon le cas | Reporter tel quel dans vos notes d’enquête |
Scripts utiles de collecte
Regroupez en quelques minutes les informations clés à attacher au ticket d’incident.
# 1) Inventaire OS et correctifs
Get-ComputerInfo | Select OsName, OsVersion, OsBuildNumber, WindowsInstallDateFromRegistry
Get-HotFix | Sort-Object InstalledOn | Select HotFixID, InstalledOn
# 2) Pilotes non Microsoft
Get-WmiObject Win32_PnPSignedDriver |
Where-Object {$_.DriverProviderName -ne "Microsoft"} |
Select DeviceName, DriverProviderName, DriverVersion, DriverDate |
Export-Csv C:\Temp\drivers.csv -NoTypeInformation
# 3) Services d'intégration
Get-VMIntegrationService -VMName |
Select Name, Enabled, PrimaryStatusDescription
# 4) Événements system critiques & storport
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 200 |
Select TimeCreated, Id, ProviderName, Message | Out-File C:\Temp\system_crit.log
Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(129,153,157)} -MaxEvents 200 |
Select TimeCreated, Id, Message | Out-File C:\Temp\storport.log Bonnes pratiques Hyper‑V pour réduire le risque
- Version de configuration des VM : utiliser la version la plus élevée supportée par l’hôte, cohérente avec l’invité. Vérifier avec
Get-VM | Select Name,Version. - Affinités & NUMA : éviter d’épingle r les vCPU inutilement ; laisser Hyper‑V planifier. Sur des hôtes multi‑socket, respecter la topologie NUMA.
- Répartition des VHDX : éviter de concentrer trop d’E/S sur un même CSV/LUN ; surveiller le cache et le journalisation.
- Backups : préférer des agents compatibles Hyper‑V (VSS) et tester la restauration ; certains outils CBT non certifiés peuvent corrompre des chemins I/O.
Quand envisager des mesures radicales
- Réinstallation in‑place de l’OS invité : efficace si l’image a hérité d’une corruption logicielle ou d’un empilement de pilotes obsolètes.
- Migration vers un nouvel hôte : si l’analyse pointe du doigt le matériel (RAM/MCH/CPU) ou un firmware douteux.
- Conversion disque : passer d’un VHDX dynamique très fragmenté à un VHDX fixe propre.
Exemple de parcours de résolution
- Observation : trois VM (2×Windows 10, 1×Server 2022) quittent inopinément avec 0x109, aucun SFC/DISM/CHKDSK en défaut.
- Collecte : kernel dumps + journaux Hyper‑V‑Worker + export des pilotes tiers. On constate un filtre NDIS et un agent de sauvegarde communs aux 3 VM.
- Isolation : clean boot ; plus de crashs. Réactivation par lots : crash dès réactivation du filtre réseau ; Driver Verifier confirme (0xC4 sous charge réseau).
- Action : mise à jour du pilote incriminé + correctif de l’agent de sauvegarde. Re‑tests de charge : plus d’incidents pendant 7 jours.
Tableau récapitulatif des actions prioritaires
| Axe | Actions | Résultat attendu |
|---|---|---|
| RAM | Tests prolongés hôte/VM, ajustement mémoire dynamique | Exclure défaut matériel, réduire pression mémoire |
| Pilotes | MAJ/réinstall filtres NDIS/stockage/EDR, Verifier ciblé | Identifier et corriger le driver fautif |
| Stockage | Contrôler VHDX, latences, événements 129/153/157 | Éliminer corruption et timeouts E/S |
| Paramètres | Désactiver OC, vérifier Secure Boot, VT‑d/AMD‑Vi | Conformité plateforme de virtualisation |
| Journaux & Dumps | WinDbg, Event Viewer, corrélation temporelle | Preuves solides pour une remédiation ciblée |
FAQ ciblée
Pourquoi ntoskrnl.exe ressort‑il toujours ?
Parce que le noyau est l’endroit où la corruption est détectée, pas nécessairement créée. Un pilote tiers peut corrompre la mémoire, puis le noyau tombe en défaut ailleurs. D’où l’importance de Driver Verifier et des dumps complets.
La mémoire dynamique Hyper‑V peut‑elle provoquer un 0x109 ?
Indirectement seulement. Une pression mémoire extrême peut révéler des courses/panneaux mal gérés par des pilotes fragiles. Ajustez Minimum, Maximum et Buffer, surveillez le paging et l’utilisation réelle.
Dois‑je activer HVCI/« Intégrité de la mémoire » dans l’invité ?
Oui si vos pilotes sont compatibles. HVCI peut au contraire prévenir certaines corruptions, mais des pilotes anciens peuvent planter sous charge. Validez d’abord en pré‑production.
Faut‑il réinstaller l’OS invité tout de suite ?
Non. Essayez d’abord la mise à jour des pilotes, l’isolement par clean boot et Driver Verifier. La réinstallation in‑place est le dernier recours, utile si l’image traîne des héritages problématiques.
Conclusion
Les plantages répétés 0x109 dans des VM Hyper‑V sont presque toujours la conséquence d’un pilote noyau instable ou d’une mémoire/plateforme défaillante. En appliquant un protocole rigoureux — tests RAM, mise à jour des composants, analyse WinDbg, Driver Verifier ciblé, contrôle du stockage — vous transformez un incident intermittent difficile en une cause reproductible et donc corrigeable. Gardez des preuves (dumps, journaux, versions) : elles accélèrent grandement la remédiation et évitent les régressions ultérieures.
Annexe : Playbook rapide
- Configurer kernel dumps et
gflags /r +ptg. - Mettre à jour : BIOS/firmware hôte, NIC/HBA, intégration Hyper‑V, pilotes réseau/stockage/EDR invités.
- Tester RAM (hôte → long run, invités si possible).
- Contrôler stockage : latence, fragmentation, événements 129/153/157.
- WinDbg sur minidump :
!analyze -v,lmtn, corrélation P1–P4. - Activer Driver Verifier ciblé sur non‑Microsoft, reproduire.
- Clean boot des VM, réactivation par lots, confirmer le composant fautif.
- Corriger : mise à jour/remplacement du pilote ou de l’agent, re‑test sous charge.
- Si doute matériel : snapshot/export vers autre hôte, comparer le comportement.
- Documenter : versions, dumps, commandes, résultats de tests.