Écran bleu SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD : les solutions

Neuf fois sur dix, ce code d’arrêt vient d’un pilote qui s’est déchargé sans annuler ses opérations en attente : le noyau est ensuite allé lire l’ancienne adresse de ce pilote à un IRQL élevé, et Windows a coupé. Le nom du fichier fautif est presque toujours affiché sur l’écran bleu ou lisible dans le fichier de vidage.

Points clés

• Le code de vérification de bogue SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD porte la valeur 0x000000D4.
• Cause documentée par Microsoft : un pilote n’a pas annulé ses lookaside lists, DPC, threads de travail ou objets équivalents avant son déchargement.
• Les 4 paramètres affichés sont la mémoire référencée, l’IRQL au moment de l’accès, le sens de l’accès (0 lecture, 1 écriture) et l’adresse appelante.
• Si le pilote est identifié, son nom est stocké en mémoire dans KiBugCheckDriver et affiché à l’écran.
• La bonne piste n’est jamais un nettoyage de registre : c’est le pilote tiers installé, mis à jour ou désinstallé juste avant les premiers plantages.

Ce que veut dire le code 0xD4

Un pilote en mode noyau qui se décharge doit faire le ménage derrière lui. Il annule ses requêtes en attente, libère ses listes de mémoire rapide, arrête ses threads. Quand il oublie une de ces étapes, le code du pilote a disparu de la mémoire mais des structures pointent encore vers l’adresse qu’il occupait. Le système finit par y accéder pendant un balayage effectué à IRQL élevé, tombe sur du vide, et déclenche la vérification de bogue 0xD4 (documentation Microsoft).

C’est un cousin direct de DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS (0xCE), qui décrit le même défaut de programmation vu sous un autre angle. Autrement dit : le bug est dans un pilote, pas dans votre installation de Windows. Vous ne le corrigerez pas, vous allez identifier le pilote et le remplacer, le mettre à jour ou le retirer.

Conséquence pratique : les manipulations habituelles de dépannage Windows, du type réparation de fichiers système ou réinitialisation du profil, n’ont aucun effet ici, sauf si le pilote fautif a été installé par un composant Windows.

Les suspects les plus fréquents

• Pilotes de périphériques USB amovibles, notamment les adaptateurs Wi-Fi et les cartes de capture, qui se chargent et se déchargent à chaque branchement.
• Pilotes filtre : antivirus, chiffrement de disque, outils de sauvegarde, VPN, pare-feu applicatifs.
• Pilotes de virtualisation et d’émulation de lecteur (montage d’images disque).
• Utilitaires de contrôle matériel : ventilateurs, éclairage RGB, overclocking, macros de souris et clavier.
• Restes d’un pilote désinstallé proprement dans l’interface mais toujours présent dans la base de pilotes.

Le point commun de cette liste : ce sont des pilotes qui sont chargés et déchargés en cours de session, contrairement au pilote de stockage qui reste en place du démarrage à l’arrêt. Un plantage 0xD4 qui survient au moment où vous débranchez un périphérique, fermez un logiciel ou basculez un profil matériel pointe donc presque toujours vers ce périphérique ou ce logiciel.

Solution 1 : lire le nom du pilote sur l’écran bleu

Sur Windows 10 et 11, l’écran bleu affiche une ligne du type « Ce qui a échoué : nomdupilote.sys » sous le code d’arrêt. Photographiez l’écran, ou notez ce nom, avant tout redémarrage. C’est l’information la plus utile de tout le dépannage.

Si le plantage passe trop vite, allez chercher le fichier de vidage. Vérifiez d’abord que Windows en produit un : Paramètres système avancés, section Démarrage et récupération, puis Vidage de la mémoire du noyau. Microsoft détaille la configuration attendue dans sa procédure de génération de vidage. Le fichier se trouve ensuite dans C:\Windows\MEMORY.DMP ou dans C:\Windows\Minidump.

Pour ouvrir ce fichier, WinDbg suffit : il fait partie des outils de débogage pour Windows distribués par Microsoft. La commande !analyze -v affiche le module suspect. Vous n’avez pas besoin de comprendre la pile d’appels, juste de relever le nom du .sys.

Solution 2 : reculer d’une version de pilote

Une fois le fichier identifié, ouvrez le Gestionnaire de périphériques, trouvez le périphérique concerné, onglet Pilote, bouton Version précédente. Ce bouton n’est actif que si Windows a conservé la version antérieure. S’il est grisé, désinstallez le pilote en cochant la suppression du logiciel de pilote, puis installez la version précédente téléchargée sur le site du fabricant du composant.

Prenez la version publiée par le constructeur du matériel, pas celle d’un site agrégateur. Notre méthode complète pour mettre à jour les pilotes sous Windows 11 sans logiciel tiers évite au passage les paquets remaniés qui ajoutent leur propre pilote filtre.

Solution 3 : désinstaller le logiciel qui embarque le pilote

Beaucoup de pilotes filtres n’apparaissent pas comme périphérique. Ils arrivent avec une suite logicielle et repartent avec elle. Antivirus tiers, client VPN, outil de sauvegarde, logiciel de gravure : désinstallez le programme complet depuis Applications installées, redémarrez, et laissez tourner la machine une journée dans les conditions qui provoquaient le plantage.

Un détail à connaître pour les antivirus : sur Windows 10 et 11 grand public, quand un antivirus tiers est actif, Microsoft Defender bascule en mode désactivé, pas en mode passif. Retirer l’antivirus tiers réactive donc Defender sans intervention.

Solution 4 : nettoyer les pilotes fantômes de la base de pilotes

Un pilote désinstallé peut rester dans la banque de pilotes de Windows et se réinstaller au branchement suivant. Ouvrez une invite de commandes en administrateur et listez les paquets tiers :

pnputil /enum-drivers

Repérez le paquet dont le nom de fichier d’origine correspond au .sys fautif, puis retirez-le avec son identifiant oemXX.inf :

pnputil /delete-driver oem23.inf /uninstall /force

Ne supprimez que le paquet identifié. Retirer au hasard des paquets de stockage ou de chipset peut rendre la machine non démarrable, et vous obligerait à passer par l’environnement de récupération Windows pour revenir en arrière.

Analyser le vidage : ce que vous cherchez dans le crash dump

Un fichier de vidage n’a rien d’illisible quand on sait quelles trois informations relever. Ouvrez le fichier .dmp dans WinDbg, laissez le chargement des symboles se terminer, puis tapez !analyze -v. Le résultat de l’analyse tient sur trois lignes utiles.

• Module name et image name : le nom du pilote .sys mis en cause par l’analyse. C’est la seule information réellement décisive.
• Bug check et paramètres : le code 0xD4 suivi de ses quatre valeurs, souvent affichées sous la forme d’adresses en fffff. Le deuxième paramètre donne l’IRQL du moment.
• Process name : le processus actif lors du crash, utile quand un logiciel précis déclenche le déchargement du pilote.

Les adresses n’ont pas besoin d’être interprétées. Un type de vidage réduit, le minidump, suffit pour ce diagnostic ; le vidage du noyau apporte plus de contexte quand l’analyse ne nomme aucun module et renvoie un composant Windows générique comme ntoskrnl.exe.

Si l’analyse échoue faute de symboles, vérifiez que le chemin de symboles publics de Microsoft est configuré dans WinDbg. Sans symboles, le débogueur affiche des noms de fonctions absents et n’attribue le problème à aucun pilote.

Deux limites à connaître. Un pilote graphique peut apparaître comme module fautif alors qu’il n’était que la victime, notamment sur les cartes Nvidia dont le pilote occupe une large part de la mémoire noyau. Et une mémoire RAM instable produit des analyses qui désignent un module différent à chaque plantage : dans ce cas, les erreurs viennent du matériel, pas des drivers.

Solution 5 : faire parler le coupable avec le Vérificateur de pilotes

Quand aucun nom ne sort du vidage, le Vérificateur de pilotes force le pilote fautif à planter immédiatement, avec un code plus précis, au lieu de laisser le système planter plus tard sur un 0xD4. C’est un outil de développeur que Microsoft documente pour ce genre de diagnostic dans la page Driver Verifier.

Sélectionnez uniquement les pilotes non signés par Microsoft, jamais tous les pilotes. La syntaxe en ligne de commande permet d’activer une sélection précise :

verifier /standard /driver monpilote.sys

Avant de lancer l’outil, créez un point de restauration et vérifiez que vous savez démarrer en mode sans échec. Si la machine ne démarre plus, le mode sans échec permet de tout désactiver avec verifier /reset. Le plantage provoqué porte souvent le code 0xC4, dont les paramètres nomment directement la règle violée.

Quand ça ne vient pas d’un pilote tiers

Trois cas de figure sortent du scénario classique.

• Mémoire instable. Une barrette défaillante produit des adresses invalides dans n’importe quel contexte, y compris pendant un déchargement de pilote. Passez d’abord un test mémoire complet si les codes d’arrêt changent d’un plantage à l’autre.
• Fichiers système altérés. Lancez sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth. Microsoft décrit la procédure dans sa page sur le Vérificateur des fichiers système.
• Mise à jour de Windows récente. Si les plantages ont commencé juste après une mise à niveau, un pilote ancien peut être devenu incompatible. La désinstallation de la mise à jour n’est qu’un test : la vraie correction reste le pilote à jour.

Si les codes d’arrêt varient sans logique apparente, la méthode générale de tri est décrite dans notre guide des écrans bleus Windows 10 et 11, qui liste les codes par famille.

Ordre de traitement recommandé

1. Relever le nom du pilote sur l’écran bleu ou dans le minidump.
2. Revenir à la version précédente de ce pilote.
3. Désinstaller le logiciel qui l’installe, s’il s’agit d’un pilote filtre.
4. Purger le paquet correspondant avec pnputil.
5. Vérificateur de pilotes en dernier recours, sur les pilotes non Microsoft seulement.

Aucune de ces étapes n’efface vos données. La réinstallation de Windows n’a d’intérêt que si le pilote est réinstallé automatiquement par un logiciel impossible à désinstaller, ce qui est rare.

Questions fréquentes

Le code 0xD4 signifie-t-il que mon matériel est mort ?

Non. Microsoft attribue ce code à un défaut de déchargement de pilote, donc à du logiciel. Le matériel n’entre en jeu que si la mémoire est instable et fabrique des adresses invalides, ce que le test mémoire tranche en une passe.

Quelle différence avec l’erreur 0xCE ?

Les deux codes décrivent un pilote déchargé sans avoir annulé son travail en cours. Le 0xD4 est déclenché lors d’un balayage système à IRQL élevé, le 0xCE lors de l’accès direct au code disparu. La démarche de dépannage est identique.

Faut-il désactiver la mémoire virtuelle pour obtenir un vidage ?

Non, c’est l’inverse. Un vidage du noyau a besoin d’un fichier d’échange actif sur le volume système. Si vous l’avez désactivé, remettez une gestion automatique le temps du diagnostic.

Le Vérificateur de pilotes peut-il empêcher Windows de démarrer ?

Oui, c’est même son mode de fonctionnement quand un pilote chargé au démarrage viole une règle. Prévoyez un accès au mode sans échec avant de l’activer, et tapez verifier /reset pour tout annuler.

Un écran bleu unique justifie-t-il ce dépannage ?

Un plantage isolé après un branchement inhabituel peut rester sans suite. Deux occurrences ou plus sur la même semaine méritent le relevé du nom du pilote, parce que le déclencheur est reproductible par nature.

_{Photo d’en-tete : ecran bleu Windows photographie par Oleg Yunakov, licence CC BY-SA 4.0. Le code affiche sur la photo n’est pas le 0xD4 : elle illustre un ecran bleu attribue a un fichier de pilote. Sources : Microsoft Learn, vérification de bogue 0xD4 ; vérification de bogue 0xCE ; Driver Verifier ; génération d’un vidage de mémoire ; Support Microsoft, résoudre les erreurs d’écran bleu. Consulté le 12 septembre 2026.}