Accueil » Blog » Informatique » Windows » Ecrans bleus (BSOD) » DPC_WATCHDOG_VIOLATION : les solutions (SSD, pilotes, chipset)

DPC_WATCHDOG_VIOLATION : les solutions (SSD, pilotes, chipset)

L’erreur DPC_WATCHDOG_VIOLATION apparaît quand un pilote monopolise le processeur trop longtemps à un niveau d’interruption élevé, et Windows arrête le système avant que le blocage ne se propage. Sur les ordinateurs récents, le trio pilote de stockage SSD, pilote de chipset et carte graphique concentre l’essentiel des cas de cette erreur.

Points clés

  • Code d’erreur officiel : 0x00000133, déclenché par le chien de garde des appels de procédure différée (DPC).
  • Microsoft rappelle qu’un DPC ne devrait pas dépasser 100 microsecondes et une routine d’interruption 25 microsecondes.
  • Le paramètre 1 distingue un DPC unique trop long (valeur 0) d’un système resté trop longtemps au niveau DISPATCH_LEVEL (valeur 1).
  • Suspects habituels de ce crash : contrôleur SATA ou NVMe mal piloté, pilote chipset obsolète, pilote graphique nvlddmkm.sys, périphérique USB ou Bluetooth ancien.
  • La solution la plus rentable reste le passage du contrôleur de stockage sur le pilote AHCI standard de Microsoft, avant toute intervention matérielle.

Ce que mesure le chien de garde DPC

Un appel de procédure différée (DPC) est un morceau de code qu’un pilote reporte pour libérer une interruption matérielle au plus vite. Le noyau (kernel) de Windows accorde à ces routines un budget de temps très court. Quand un pilote dépasse ce budget, ou quand le système entier reste bloqué à un niveau de requête d’interruption élevé, le chien de garde déclenche le contrôle de bogue.

La documentation Microsoft est explicite sur le sens des paramètres : la valeur 0 en paramètre 1 signale un DPC ou une routine d’interruption unique qui a dépassé son allocation, la valeur 1 signale une période prolongée passée au niveau DISPATCH_LEVEL. Dans les deux cas, le composant fautif est identifiable par une trace d’appels dans le fichier de vidage écrit par le système d’exploitation.

A lire  Écran bleu KMODE_EXCEPTION_NOT_HANDLED : les solutions

Contrairement à un plantage de lecture de données noyau, ce code d’arrêt ne dit rien de l’intégrité du disque. Il dit qu’un pilote a été trop lent, ce qui distingue ce crash d’une erreur mémoire de type IRQL.

Schéma des budgets de temps DPC et ISR et des deux valeurs du paramètre 1 du code 0x133
Les valeurs de référence du chien de garde DPC, d’après Microsoft Learn.

Les causes de l’erreur, par ordre de fréquence

  • Pilote de contrôleur de stockage inadapté. Un pilote SATA fourni par le constructeur pour une génération précédente reste installé après une migration vers un SSD NVMe.
  • Micrologiciel de SSD ancien. Les fabricants publient des mises à jour de firmware qui corrigent des latences excessives sur certaines commandes.
  • Pilote graphique. Le module nvlddmkm.sys apparaît régulièrement dans les traces, en particulier après une mise à jour partielle.
  • Périphériques USB et Bluetooth. Casques, adaptateurs Wi-Fi bon marché et hubs alimentés génèrent des interruptions mal gérées.
  • Logiciel installant un pilote noyau. Antivirus tiers, machines virtuelles, outils de synchronisation de fichiers montant un lecteur réseau. Ces logiciels sont rarement suspectés, à tort.

Les solutions, de la moins risquée à la plus lourde

Appliquez ces solutions dans l’ordre, une étape à la fois, et laissez tourner l’ordinateur entre deux essais. Enchaîner trois manipulations d’affilée rend impossible d’attribuer la correction à l’une d’elles.

1. Identifier le pilote cité dans le journal

Sur l’ordinateur concerné, ouvrez l’Observateur d’événements, journal Système, et cherchez la source BugCheck. Notez le code d’erreur, l’horodatage et le nom de fichier associé. La fenêtre d’historique de fiabilité donne la même chronologie sous forme graphique, ce qui aide à relier le premier crash à une installation précise.

Si un module comme nvlddmkm.sys, iastor.sys ou ntoskrnl.exe revient à chaque fois, vous tenez la piste du driver responsable. Le cas particulier de ntoskrnl.exe mérite une lecture séparée, car ntoskrnl.exe est presque toujours cité par défaut quand le vrai coupable n’a pas pu être isolé.

2. Basculer le contrôleur de stockage sur le pilote AHCI standard

Ouvrez le Gestionnaire de périphériques, développez Contrôleurs IDE ATA/ATAPI, faites un clic droit sur le contrôleur SATA AHCI, puis Mettre à jour le pilote, Parcourir mon poste, Choisir parmi une liste. Sélectionnez Contrôleur SATA AHCI standard et redémarrez.

Cette étape est réversible et sans risque pour vos données. Elle remplace un driver constructeur potentiellement inadapté par celui de Microsoft, qui n’est pas le plus rapide mais qui respecte les budgets de temps du kernel.

3. Mettre à jour chipset, stockage et carte graphique

Prenez les pilotes de chipset chez le constructeur de la carte mère ou de l’ordinateur portable, avec la référence exacte de l’appareil. Chez Lenovo comme chez les autres, la page support du modèle est la seule source fiable. Sur les plateformes AMD, la page officielle de téléchargement des pilotes fournit le paquet complet.

A lire  Écran Bleu Unexpected Kernel Mode Trap : Les Solutions

Pour le SSD, vérifiez le micrologiciel avec l’utilitaire du fabricant. Pour le pilote vidéo NVIDIA ou AMD, désinstallez proprement l’ancienne version avant d’installer la nouvelle, une simple mise à jour par-dessus laissant souvent des fichiers de l’ancienne version.

Schéma classant les suspects de l'erreur DPC_WATCHDOG_VIOLATION par ordre de priorité
Ordre d’examen conseillé pour l’erreur 0x133.

4. Réparer les fichiers système et le disque

En invite de commandes administrateur, lancez successivement sfc /scannow puis, si des fichiers restent non réparables, DISM /Online /Cleanup-Image /RestoreHealth. Terminez par chkdsk C: /f /r, qui s’exécutera au prochain démarrage de Windows et vérifiera les secteurs du disque.

Ce dernier outil peut prendre plusieurs heures sur un disque mécanique. Sur un SSD, il est rapide, mais il ne remplace pas la vérification du micrologiciel. Si le disque n’apparaît plus du tout, la marche à suivre est différente et détaillée dans notre article sur un SSD non reconnu ou non détecté.

5. Débrancher les périphériques un par un

Retirez tout périphérique qui n’est pas indispensable : disques externes, hubs USB, clés Wi-Fi, adaptateurs Bluetooth, station d’accueil. Utilisez l’ordinateur ainsi pendant une journée complète, en gardant vos usages habituels.

Si les écrans bleus cessent, rebranchez chaque périphérique un à un, à raison d’un par jour. C’est lent, mais c’est la seule des méthodes disponibles qui produise une réponse fiable sans matériel de diagnostic.

6. Démarrage propre et Vérificateur de pilotes

Un démarrage en mode minimal, configuré avec msconfig, désactive tous les services non Microsoft et permet de savoir si un logiciel tiers est à l’origine du problème. Le mode sans échec sert au même diagnostic quand le système ne tient plus assez longtemps pour être configuré.

Le Vérificateur de pilotes va plus loin en forçant un plantage qui nomme le pilote fautif. Réservez cet outil à la fin du parcours : mal réglé, il empêche le démarrage normal et impose de passer par le mode sans échec pour lancer verifier /reset.

7. Réinstallation propre, puis remplacement du disque

Une installation neuve de Windows, sans pilote tiers, tranche définitivement entre logiciel et matériel. Restaurer le système à un point antérieur est une étape moins lourde, à tenter avant. Sauvegardez d’abord : l’opération efface la partition système.

Si le crash survit à une installation propre de Windows, le SSD ou la carte mère sont en cause. Contrôlez la santé du disque avec l’utilitaire du fabricant avant d’acheter quoi que ce soit, les valeurs SMART et l’état des données stockées suffisent souvent à trancher.

Les outils de diagnostic à utiliser

Trois outils intégrés à Windows suffisent pour la première passe. L’Observateur d’événements donne la chronologie des erreurs. Le Gestionnaire de périphériques expose la version de chaque pilote et signale les périphériques en défaut. La commande msinfo32 liste les pilotes chargés et leur éditeur.

A lire  Écran bleu CRITICAL_PROCESS_DIED : les solutions

Pour lire une trace d’appels, il faut le débogueur Windows et le fichier de vidage. Cette étape dépasse le cadre d’un dépannage courant, mais elle est la seule à nommer le pilote fautif avec certitude. Les outils tiers qui promettent de corriger l’erreur automatiquement ne font, dans les faits, que relancer les mêmes mises à jour de pilotes.

Restaurer le système avant d’aller plus loin

Si l’erreur est apparue après une installation précise, la restauration du système ramène l’ordinateur à un état antérieur sans toucher aux documents. Ouvrez la protection du système, choisissez un point antérieur au premier crash, et laissez l’opération se terminer.

Cette solution ne corrige rien en profondeur : elle isole la cause. Si le problème disparaît puis revient après réinstallation du même logiciel, vous avez identifié le coupable en deux étapes.

Quand ça ne vient pas de là

Des codes d’arrêt qui changent à chaque crash orientent vers la mémoire ou l’alimentation plutôt que vers un pilote unique. Le guide des écrans bleus Windows 10 et 11 regroupe les codes d’erreur par famille et donne les solutions propres à chaque écran bleu.

Un plantage systématique à la mise en veille, avec le code DRIVER_POWER_STATE_FAILURE plutôt que celui-ci, désigne la gestion d’énergie d’un pilote et se traite autrement. Un arrêt brutal de l’ordinateur sans écran bleu relève plutôt du redémarrage intempestif Kernel-Power 41.

Questions fréquentes

DPC_WATCHDOG_VIOLATION vient-il forcément du SSD ?

Non, mais le stockage est le premier suspect statistique sur les machines migrées d’un disque mécanique vers un SSD sans mise à jour des pilotes. Le pilote vidéo et les périphériques USB suivent de près.

Le passage au pilote AHCI standard ralentit-il la machine ?

La différence est mesurable en test synthétique et invisible à l’usage courant. Sur un ordinateur qui plante plusieurs fois par jour, la stabilité vaut largement le débit perdu, et vos données courent moins de risques.

Faut-il désactiver le démarrage rapide de Windows ?

C’est un test utile quand les plantages surviennent juste après l’allumage. Le démarrage rapide restaure un état du kernel enregistré sur le disque, donc il rejoue aussi l’état d’un driver défaillant.

Le code peut-il apparaître sur un ordinateur portable neuf ?

Oui, cette erreur touche aussi un ordinateur neuf, en particulier dans les semaines qui suivent la sortie d’un modèle, le temps que le constructeur publie des pilotes de chipset corrigés. La page support du modèle est alors la seule source à consulter.

Que faire si Windows ne démarre plus assez longtemps pour appliquer ces étapes ?

Passez par le mode sans échec de Windows, qui charge un jeu minimal de drivers, ou par l’environnement de récupération accessible après trois échecs de démarrage consécutifs. La mise à jour des pilotes de stockage y reste possible.

Photo d’en-tête : « SAMSUNG M.2 NVMe SSD 990 PRO 4TB » par Dinkun Chen, licence CC BY-SA 4.0, via Wikimedia Commons. Ce modèle de SSD sert d’illustration du format M.2 NVMe et n’est pas associé à ce code d’arrêt en particulier.
Sources : Microsoft Learn, contrôle de bogue 0x133 DPC_WATCHDOG_VIOLATION · Support Microsoft, résoudre les erreurs d’écran bleu · Microsoft Learn, dépannage avancé des erreurs d’arrêt · Microsoft Learn, Vérificateur de pilotes · Microsoft Learn, options DISM de gestion d’image · AMD, téléchargement des pilotes officiels.

Laisser un commentaire

Pin It on Pinterest