Le code d’arrêt DRIVER_VERIFIER_DETECTED_VIOLATION apparaît presque toujours après l’activation du Vérificateur de pilotes de Windows, l’outil qui fait planter volontairement la machine dès qu’un pilote en mode noyau se comporte mal. Neuf fois sur dix, la sortie de crise consiste à désactiver le vérificateur, puis à remplacer le pilote qu’il a dénoncé.
Points clés
- Le code vaut 0x000000C4. C’est le code générique des erreurs irrécupérables détectées par le Vérificateur de pilotes.
- Le paramètre 1 affiché dans l’écran bleu identifie le type de violation, les trois autres paramètres dépendent de lui.
- La commande verifier /reset efface tous les réglages du vérificateur. Après redémarrage, plus aucun pilote n’est surveillé.
- Microsoft réserve cet outil aux machines de test et de débogage, parce qu’il provoque des blocages par conception.
- Si le vérificateur n’a jamais été activé manuellement, le fautif est en général un pilote tiers récent, pas Windows.
Ce que fait réellement le Vérificateur de pilotes
Driver Verifier surveille en temps réel les pilotes en mode noyau et les pilotes graphiques. Il soumet chaque pilote sélectionné à des tests de contrainte, détecte les appels de fonction non conformes, puis déclenche un écran bleu à la première infraction. L’objectif n’est pas de protéger le système en production. Il est de rendre visible, tout de suite, une faute qui passerait autrement inaperçue pendant des semaines.
Cette logique explique le symptôme classique. Un utilisateur active le vérificateur pour diagnostiquer des plantages aléatoires, redémarre, et la machine tombe désormais en boucle sur 0xC4. Le vérificateur fonctionne. Il a trouvé son coupable, et il refuse de laisser le pilote continuer.
Les causes du code 0xC4
- Un pilote tiers défaillant : pilote graphique, pilote réseau, antivirus ou logiciel de virtualisation qui installe son propre filtre noyau.
- Un pilote ancien conçu pour une version antérieure de Windows et jamais recompilé.
- Le vérificateur laissé activé après une session de diagnostic, avec l’option de persistance par défaut qui le maintient à chaque démarrage.
- Un test trop agressif : la simulation de ressources faibles fait échouer volontairement des allocations mémoire, avec une probabilité par défaut de 600 sur 10 000, soit 6 %. Beaucoup de pilotes ne survivent pas à ce régime.
- Une mémoire vive instable qui amplifie les violations détectées sans en être la cause première.
Lire le paramètre 1 avant de toucher à quoi que ce soit
Le paramètre 1 de l’écran bleu oriente le diagnostic bien plus vite qu’une réinstallation à l’aveugle. Quelques valeurs documentées par Microsoft :
- 0x00 : le pilote a demandé une allocation de pool de zéro octet.
- 0x01 : allocation de mémoire paginée à un niveau IRQL supérieur à APC_LEVEL.
- 0x02 : allocation de mémoire non paginée à un IRQL supérieur à DISPATCH_LEVEL.
- 0x13 et 0x14 : libération d’un bloc mémoire déjà libéré.
- 0x30 et 0x31 : paramètre non valide transmis à KeRaiseIrql ou KeLowerIrql.
Ces informations sont techniques, mais une seule chose compte pour un dépannage : la violation vient du pilote nommé dans le vidage mémoire, pas du noyau qui la signale.
Les solutions, de la moins risquée à la plus lourde
1. Désactiver le Vérificateur de pilotes
Ouvrir une invite de commandes en administrateur, taper verifier /reset, puis redémarrer. Tous les réglages sont effacés et plus aucun pilote n’est vérifié au démarrage suivant. Si la machine démarre encore normalement, c’est l’action à faire en premier.
2. Passer par le mode sans échec quand Windows ne démarre plus
En boucle d’écran bleu, Windows bascule au bout de plusieurs échecs dans l’environnement de récupération. De là, il faut atteindre les options de démarrage avancées, choisir le mode sans échec avec invite de commandes, puis lancer verifier /reset. La commande fonctionne aussi depuis l’invite de commandes de l’environnement de récupération lorsque le registre du système installé est accessible.
3. Vérifier ce que le vérificateur surveille encore
La commande verifier /query affiche les statistiques en cours, verifier /querysettings liste les pilotes et les options actives. Utile pour confirmer que la réinitialisation a bien pris, ou pour repérer un pilote ciblé qu’on avait oublié.
4. Identifier le pilote fautif dans le vidage mémoire
Les fichiers de vidage se trouvent dans C:\Windows\Minidump. Ouverts dans WinDbg, la commande !analyze -v donne le module mis en cause. Un nom de fichier .sys inconnu pointe presque toujours vers un périphérique tiers récemment installé. Cette étape évite de désinstaller trois pilotes sains avant d’atteindre le bon.
5. Mettre à jour ou désinstaller le pilote incriminé
Le pilote doit venir du site du fabricant du composant ou de l’ordinateur, pas d’un utilitaire de mise à jour automatique. En cas de doute, la désinstallation complète depuis le Gestionnaire de périphériques, avec la case de suppression du logiciel du pilote, remet le périphérique sur un pilote générique Windows. Un périphérique qui fonctionne en mode dégradé vaut mieux qu’une machine qui plante.
6. Revenir à un point de restauration antérieur
Si la protection du système était active, un point de restauration antérieur à l’installation du pilote annule à la fois le pilote et les réglages du vérificateur. Les documents personnels ne sont pas touchés, les logiciels installés depuis le point choisi disparaissent.
7. Relancer un test ciblé plutôt qu’un test global
Pour un diagnostic volontaire, vérifier tous les pilotes en même temps produit du bruit. La bonne méthode consiste à surveiller un seul pilote suspect, et à limiter la durée d’exposition avec l’option de démarrage adaptée. Le mode oneboot n’active le vérificateur que pour le prochain démarrage, disableafterfail le désactive si Windows ne parvient pas à démarrer. Ces deux options évitent la boucle d’écran bleu.
8. Réparer les fichiers système, en dernier recours
Les commandes sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth réparent une image Windows abîmée. Elles ne corrigent pas un pilote tiers défectueux, elles écartent seulement l’hypothèse d’un composant système corrompu avant d’envisager une réinstallation.
Quand le problème ne vient pas du vérificateur
Un 0xC4 sur une machine où personne n’a jamais lancé verifier reste possible : certains outils de diagnostic constructeur et certaines suites de sécurité activent le vérificateur en arrière-plan. Il arrive aussi que l’écran bleu change de code après la désactivation, ce qui signale un défaut matériel sous-jacent. Dans ce cas, le diagnostic repart de zéro avec un test mémoire et une analyse des plantages, décrits dans notre méthode de diagnostic des écrans bleus aléatoires.
Le guide des écrans bleus Windows 10 et 11 recense les autres codes d’arrêt. Si le vidage mémoire désigne le noyau lui-même, la lecture utile est celle de l’écran bleu ntoskrnl.exe, dont la section sur le vérificateur de pilotes complète cette page.
Questions fréquentes
Le Vérificateur de pilotes peut-il endommager Windows ?
Il ne modifie pas les fichiers système, il provoque des arrêts brutaux. Le risque réel est la perte de données non enregistrées et, à la longue, la corruption d’un fichier ouvert au moment du plantage. Microsoft précise qu’il doit être réservé aux ordinateurs de test et de débogage.
Combien de temps faut-il laisser le vérificateur activé ?
Le temps de reproduire le plantage recherché, pas davantage. Une session de diagnostic se pilote avec l’option de démarrage oneboot ou disableafterfail, qui garantissent un retour à la normale même si la machine ne démarre plus.
Faut-il des droits administrateur ?
Oui. Microsoft indique qu’il faut appartenir au groupe Administrateurs de l’ordinateur pour utiliser Driver Verifier, que ce soit par la commande ou par l’interface graphique.
Pourquoi le même pilote passe-t-il sans erreur chez quelqu’un d’autre ?
Parce que les options activées ne sont pas les mêmes. La simulation de ressources faibles, par exemple, fait échouer une allocation sur environ seize, ce qui met à genoux des pilotes parfaitement stables en usage courant.
Existe-t-il une alternative moins brutale ?
Oui, l’analyse des vidages mémoire déjà présents dans C:\Windows\Minidump. Elle ne nécessite aucun plantage supplémentaire et suffit souvent à nommer le pilote responsable.
Photo d’en-tête : Tony Webster, CC BY 2.0, via Wikimedia Commons. La photo montre un écran bleu Windows générique, pas le code 0xC4 lui-même.
Sources : Microsoft Learn, vérification de bogue 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION ; Microsoft Learn, commande verifier ; Microsoft Learn, Vérificateur de pilotes ; Microsoft Learn, gestion d’une vérification de bogue avec le vérificateur activé ; Microsoft Learn, analyser les données d’un code d’arrêt.
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
