Écran bleu ATTEMPTED_WRITE_TO_READONLY_MEMORY : les solutions

ATTEMPTED_WRITE_TO_READONLY_MEMORY est l’un des rares codes d’arrêt qui désigne son coupable sans ambiguïté : un pilote. Microsoft le décrit en une phrase, « cette opération est émise si un pilote tente d’écrire dans un segment de mémoire en lecture seule », et lui attribue la valeur 0x000000BE.

Points clés

• Code d’arrêt : ATTEMPTED_WRITE_TO_READONLY_MEMORY, valeur 0x000000BE.
• La cause est un pilote en mode noyau, jamais une application classique et jamais une barrette de mémoire défectueuse.
• Quand le pilote responsable est identifiable, son nom est affiché sur l’écran bleu et conservé en mémoire par Windows.
• La démarche : lire le nom du fichier, désinstaller proprement ce pilote, et si rien n’est nommé, faire parler le Vérificateur de pilotes puis le fichier de vidage.

Ce que le code 0xBE dit exactement

Windows marque certaines zones de mémoire en lecture seule : le code du noyau, des tables de correspondance, des pages partagées entre plusieurs processus. Un pilote qui écrit dans une de ces zones fait une opération interdite par nature, parce que le contenu pourrait servir à autre chose au même instant. Le noyau refuse et arrête la machine plutôt que de laisser passer une corruption silencieuse.

La documentation Microsoft détaille les quatre paramètres affichés :

• Paramètre 1 : adresse virtuelle de la tentative d’écriture.
• Paramètre 2 : contenu de l’entrée de table de page correspondante.
• Paramètres 3 et 4 : réservés.

Point décisif du dépannage, toujours selon Microsoft : si le pilote fautif peut être identifié, son nom est imprimé sur l’écran bleu et stocké en mémoire à l’emplacement KiBugCheckDriver. Autrement dit, la ligne qui suit le code d’arrêt vaut plus que tous les tests matériels du monde. Notez-la, même partiellement.

Solution 1 : identifier le pilote nommé sur l’écran bleu

Le nom se présente sous la forme d’un fichier en .sys. Quelques familles courantes :

• Cartes graphiques : nvlddmkm.sys, amdkmdag.sys, igdkmd64.sys.
• Réseau et Wi-Fi : netwtw, rt640x64.sys, athw8x.sys.
• Audio : rtkvhd64.sys.
• Outils de sécurité et logiciels de virtualisation, qui chargent presque tous un composant noyau.

Si l’écran est passé trop vite, le nom se retrouve dans le fichier de vidage minimal, dans C:\Windows\Minidump. Sur un poste où l’écran bleu se répète, une simple recherche du nom trouvé dans ce dossier suffit à orienter le reste du travail.

Solution 2 : désinstaller proprement le pilote fautif

Une mise à jour par dessus une installation déjà bancale ne règle rien. La désinstallation propre se fait en trois temps.

1. Démarrer en mode sans échec. Le pilote tiers n’est pas chargé, la machine reste stable le temps de la manipulation. La procédure complète est décrite dans notre article sur le mode sans échec sous Windows 11.
2. Supprimer le périphérique et son pilote. Gestionnaire de périphériques, clic droit sur le matériel concerné, « Désinstaller l’appareil », puis cocher la case qui supprime aussi le logiciel du pilote. Cette case est le point important : sans elle, Windows réinstalle exactement le même fichier au redémarrage.
3. Redémarrer, puis installer la version officielle récupérée sur le site du fabricant du composant ou du constructeur de la machine. Pas une version « pilote universel » trouvée ailleurs.

Si les plantages ont commencé juste après une mise à jour, faites l’inverse : onglet Pilote des propriétés du périphérique, bouton « Version précédente ». C’est plus rapide et réversible.

Solution 3 : revenir à un point de restauration

Quand la panne date d’un changement récent mais que le pilote responsable reste flou, la restauration système ramène les pilotes et le registre à leur état antérieur sans toucher aux documents. Cette option se trouve aussi dans l’environnement de récupération, accessible après trois échecs de démarrage consécutifs.

La création des points, leur restauration et les raisons pour lesquelles la liste apparaît souvent vide sont détaillées dans notre article sur le point de restauration Windows 11.

Sauvegarder avant de manipuler

Un BSOD 0xBE ne détruit pas les données par lui-même : le noyau s’arrête justement pour éviter la corruption. Le risque vient des manipulations qui suivent, en particulier la restauration système et la réinstallation.

Avant de démarrer sur un support d’installation ou d’entrer dans le menu de récupération, copiez les dossiers de travail sur un disque externe ou une clé USB. Sur un ordinateur portable qui ne démarre plus du tout, sortir le disque et le lire depuis une autre machine avec un boîtier externe reste la méthode la plus simple pour récupérer les fichiers, et évite d’avoir à chercher un logiciel de réparation dont l’utilité sur ce code d’arrêt est nulle.

Aucun utilitaire commercial ne corrige un pilote qui écrit dans une page en lecture seule. Les seules méthodes qui fonctionnent sont celles décrites ici : identifier le fichier, le désinstaller, le remplacer par la version officielle du constructeur.

Solution 4 : faire parler le Vérificateur de pilotes

Aucun nom sur l’écran bleu, aucun changement récent identifié ? Le Vérificateur de pilotes est l’outil prévu pour ça. Il surveille les pilotes en mode noyau en temps réel et détecte les appels de fonction non conformes, ce qui provoque un arrêt immédiat et nommé au lieu d’un plantage aléatoire quelques heures plus tard.

Microsoft précise deux choses avant de commencer. L’outil est déjà présent dans %WinDir%\system32 sous le nom Verifier.exe et n’est distribué dans aucun paquet à télécharger. Et surtout, son exécution peut provoquer le blocage de l’ordinateur : Microsoft recommande de ne l’utiliser que sur des machines de test et de débogage.

La procédure sur un poste dont on accepte l’instabilité temporaire :

1. Créer un point de restauration, puis lancer verifier depuis une invite de commandes en administrateur.
2. Choisir « Créer des paramètres personnalisés », puis sélectionner les vérifications standard.
3. Choisir « Sélectionner automatiquement les pilotes non signés » ou, mieux, désigner à la main les pilotes tiers suspects. Ne jamais activer la vérification sur tous les pilotes en même temps : la machine ne démarrera peut-être plus.
4. Redémarrer et travailler normalement. Au prochain arrêt, le nom du module fautif apparaît.
5. Désactiver l’outil dès l’identification, avec verifier /reset puis un redémarrage.

Si la machine ne redémarre plus après activation, le mode sans échec permet toujours d’exécuter verifier /reset.

Solution 5 : lire le fichier de vidage avec WinDbg

C’est la méthode qui donne une réponse ferme. Windows écrit un vidage à chaque écran bleu, dans C:\Windows\Minidump pour le vidage minimal. Microsoft documente les différents types de fichiers de vidage et leur emplacement.

WinDbg s’installe depuis le Microsoft Store ou avec le kit de pilotes Windows. Une fois le fichier ouvert, la commande !analyze -v lance l’analyse automatique. Le champ à lire s’appelle MODULE_NAME ou IMAGE_NAME : il contient le fichier .sys à traiter. Sur un 0xBE, cette analyse aboutit dans la grande majorité des cas, parce que la pile d’appels au moment de l’écriture interdite est courte et lisible.

Les codes d’arrêt voisins se lisent avec les mêmes outils. Voir notamment l’écran bleu ntoskrnl.exe, qui nomme le noyau lui-même alors que le fautif est presque toujours un pilote tiers, et SYSTEM_SERVICE_EXCEPTION, dont la démarche est très proche.

Solution 6 : les vérifications système, en appui

Deux commandes utiles quand un fichier de pilote a été partiellement écrasé, dans une invite de commandes en administrateur :

• sfc /scannow, détaillé dans notre article sur sfc /scannow, remplace les fichiers système protégés qui ne correspondent plus à leur référence.
• DISM /Online /Cleanup-Image /RestoreHealth répare l’image de référence quand la commande précédente échoue.

Ces deux commandes ne touchent pas les pilotes tiers. Elles servent à écarter une corruption du magasin de composants, pas à régler le problème de fond.

Quand ça ne vient pas de là

Trois situations sortent du cadre habituel.

L’écran bleu survient pendant l’installation de Windows. Le pilote de stockage fourni sur le support d’installation est alors souvent en cause. Récupérer les pilotes de chipset et de contrôleur SATA ou NVMe sur le site du constructeur et les charger pendant l’installation résout la plupart de ces cas.

Le code change d’un plantage à l’autre. Un 0xBE qui alterne avec un DRIVER_POWER_STATE_FAILURE ou d’autres codes mémoire penche vers un défaut matériel ou une corruption plus large. Dans ce cas, le diagnostic mémoire et le contrôle du disque reprennent leur place.

Aucun pilote tiers récent, aucun matériel ajouté. Vérifiez les logiciels qui chargent un composant noyau sans être des pilotes de périphérique : outils de sécurité, machines virtuelles, utilitaires de surveillance de température, logiciels anti-triche de jeux. Ils s’installent sans passer par le Gestionnaire de périphériques et échappent donc à l’inventaire visuel.

La réinstallation de Windows reste la dernière option. Elle règle réellement un 0xBE causé par un pilote, puisqu’elle repart d’un jeu de pilotes propre, mais elle coûte une journée pour un résultat qu’une désinstallation ciblée obtient en vingt minutes. Pour une vue d’ensemble des autres codes d’arrêt, le guide des écrans bleus Windows 10 et 11 renvoie vers chaque code traité sur le site.

Questions fréquentes

Ma mémoire RAM est-elle en cause ?

Non, malgré le mot « memory » dans le nom du code. 0xBE désigne une écriture interdite dans une zone protégée, pas une puce défaillante. Un test mémoire propre ne fera donc pas disparaître le problème.

Comment retrouver le nom du pilote si l’écran est passé trop vite ?

Il est conservé dans le fichier de vidage, sous C:\Windows\Minidump. Ouvrez le fichier le plus récent avec WinDbg et lancez !analyze -v. Le module fautif apparaît dans les premières lignes du rapport.

Le Vérificateur de pilotes est-il risqué ?

Il peut rendre la machine instable, Microsoft le dit explicitement. Créez un point de restauration avant, n’activez la vérification que sur quelques pilotes à la fois, et gardez en tête que le mode sans échec permet toujours de le désactiver avec verifier /reset.

Faut-il désinstaller Windows Update pour régler l’erreur ?

Pas la mise à jour du système en général. En revanche, si le plantage a commencé après une mise à jour cumulative qui a livré un nouveau pilote, désinstaller cette mise à jour précise depuis l’historique des mises à jour est une piste légitime, à faire avant les manipulations plus lourdes.

Le problème peut-il venir d’un périphérique USB ?

Oui, indirectement. Un dock, une carte son externe ou un adaptateur réseau USB installe son propre pilote noyau. Débrancher tous les périphériques non indispensables pendant une journée est un test rapide qui ne coûte rien.

_{Photo d’en-tête : écran bleu Windows nommant un fichier de pilote, par Oleg Yunakov, licence CC BY-SA 4.0, via Wikimedia Commons. Le code d’arrêt visible sur la photo est celui d’un autre plantage, pas ATTEMPTED_WRITE_TO_READONLY_MEMORY.
Sources : Microsoft Learn, vérification de bogue 0xBE ATTEMPTED_WRITE_TO_READONLY_MEMORY ·
Microsoft Learn, vérificateur de pilotes ·
Microsoft Learn, fichiers de vidage sur incident ·
Microsoft Learn, débuter avec WinDbg ·
Microsoft Support, résoudre les erreurs d’écran bleu}