DPC_WATCHDOG_VIOLATION (0x00000133) sur Windows Server 2022 Hyper‑V : diagnostic, correctifs et prévention

Écran bleu DPC_WATCHDOG_VIOLATION (0x00000133) sur Windows Server 2022 Hyper‑V : ce guide pas‑à‑pas vous aide à diagnostiquer, corriger et prévenir ces redémarrages, en s’appuyant sur l’analyse de dumps, la mise à jour des pilotes/firmwares et la mesure des latences DPC/ISR.

Sommaire

Vue d’ensemble du problème

Sur Windows Server 2022 Standard jouant le rôle d’hôte Hyper‑V, l’écran bleu 0x00000133 – DPC_WATCHDOG_VIOLATION indique que le « watchdog » du noyau a détecté soit :

un Deferred Procedure Call (DPC) dont l’exécution a dépassé les seuils de sécurité,
ou une présence prolongée du système à un niveau d’interruption élevé (≥ DISPATCH_LEVEL), empêchant d’autres tâches critiques de s’exécuter.

En environnement serveur, la cause la plus fréquente est un pilote (stockage, réseau, HBA/RAID, parfois GPU) qui monopolise le CPU à IRQL élevé, suivi par un firmware ou un BIOS/UEFI obsolète. Lorsque le matériel a été testé sans anomalie, la priorité est donc de traiter la chaîne logiciel‑pilotes‑firmwares.

Symptômes observables

Redémarrages inopinés de l’hôte Hyper‑V, parfois sous charge I/O importante (sauvegardes, migration à chaud, opérations sur des VHDX, reconstruction RAID).
Événements système corrélés : Kernel‑Power 41 (arrêt inattendu) et BugCheck 1001 (détails du stop code), ainsi que storport 129/153 côté stockage (timeouts, réinitialisations d’un port ou d’un disque logique).
Pics de latence DPC/ISR visibles avec des outils de traçage (WPR/xperf) ou de monitoring (LatencyMon).
Sur l’hyperviseur, ralentissements transitoires dans les VM, pertes de paquets, Timeouts RDP ou iSCSI avant le crash.

Solutions, pistes de diagnostic et bonnes pratiques

Étape	Pourquoi ?	Comment faire ?
1. Récupérer et analyser les minidumps	Identifier le pilote ou le module fautif.	Activez la création de minidumps (`.dmp`), puis ouvrez‑les avec WinDbg (`!analyze -v`).
2. Mettre à jour les pilotes critiques	Les pilotes de stockage, de contrôleur RAID/HBA, réseau et GPU (même sur un serveur) sont les plus souvent en cause.	Téléchargez des versions certifiées WHQL et récentes, de préférence publiées après la sortie de Windows Server 2022.
3. Vérifier le firmware et le BIOS/UEFI	Un microcode obsolète peut provoquer des délais anormaux dans les DPC.	Installez le dernier BIOS/UEFI et le firmware des SSD/NVMe/RAID/HBA.
4. Contrôler les paramètres de stockage	Les mauvais pilotes AHCI/StorAHCI/NVMe déclenchent fréquemment ce stop code.	Désactivez les pilotes génériques au profit de ceux du fabricant ; exécutez `chkdsk /scan` et `sfc /scannow`.
5. Actualiser Hyper‑V et les composants d’intégration	Des versions non alignées hôte/VM accroissent la latence IRQ.	Appliquez les CU Windows Server 2022 et redémarrez l’hôte et l’ensemble des VM.
6. Surveiller les temps d’exécution des DPC/ISR	Confirme visuellement les pics de latence.	Utilisez LatencyMon ou `xperf -on latency` pour localiser le pilote responsable.
7. Désactiver temporairement le matériel non indispensable	Isole progressivement la source.	Retirez les cartes d’extension non critiques, suspendez les services/agents tiers, vérifiez si les plantages cessent.
8. Vérifier l’espace libre et la santé du volume `C:`	Un disque saturé ou défaillant allonge le traitement DPC.	Maintenez ≥ 10 % d’espace libre ; surveillez les compteurs SMART et remplacez le disque en cas d’erreurs.

Mise en œuvre détaillée (pas‑à‑pas)

Activer et collecter des minidumps

Vérifiez que la pagination n’est pas désactivée et configurez l’écriture des minidumps (256 Ko) pour capturer le prochain crash :

SystemPropertiesAdvanced.exe
&gt; Démarrage et récupération &gt; Paramètres
&gt; Écriture des informations de débogage : Petit vidage mémoire (256 Ko)
&gt; Répertoire : %SystemRoot%\Minidump

Automatisez en PowerShell :

# Activer minidumps et définir le dossier
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl" -Force | Out-Null
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' CrashDumpEnabled 3
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' MinidumpDir '%SystemRoot%\Minidump'
# S'assurer que le fichier d'échange existe
wmic pagefile list /format:list

Après redémarrage sur BSOD, ouvrez le .dmp dans WinDbg :

!analyze -v
lmv m &lt;nom_du_pilote_suspect&gt;
!thread
!irql

Interprétation rapide : si !analyze -v mentionne un module tiers (ex. stornvme.sys couplé à un pilote NVMe du fabricant, ixn52x64.sys pour une carte réseau, hpcisss2.sys pour un HBA, fltmgr.sys avec un filtre de sauvegarde), traitez en priorité ce composant.

Mettre à jour les pilotes critiques (stockage, HBA/RAID, réseau, GPU)

Inventoriez les versions actuellement chargées :

# Liste des pilotes PnP signés, triés par date
Get-CimInstance Win32_PnPSignedDriver |
  Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
  Sort-Object DriverDate -Descending | Format-Table -Auto

# Pilotes réseau et infos RSS/SR-IOV

Get-NetAdapter | Format-Table Name, InterfaceDescription, DriverVersion, DriverInformation

# Pilotes de stockage (storport/miniport)

Get-WmiObject -Class Win32_SCSIController | Select Name, Manufacturer

Bonnes pratiques :

Privilégiez des pilotes WHQL fournis par l’OEM du serveur (HPE, Dell, Lenovo…) ou par l’éditeur de la carte (Broadcom, Intel, Marvell…).
Mettre à jour les filtres liés aux antivirus/EDR, sauvegardes, chiffrement (les pilotes *.sys de type fltmgr peuvent retenir des IRP trop longtemps en I/O intense).
Sur hôtes RDS/RemoteApp avec GPU, installez un pilote stable (Studio/LTSB si disponible) même si l’accélération n’est pas cœur de métier.

Mettre à jour UEFI/BIOS et firmwares

Appliquez les mises à jour BIOS/UEFI, microcodes CPU (via BIOS) et firmwares de contrôleurs RAID/HBA, SSD/NVMe et cartes réseau.
Après mise à jour, réinitialisez l’alimentation (mise hors tension complète) pour garantir le rechargement des microcodes.
Évitez, à titre permanent, les ajustements agressifs d’économie d’énergie (ex. C‑States profonds) sur un hyperviseur ; si vous testez, documentez et revenez à des profils Performances élevées en production.

Paramétrage et santé du stockage

Alignez les pilotes et validez l’intégrité du volume système :

# Vérifier et réparer les fichiers système
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

# Vérifier les volumes (mode online)

chkdsk C: /scan

# Espace disque et fiabilité

fsutil volume diskfree C:
Get-Volume | Format-Table DriveLetter, FileSystemLabel, AllocationUnitSize, SizeRemaining
Get-PhysicalDisk | Get-StorageReliabilityCounter | `
Select-Object FriendlyName, Wear, ReadErrorsTotal, WriteErrorsTotal, Temperature

Recommandations de pilotes :

Préférez le miniport du fabricant pour RAID/HBA (au lieu du générique) quand l’OEM le recommande pour votre plate‑forme.
Pour NVMe : validez la combinaison stornvme.sys (Microsoft) vs pilote NVMe OEM selon le firmware du SSD ; n’utilisez jamais un pilote « hérité » non supporté.

Hyper‑V : hôte, VM et composants d’intégration

Alignez versions et correctifs pour réduire la latence IRQ et les pics DPC :

# Niveau de configuration des VM
Get-VM | Select-Object Name, Version

# Services d'intégration par VM (Windows & Linux)

Get-VM | Get-VMIntegrationService | `
Select-Object VMName, Name, Enabled, PrimaryStatusDescription | Format-Table -Auto

# Migrations à chaud et trafic storage

Get-VMHost | fl *Storage*

Appliquez les mises à jour cumulatives de Windows Server 2022 sur l’hôte et les VM.
Redémarrez toutes les VM après mise à jour de l’hôte pour recharger les services d’intégration.
Pensez à Update-VMVersion (sur les VM compatibles) pour profiter des optimisations récentes de l’hyperviseur.

Mesurer les latences DPC/ISR

Deux approches complémentaires :

Windows Performance Recorder/Analyzer (WPR/WPA) – très précis et natif.
LatencyMon – lecture rapide et orientée pilotes.

Traçage WPR/xperf :

# Capturer une trace centrée latence DPC/ISR (xperf)
xperf -on latency -stackwalk profile
REM Reproduisez la charge pendant ~2-5 minutes
xperf -d C:\Temp\DPC-ISR.etl

Ouvrez le fichier ETL dans WPA et inspectez : « CPU Usage (Precise) », « DPC/ISR », « Call Stacks ». Le pilote qui concentre le temps en DPC (ou ISR) pendant le pic est le principal suspect.

Désactivation progressive pour isoler

Désactivez temporairement les cartes d’extension non critiques (2ᵉ NIC, carte HBA secondaire, capture, etc.).
Arrêtez les services d’agents tiers (sauvegarde, supervision, EDR) un à un pour tester l’impact.
Si possible, testez sans SR‑IOV/vRSS, puis réactivez prudemment en cas d’innocence.

Espace libre et santé du volume `C:`

Gardez ≥ 10 % de libre pour les MAJ et les dumps. Surveillez :

Les compteurs SMART (usure, erreurs de lecture/écriture, température).
Les événements Disk/Storport 129/153 (réinitialisations/temps d’attente).

Check‑list « runbook » d’une heure

Fenêtre	Actions	Objectif
0–15 min	Collecte : minidumps, `MSInfo32`, `dxdiag`, `Get-CimInstance Win32_PnPSignedDriver`, journaux Système	Poser les bases d’analyse
15–30 min	Vérif. stockage (`chkdsk /scan`, SMART), espace libre, mises à jour en attente	Écarter corruption et saturation
30–50 min	Trace WPR/xperf sous charge ; désactivation ciblée (NIC/HBA secondaires, filtres)	Identifier le pilote fautif
50–60 min	Mise à jour pilote/firmware ciblée, redémarrage contrôlé, validation	Corriger et stabiliser

Scénarios typiques et correctifs rapides

Timeouts de stockage sous charge

Symptômes : événements 129/153, pics DPC sur storport.sys ou miniport RAID/NVMe, BSOD 0x133 lors de sauvegardes.

Correctifs : mettre à jour miniport RAID/NVMe, firmware SSD/contrôleur, vérifier câblage/backplane, basculer en plan d’alimentation « Performances élevées », désactiver temporairement la mise en veille des disques.

Pilote réseau provoquant des DPC longs

Symptômes : latence DPC dans ndis.sys relayée par un pilote NIC tiers, pertes de paquets, VM qui « gèlent ».

Correctifs : pilote NIC à jour (WHQL), firmware NIC, test sans SR‑IOV/vRSS/VMQ, ajustement coalescence d’interruptions au profil recommandé par l’OEM serveur.

Filtres tiers (sauvegarde, EDR, chiffrement)

Symptômes : pile fltmgr.sys en tête du temps DPC, BSOD lors des snapshots VSS ou de la déduplication.

Correctifs : mettez à jour l’agent, excluez les répertoires VM/VHDX selon les recommandations éditeur, validez la compatibilité build de l’OS.

GPU ou pilote vidéo côté hôte RDS

Symptômes : DPC longs déclenchés par le pilote vidéo lors de pics graphiques (accélération RDP, WPF, rendu 3D).

Correctifs : canal stable (LTSB/Studio), désactiver temporairement l’accélération matérielle pour valider, revoir l’allocation GPU aux VM (si GPU partagé).

Script d’aide au diagnostic (PowerShell)

Le script ci‑dessous collecte l’essentiel (versions de pilotes critiques, événements pertinents, espace disque, fiabilité stockage) et prépare un paquet de support dans C:\Temp\Support-DPC.

$out = "C:\Temp\Support-DPC"; New-Item -ItemType Directory -Path $out -Force | Out-Null

# 1) Pilotes critiques (stockage, réseau, filtres)

Get-CimInstance Win32_PnPSignedDriver |
Where-Object { $_.DeviceName -match "RAID|SAS|NVMe|Storage|Ethernet|Network|Display|HDX|Audio|Filter" } |
Select DeviceName, DriverVersion, DriverDate, Manufacturer, InfName |
Sort-Object DriverDate -Descending |
Export-Csv "$out\drivers.csv" -NoTypeInformation -Encoding UTF8

# 2) Espace disque et volumes

Get-Volume | Select DriveLetter, FileSystem, SizeRemaining, Size |
Export-Csv "$out\volumes.csv" -NoTypeInformation -Encoding UTF8
Get-PhysicalDisk | Get-StorageReliabilityCounter |
Select FriendlyName, Wear, ReadErrorsTotal, WriteErrorsTotal, Temperature |
Export-Csv "$out\storage_reliability.csv" -NoTypeInformation -Encoding UTF8

# 3) Événements clés (24 h)

$since = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$since; Id=@(41,1001,129,153)} |
Select TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Export-Csv "$out\events_system.csv" -NoTypeInformation -Encoding UTF8

# 4) Infos Hyper-V

if (Get-WindowsFeature Hyper-V -ErrorAction SilentlyContinue) {
Get-VM | Select Name, State, Version | Export-Csv "$out\vms.csv" -NoTypeInformation -Encoding UTF8
Get-VM | Get-VMIntegrationService |
Select VMName, Name, Enabled, PrimaryStatusDescription |
Export-Csv "$out\vm_integration.csv" -NoTypeInformation -Encoding UTF8
}

Compress-Archive -Path "$out*" -DestinationPath "$out.zip" -Force
Write-Host "Paquet collecté : $out.zip"

Conseils de prévention

Politique pilotes/firmwares : définissez un cycle de mise à jour trimestriel aligné sur l’OEM du serveur. Conservez un rollback documenté.
Baseline performance : enregistrez une trace WPR « saine » après chaque changement majeur pour faciliter les comparaisons.
Surveillance : ajoutez aux tableaux de bord les compteurs DPC/ISR (Processor Information\% DPC Time, % Interrupt Time) et le suivi des événements 129/153/41/1001.
Capacité stockage : gardez ≥ 20 % de marge sur les volumes hébergeant des VHDX et temp/swap.
Conception Hyper‑V : isolez trafic stockage et live‑migration, évitez la sur‑abonnement des files RSS/VMQ, testez SR‑IOV avant production.

FAQ & points d’attention

« WinDbg pointe ntoskrnl.exe. Est‑ce la cause ? »
Généralement non. Le noyau apparaît car il orchestre les interruptions. Cherchez le module tiers dans la pile d’appels, les symboles de fonction et les drivers fortement actifs en DPC.

« Puis‑je augmenter le délai du watchdog ? »
Non recommandé. Le watchdog protège l’intégrité du système ; augmenter ses seuils masque le problème et peut aggraver la corruption I/O.

« Le matériel est‑il en cause ? »
Possible mais moins fréquent si les diagnostics OEM sont OK. Commencez par les correctifs pilotes/firmwares ; remplacez les composants qui remontent des erreurs SMART/fiabilité.

Compléments utiles

Journaux : vérifiez Observateur d’événements ▸ Journaux Windows ▸ Système pour 129/153 (stockage), 41 (Kernel‑Power) et 1001 (BugCheck). Les textes des messages contiennent souvent le port ou le périphérique concerné.
Pilotes signés : évitez les pilotes « NTAMD64 Non‑WHQL ». Préférez des packages certifiés adaptés à Windows Server 2022.
Collecte automatique : si vous manquez d’un environnement de pré‑production, laissez la collecte de dumps activée pour capturer le prochain incident.
Escalade support : si l’analyse n’isole qu’ntoskrnl.exe, fournisseur ou éditeur peuvent demander des symboles privés et une trace WPR reproduisant le pic.

Résumé opérationnel

Analyser les dumps pour identifier le pilote fautif (ou la pile impliquée).
Mettre à jour/remplacer le pilote/firmware concerné et valider côté stockage/réseau.
Installer les dernières mises à jour Windows Server 2022 (hôte et VM), puis redémarrer.
Valider par monitoring (WPR/LatencyMon/PerfMon/Observateur d’événements) l’absence de pics DPC/ISR et d’événements 129/153/41/1001.

Cette démarche priorise les causes logicielles les plus probables (pilotes, filtres, firmwares). Une fois stabilisé, formalisez un plan de maintenance (pilotes/firmwares/Windows Update), gardez des baselines de performance et contrôlez régulièrement l’état du stockage et des files DPC/ISR. Vous réduirez significativement le risque de récurrence du DPC_WATCHDOG_VIOLATION sur vos hôtes Hyper‑V.