DPC_WATCHDOG_VIOLATION 0x133 sur Windows 10 et Server 2016 : analyse, causes et solutions expertes

Votre serveur Windows 10/Server 2016 (build 14393) redémarre sans prévenir avec un bugcheck DPC_WATCHDOG_VIOLATION ? Voici une procédure experte, concrète et actionnable pour identifier le pilote fautif et stabiliser durablement la plateforme, y compris en environnement virtualisé et sous charge SQL Server.

Sommaire

Vue d’ensemble

Le symptôme central est un redémarrage inopiné avec génération d’un minidump indiquant Bugcheck 0x133 : DPC_WATCHDOG_VIOLATION. L’analyse du cas type :

Fichier de vidage : 070724‑31750‑01.dmp
Contexte : un DPC/ISR a dépassé sa fenêtre d’exécution autorisée (surveillance « watchdog » du noyau).
Paramètres relevés : Arg2=0x501, Arg3=0x500 (dépassement d’un tick du watchdog — l’unité exacte dépend de KeTimeIncrement, généralement de l’ordre de quelques millisecondes).
Processus actif au moment du déclenchement : sqlservr.exe (SQL Server), indice d’une charge E/S soutenue.
Hyperviseur détecté (champ Hypervisor.Flags) indiquant une exécution dans une machine virtuelle ou un hôte avec virtualisation active.

Dans la pratique, les dépassements du watchdog sont le plus souvent causés par des pilotes (stockage, réseau, graphique) qui monopolisent le CPU au niveau ISR/DPC trop longtemps, par un firmware de périphérique présentant des latences anormales, ou par un goulet d’étranglement E/S accentué par la virtualisation.

Diagnostic rapide

Avant de dérouler un plan d’action complet, validez ces points élémentaires :

Confirmez l’événement BugCheck (Event ID 1001) et/ou Kernel-Power (Event ID 41) dans l’Observateur d’événements, rubrique Système.
Vérifiez la présence d’événements de stockage (Event ID 129 storport « Reset to device » et Event ID 153 « retry »), ou réseau (NDIS) dans les minutes précédant le redémarrage.
Identifiez les pilotes tiers chargés au moment du crash à l’aide du minidump et préparez l’environnement pour un prochain kernel dump (voir plus bas).

Plan d’action stratégique

Ce plan combine des corrections immédiates à faible risque et des investigations ciblées. Suivez l’ordre proposé ; la majorité des incidents se résolvent avant d’atteindre les étapes avancées.

Mettre à jour les pilotes critiques et le système (stockage, réseau, graphique, BIOS/UEFI, micro‑code SSD, outils d’intégration Hyper‑V/VMware). Appliquez le dernier Cumulative Update de la branche 14393 (ex. KB5035856, oct. 2025).
Contrôler l’intégrité système (SFC, DISM, CHKDSK) et rebooter proprement.
Surveiller les latences DPC/ISR avec LatencyMon ou xperf; activer Driver Verifier sur les pilotes tiers pour forcer l’apparition du coupable avec une pile exploitable.
Vérifier le matériel et l’hyperviseur : mémoire, SMART/firmware, contention CPU/E/S, placements NUMA.
Ajuster les paramètres (désactiver temporairement Fast Startup, étendre DpcWatchdogPeriod pendant l’enquête, configurer les dumps complets).

Tableau de remédiation synthétique

Axe	Actions proposées	Objectif
Pilotes et micro‑code	– Mettre à jour stockage (AHCI/NVMe, RAID/virtIO, storport), réseau (NIDS, pilotes synthétiques VM), graphique. – Mettre à jour BIOS/UEFI et firmware SSD/NVMe. – En VM : actualiser Integration Services Hyper‑V ou VMware Tools.	Supprimer la cause la plus fréquente de DPC longs : pilotes obsolètes ou instables.
Mises à jour Windows	Installer le dernier Cumulative Update de la branche 14393 (ex. KB5035856). Redémarrer.	Appliquer des correctifs noyau et stockage pertinents pour le watchdog.
Intégrité système	`sfc /scannow` `DISM /Online /Cleanup-Image /RestoreHealth` `chkdsk /f /r` (planifier hors ligne si nécessaire)	Réparer fichiers système et secteurs défectueux qui aggravent les latences E/S.
Vérifications matérielles	– Windows Memory Diagnostic ou MemTest86. – Contrôle SMART et mise à jour firmware des disques. – Côté hôte : vérifier la contention CPU/E/S et la cohérence NUMA.	Exclure RAM/disques défaillants et goulots d’étranglement au niveau hyperviseur.
Surveillance et traçage	– Activer Driver Verifier ciblé (pilotes tiers). – Utiliser LatencyMon ou `xperf -on latency` pour identifier l’ISR/DPC fautif. – Inspecter l’Observateur d’événements (Système + Application).	Pointer rapidement le pilote qui monopolise CPU au niveau DPC/ISR.
SQL Server	– Mettre SQL Server à son dernier CU. – Placer tempdb et journaux sur stockage rapide, activer le write‑cache contrôleur lorsque sécurisé. – Configurer exclusions AV pour MDF/LDF/BAK.	Réduire la pression E/S pour éviter de prolonger les DPC du contrôleur disque.
Paramètres système	– Désactiver temporairement Fast Startup (surtout Windows 10). – Optionnel : augmenter `DpcWatchdogPeriod` (ex. 2000 → 4000 ms) durant l’analyse.	Limiter les faux positifs et stabiliser l’environnement pendant l’enquête.
Captures de dump	Basculer en vidage noyau ou mémoire complète et configurer les symboles dans WinDbg.	Obtenir des piles complètes pour isoler avec certitude le module fautif.

Pourquoi ce problème survient

Dans Windows, les ISR (Interrupt Service Routines) et les DPC (Deferred Procedure Calls) gèrent des traitements temps réel (réseau, disque, GPU). Ils doivent terminer très vite. Si un pilote reste trop longtemps en ISR/DPC (boucle, attente active, firmware lent), le watchdog du noyau déclenche le bugcheck 0x133 pour protéger la stabilité. Une charge E/S lourde (SQL Server), un stockage saturé ou un hyperviseur contraint (CPU Ready élevé, datastore lent) amplifient le risque.

Mises à jour pilotes et système

Mettez d’abord à jour tout ce qui influence ISR/DPC :

Stockage : pilotes AHCI/NVMe, contrôleur RAID, storport, virtio.
Réseau : NDIS, cartes virtuelles synthétiques (Hyper‑V) ou VMXNET3 (VMware).
Graphique : même sur serveur, les pilotes GPU obsolètes peuvent générer des DPC.
BIOS/UEFI et firmware SSD/NVMe : corrige latences et timeouts bas niveau.
Outils d’intégration : Hyper‑V Integration Services/VMware Tools à jour.
Windows Update : dernier Cumulative Update pour la build 14393 (ex. KB5035856, oct. 2025).

Contrôle et réparation de l’intégrité

Exécutez ces commandes dans un Invite de commandes administrateur (ou PowerShell) :

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

Si chkdsk signale une planification au prochain démarrage, acceptez et redémarrez lors d’une fenêtre de maintenance. Répétez pour les volumes de données hébergeant bases et journaux SQL.

Surveillance des latences DPC/ISR

Avec xperf (Windows Performance Toolkit)

Sur un serveur, xperf est précis et peu intrusif.

xperf -on latency -stackwalk profile
REM Laissez tourner sous charge 5 à 15 minutes
xperf -stop -d C:\traces\watchdog.etl

Analysez le fichier .etl dans Windows Performance Analyzer : consultez DPC/ISR Duration par module. Un pilote qui concentre des durées élevées (ex. contrôleur NVMe, NDIS, GPU) est un suspect prioritaire.

Avec LatencyMon

Sur un poste Windows 10, LatencyMon expose facilement les Highest measured ISR/DPC routine execution time et les modules associés. Laissez tourner sous charge SQL (restores, index rebuilds, CHECKDB) pour reproduire.

Observateur d’événements et PowerShell

Ciblez les événements immédiatement avant le crash :

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-7)} |
  Where-Object {
    $_.Id -in 41,1001,129,153,219
  } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Cherchez des réinitialisations de contrôleur disque (129), des retries (153), des avertissements de pilote (219) ou des pannes d’alimentation (41). Les corrélations temporelles avec l’arrêt aident à prioriser le pilote incriminé.

Driver Verifier sans prise de risque

Objectif : déclencher un crash contrôlé avec une pile « parlante » pointant le pilote tiers fautif. Procédez ainsi :

Créez un point de restauration/snapshot VM et assurez l’accès console.
Activez Driver Verifier uniquement sur les pilotes tiers :

verifier /standard /driver *thirdparty.sys
REM Variante interface: verifier.exe &rarr; Créer des paramètres personnalisés &rarr; Sélectionner noms de pilotes non-Microsoft

Laissez tourner 24–48 heures sous charge. Si instable, redémarrez en Mode sans échec et désactivez :

verifier /reset

Analysez ensuite le kernel dump avec WinDbg (!analyze -v, !thread, !irp, !dpc) pour confirmer le module.

Configuration des dumps et symboles

Activez un vidage noyau ou mémoire complète :

Ouvrez sysdm.cpl → Avancé → Démarrage et récupération → Écriture des informations de débogage : « Vidage mémoire du noyau » (ou « complet » si RAM <= espace disque dédié aux dumps).
Répertoire par défaut : %SystemRoot%\MEMORY.DMP. Conservez plusieurs minidumps (%SystemRoot%\Minidump).
Dans WinDbg, configurez les symboles (serveur public Microsoft) et exécutez !analyze -v.

Optimisations spécifiques SQL Server

Mettez SQL Server au dernier Cumulative Update de sa branche.
Placez tempdb et journaux LDF sur SSD/NVMe performants ; activez le write‑back cache du contrôleur lorsque protégé par batterie/condensateur.
Activez Instant File Initialization (compte service avec privilège « Effectuer des opérations de maintenance de volume ») pour réduire les pauses d’allocation de fichiers.
Ajoutez des exclusions antivirus sur dossiers DATA, LOG, TEMPDB et BACKUP afin de limiter les hooks au niveau filtre.
Surveillez les attentes WRITELOG/PAGEIOLATCH : si élevées, la pile stockage est le suspect.

Paramètres système utiles pendant l’analyse

Fast Startup : désactivez-le temporairement (Windows 10) : Options d’alimentation → « Choisir l’action des boutons d’alimentation » → décocher « Activer le démarrage rapide ».
Fenêtre du watchdog : augmentez prudemment la valeur du registre pour réduire les faux positifs le temps de l’enquête :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Watchdog\DpcWatchdogPeriod (ex. 2000 → 4000 ms). Redémarrage requis.
Plan d’alimentation : sélectionnez « Performances élevées » sur l’hôte et la VM pour stabiliser la latence des timers.

Spécificités virtualisation

En environnement Hyper‑V/VMware, vérifiez :

CPU Ready/Co-Stop : si élevés, le vCPU est souvent déschedulé pendant de longues périodes, ce qui perturbe les ISR/DPC.
Placement NUMA : vCPU et mémoire de la VM doivent rester dans le même nœud ; évitez les surdimensionnements qui forcent l’inter‑NUMA.
Datastores : latences > 10–15 ms en écriture sous charge SQL sont un signal d’alerte.
Outils d’intégration à jour, paravirtualisation activée (VMXNET3/virtIO), temps invité synchronisé.

Contrôles matériels à ne pas négliger

Mémoire : Windows Memory Diagnostic (mode étendu) ou MemTest86 sur plusieurs passes.
Disques : lisez l’état SMART ; mettez à jour le firmware NVMe/RAID ; vérifiez l’activation du cache d’écriture.
Cartes réseau : désactivez provisoirement l’offload avancé (RSS/LSO/TSO) pour tester l’impact sur les DPC.

Script d’audit PowerShell

Automatisez les contrôles clés et centralisez les résultats pour un diagnostic reproductible :

# État Windows Update (journal reconstitué sur Server 2016/Win10)
Get-WindowsUpdateLog | Out-Null

# Pilotes présents et état

Get-PnpDevice -PresentOnly | Where-Object {$_.Status -ne 'OK'} |
Select-Object Class, FriendlyName, Manufacturer, Status

# Volumes et santé

Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining

# Disques physiques, modèle et statut

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus

# Événements critiques récents

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Id, ProviderName, Message

# Résumé des paramètres watchdog (registre)

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Watchdog' |
Select-Object DpcWatchdogPeriod, SystemLogLevel

Lecture avancée du minidump

Dans WinDbg, exécutez :

!analyze -v
!thread
!dpc
!stacks 2

Recherchez la routine DPC/ISR la plus coûteuse (Module!Routine) et la chaîne d’appels qui y mène : un filter driver antivirus ou un pilote de stockage est souvent au sommet. Si le processus actif est sqlservr.exe, corrélez avec des opérations E/S importantes (restauration sauvegardes, indexation, maintenance).

Validation après remédiation

Lorsque vous avez appliqué les mises à jour et correctifs, vérifiez la stabilité pendant plusieurs jours et suivez ces compteurs PerfMon :

DPCs Queued/sec : doit rester relativement stable.
% Interrupt Time et % DPC Time : idéalement < 5 % en moyenne sous charge normale.
Avg. Disk sec/Write / Avg. Disk sec/Read : surveillez les pics ; corrélez avec les heures des anciens crashs.

Erreurs courantes à éviter

Activer Driver Verifier sur tous les pilotes y compris Microsoft : cela peut dégrader gravement la stabilité. Ciblez les pilotes tiers uniquement.
Forcer la mise à jour d’un pilote sans point de retour (snapshot/backup) sur un serveur de production.
Négliger l’hôte virtualisé : une VM « saine » peut tout de même souffrir d’un datastore saturé ou d’un mauvais placement NUMA.

Exemple d’ordonnancement d’intervention

J0, H0–H2 : mise à jour pilotes/BIOS/firmware + Windows Update, redémarrage contrôlé.
J0, H2–H4 : SFC/DISM/CHKDSK, configuration du dump noyau, désactivation temporaire de Fast Startup.
J1 : capture xperf sous charge réelle, lecture des journaux, corrections ciblées si un module se détache nettement.
J1–J2 : Driver Verifier (pilotes tiers), collecte d’un nouveau dump en cas de crash, analyse WinDbg, mise à jour/remplacement du pilote incriminé.
J3+ : validation sous surveillance PerfMon ; réactivation des optimisations (offloads réseau, etc.) si elles avaient été désactivées pour test.

Foire aux questions

Le fait d’augmenter DpcWatchdogPeriod règle‑t‑il le problème ?
Non : cela réduit la sensibilité du watchdog et peut éviter des redémarrages pendant l’analyse, mais la cause racine reste un pilote/firmware ou une latence E/S excessive. Revenez à la valeur par défaut après résolution.

Pourquoi le problème apparaît‑il lors des sauvegardes ou des maintenances SQL ?
Parce que ces opérations saturent le chemin E/S. Un contrôleur ou un pilote disque lent (ou instrumenté par un filtre) passe plus de temps en ISR/DPC et peut déclencher le watchdog.

Je suis en VM et je n’ai pas changé de pilotes récemment, pourquoi maintenant ?
Une hausse de contention CPU/IO côté hôte, une mise à jour d’outils d’intégration, ou une modification du placement NUMA peuvent suffire à exposer un timing auparavant marginal.

Conclusion opérationnelle

En combinant mises à jour pilotes/firmware, hygiène du système de fichiers, traçage précis des ISR/DPC (xperf ou LatencyMon) et, au besoin, Driver Verifier, vous identifierez dans la grande majorité des cas le composant fautif à l’origine de DPC_WATCHDOG_VIOLATION. Conservez un kernel dump à portée, corrélez avec les journaux et surveillez les compteurs clés : une stabilité retrouvée (DPC/Interrupt < 5 %) valide la remédiation.

Ordre recommandé en pratique

Pilotes + Windows Update, puis redémarrage.
Si le problème persiste : Driver Verifier (24–48 h) et observation avec LatencyMon/xperf.
Collecter un nouveau dump ; la pile incriminée (Module!Routine) révèle souvent le pilote précis.

Points d’attention supplémentaires

Virtualisation : limitez le nombre de vCPU au strict nécessaire, assurez la cohérence NUMA, vérifiez les latences du datastore et le niveau de CPU Ready.
Automatisation : centralisez l’état des pilotes et mises à jour avec le script PowerShell d’audit fourni.
Surveillance continue : conservez dans PerfMon un jeu de compteurs DPC/ISR et stockage pour prévenir toute régression future.

En appliquant systématiquement ces mesures (mise à jour, diagnostic matériel, traçage pilote), on isole le composant fautif et on élimine les redémarrages imprévus liés au bugcheck 0x133 avec un niveau de confiance élevé, y compris sur des charges SQL Server intenses et des infrastructures virtualisées.