Écran bleu DRIVER_IRQL_NOT_LESS_OR_EQUAL : les solutions

DRIVER_IRQL_NOT_LESS_OR_EQUAL désigne un pilote en mode noyau qui a tenté d’accéder à de la mémoire paginable alors que le niveau d’interruption du processeur était trop élevé. Microsoft attribue à ce code d’arrêt la valeur 0x000000D1 et pointe directement les pilotes qui utilisent des adresses mémoire incorrectes.

Points clés

• Code d’arrêt 0x000000D1, le mot DRIVER en tête du libellé indique que le noyau a déjà attribué la faute à un pilote.
• Quatre paramètres accompagnent le code : mémoire référencée, IRQL au moment de l’accès, type d’opération, et adresse du code fautif.
• Le quatrième paramètre est le plus utile : il donne l’adresse à partir de laquelle le débogueur nomme la fonction, donc le module.
• Microsoft estime que trois quarts environ des erreurs de code d’arrêt viennent de pilotes défaillants.
• Le nom du fichier affiché sous « Ce qui a échoué » sur l’écran bleu est une piste, pas une conclusion.

Ce que dit le code 0x000000D1

La documentation Microsoft est explicite : une tentative d’accès a été faite vers une adresse paginable, ou totalement invalide, à un niveau de requête d’interruption trop élevé. Traduit en langage de dépannage, un pilote a voulu lire ou écrire une zone mémoire qui pouvait être sortie de la mémoire physique, à un instant où le noyau n’a pas le droit d’aller la rechercher sur le disque.

Le noyau ne peut ni satisfaire la demande ni l’ignorer. Il arrête le système. La différence avec son cousin IRQL_NOT_LESS_OR_EQUAL tient à un mot : ici, le libellé nomme le pilote comme responsable, et le code sanctionne l’accès mémoire d’un pilote identifiable, pas une condition générale du système. Autre voisin encore, IRQL_NOT_DISPATCH_LEVEL sanctionne une erreur de palier, pas un accès mémoire interdit.

Concrètement, cela réduit le champ des recherches. Sur un 0xD1, l’enquête ne porte pas sur Windows mais sur la liste des pilotes tiers de la machine, en commençant par le plus récemment installé.

Lire les quatre paramètres

Les quatre valeurs affichées après le code d’arrêt ne sont pas décoratives. Microsoft en donne la signification exacte : le paramètre 1 est la mémoire référencée, le paramètre 2 l’IRQL au moment de l’accès, le paramètre 3 le type d’opération avec 0 pour une lecture, 1 pour une écriture et 8 pour une exécution, et le paramètre 4 l’adresse qui a référencé cette mémoire.

La documentation recommande d’utiliser les paramètres 1, 3 et 4 pour l’investigation, et la commande ln du débogueur sur le paramètre 4 pour obtenir le nom de la fonction appelée. C’est cette fonction qui trahit le module fautif, et c’est la raison pour laquelle un vidage mémoire vaut mieux qu’une série de désinstallations à l’aveugle.

Vous retrouvez ces quatre paramètres sans débogueur : les propriétés de l’événement d’arrêt dans le journal Système de l’Observateur d’événements les listent, comme le rappelle Microsoft dans sa page sur les données d’écran bleu.

Solution 1 : revenir sur le dernier pilote installé

C’est la piste la plus probable et la moins risquée. Ouvrez le Gestionnaire de périphériques, repérez le matériel dont le pilote a changé récemment, propriétés puis onglet Pilote, et utilisez la restauration de la version précédente si le bouton est actif. Microsoft documente ce parcours dans sa page sur la mise à jour des pilotes via le Gestionnaire de périphériques.

Si le bouton est grisé, désinstallez le périphérique en cochant la suppression du logiciel de pilote, redémarrez et laissez Windows remettre sa version générique. Les cartes réseau sans fil, les contrôleurs de stockage et les cartes son sont les familles qui reviennent le plus souvent sur ce code.

Solution 2 : traiter le fichier .sys nommé sur l’écran bleu

Quand l’écran affiche un nom de fichier sous la ligne « Ce qui a échoué », vous avez un point de départ. Identifiez le composant auquel appartient ce pilote, puis récupérez sa version la plus récente chez le constructeur de la machine ou du composant, pas sur un site de téléchargement de pilotes.

Attention au raccourci classique : un pilote nommé n’est pas toujours coupable. Il peut être la victime d’un autre module qui a corrompu la mémoire avant lui. Si la mise à jour du fichier nommé ne change rien, ne vous acharnez pas sur lui, passez au vidage mémoire.

Solution 3 : ouvrir le vidage mémoire

Chaque écran bleu écrit un vidage. Dans une configuration par défaut, un minidump atterrit dans C:\Windows\Minidump. Ouvrez-le avec WinDbg et lancez !analyze -v : l’extension affiche l’analyse du code d’arrêt et, dans la majorité des cas, le module mis en cause.

Si le dossier est vide, la génération de vidage est probablement désactivée ou le fichier d’échange trop petit. Microsoft décrit la configuration à appliquer pour obtenir un vidage noyau ou complet exploitable. Sans vidage, un écran bleu intermittent reste une devinette.

Solution 4 : Driver Verifier, sur une machine que vous pouvez perdre

Driver Verifier est intégré à Windows et se lance en tapant verifier dans une invite de commandes. Il surveille en temps réel les pilotes en mode noyau, vérifie l’usage des ressources mémoire et provoque volontairement un arrêt sur la cause plutôt que sur l’effet. C’est exactement ce que l’on cherche quand le module fautif change d’un plantage à l’autre.

Microsoft précise de ne l’exécuter que sur des machines de test ou en cours de débogage, car le code de vérification ajoute une surcharge et provoque des arrêts. Sur un poste de production, limitez la vérification aux pilotes non signés par Microsoft, sachez démarrer en mode sans échec, et retenez la commande verifier /reset pour tout désactiver.

Solution 5 : écarter la mémoire et les réglages BIOS

Un pilote parfaitement correct peut échouer sur une mémoire qui perd des bits. Si le module accusé change à chaque plantage, la piste logicielle s’affaiblit nettement. Lancez un test mémoire complet sur plusieurs passes avant d’aller plus loin.

Remettez aussi les réglages du BIOS par défaut le temps du diagnostic : profil XMP ou EXPO, courbe de tension, overclocking processeur. Si les écrans bleus disparaissent, le coupable n’était pas un pilote mais la stabilité de la plateforme.

Solution 6 : vérifier l’intégrité du système

Si aucun changement matériel ou logiciel récent n’explique le plantage, contrôlez les fichiers système. Dans une invite de commandes administrateur, lancez sfc /scannow, puis DISM /Online /Cleanup-Image /RestoreHealth si des corruptions résistent, et relancez sfc /scannow.

Cette étape ne répare pas un pilote tiers défectueux. Elle sert à éliminer un doute, ce qui a de la valeur avant d’envisager une réinstallation.

Quand ça ne vient pas du pilote nommé

Certaines machines enchaînent des codes d’arrêt différents à chaque redémarrage. Dans ce cas, la démarche n’est plus celle d’un code isolé mais celle du guide général des écrans bleus Windows, qui trie les causes matérielles et logicielles dans l’ordre.

Pensez aussi aux couches bas niveau qui ne ressemblent pas à des pilotes : antivirus tiers, client VPN, filtre réseau, logiciel de disque virtuel, utilitaire RGB de carte mère. Toutes chargent du code en mode noyau et figurent parmi les habitués de la famille des écrans bleus liés aux pilotes, au même titre que le code qui sanctionne un déchargement de pilote incorrect.

Si l’ordinateur redémarre en boucle avant le bureau

Quand l’écran bleu revient avant l’ouverture de session, aucune des solutions ci-dessus n’est applicable en l’état. Il faut d’abord atteindre l’environnement de récupération. Après deux ou trois échecs de démarrage consécutifs, Windows y arrive de lui-même ; sinon, un support d’installation démarré au clavier ouvre la même porte.

Dans cet environnement, sélectionnez Dépannage, puis Options avancées, puis Paramètres. Le mode sans échec avec réseau permet de charger un jeu minimal de pilotes, donc de désinstaller le pilote suspect ou de lancer une restauration du système vers un point antérieur au premier plantage. La restauration du système est l’outil le plus rapide quand vous ne savez pas quel pilote a bougé.

Si l’appareil ne démarre même pas sur son disque, le problème dépasse le pilote et rejoint la famille des erreurs de démarrage : contrôleur de stockage, fichiers de configuration ou disque lui-même. Les données personnelles ne sont pas concernées par un écran bleu, mais un disque qui commence à faiblir mérite une sauvegarde immédiate.

Ce qui ne sert à rien

• Les logiciels de réparation automatique de pilotes : ils installent des versions génériques, parfois plus anciennes que celle du constructeur, et brouillent le diagnostic.
• Les utilitaires de nettoyage de registre. Aucun rapport avec un accès mémoire fautif en mode noyau.
• Réinstaller Windows avant d’avoir lu le vidage mémoire : si le pilote fautif est réinstallé ensuite, le problème revient.
• Changer la barrette de mémoire au hasard sans test préalable sur plusieurs passes.

En dernier recours

La réinitialisation de Windows en conservant les fichiers personnels règle les cas où un pilote résiduel refuse de disparaître. Elle réinstalle le système et supprime les applications installées, donc sauvegardez d’abord. Les options et leurs conséquences sont décrites par Microsoft dans sa page sur les options de récupération.

Questions fréquentes

Quelle différence avec IRQL_NOT_LESS_OR_EQUAL ?

Les deux codes relèvent de la même mécanique d’IRQL, mais 0x000000D1 nomme le pilote dans son libellé et correspond à un accès mémoire fautif attribuable à un module en mode noyau. La démarche se ressemble, l’entrée en matière change : sur un 0xD1, commencez par la liste des pilotes tiers.

Le fichier .sys affiché est-il forcément le coupable ?

Non. Il indique où le système s’est arrêté, ce qui n’est pas toujours l’origine du problème. Un module peut corrompre la mémoire et laisser un autre déclencher l’arrêt. Le vidage mémoire tranche.

Une carte Wi-Fi peut-elle provoquer ce code ?

Oui, les pilotes de cartes réseau sans fil font partie des familles les plus souvent citées sur ce type d’arrêt. Récupérez le pilote chez le fabricant de la carte ou de l’ordinateur, et testez la version précédente si la dernière est récente.

Faut-il installer WinDbg pour s’en sortir ?

Pas toujours. Si un pilote a été installé la veille du premier plantage, la restauration de la version précédente suffit souvent. Le débogueur devient nécessaire quand rien n’a changé ou quand les plantages sont irréguliers.

Ce code peut-il venir d’une mise à jour Windows ?

Indirectement, oui : une mise à jour peut livrer une nouvelle version de pilote. Restaurez la version précédente, puis empêchez sa réinstallation automatique le temps qu’une version corrigée sorte.

_{Photo d’en-tete : ecran bleu Windows 10 photographie par Snoopy1964, Wikimedia Commons, licence CC BY-SA 4.0. La photo montre un ecran bleu generique, pas ce code d’arret precis.}

Sources : Microsoft Learn, Bug Check 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL ; Microsoft Learn, analyser les données de code d’arrêt ; Microsoft Learn, vérificateur de pilotes ; Microsoft, générer un vidage mémoire ; Microsoft, mettre à jour les pilotes via le Gestionnaire de périphériques ; Microsoft, options de récupération dans Windows. Consultées le 13 septembre 2026.