L’écran bleu FAULTY_HARDWARE_CORRUPTED_PAGE signale que le gestionnaire de mémoire de Windows a trouvé une page mémoire corrompue, et la cause la plus fréquente est une barrette de RAM défaillante. Le code d’arrêt associé est 0x0000012B, et Microsoft le classe explicitement comme une erreur mémoire matérielle.
Points clés
- Code de vérification de bogue : 0x0000012B, nom FAULTY_HARDWARE_CORRUPTED_PAGE.
- Signification officielle : le gestionnaire de mémoire a détecté une erreur sur un seul bit dans une page qu’il attendait vierge.
- Trois causes reconnues par Microsoft : RAM défectueuse, pilote ou périphérique modifiant des pages physiques par un DMA incorrect, microprogramme qui corrompt la mémoire.
- Premier test à faire : le Diagnostic de mémoire Windows (mdsched.exe), puis un test long type MemTest86 sur plusieurs passes.
- Si les paramètres 3 et 4 du code ne sont pas nuls, le plantage vient du Gestionnaire de magasin compressé, pas d’une erreur mono-bit.
Ce code tombe rarement en pleine action. Il arrive plutôt au repos, pendant une veille, ou au retour d’une mise en veille prolongée. C’est logique : la mémoire est manipulée en masse à ces moments-là, et une cellule instable finit par renvoyer un bit faux.
Ce que Windows dit exactement quand il affiche ce code
La documentation Microsoft est nette sur un point : cette corruption ne peut venir que d’un composant qui accède à la mémoire par adressage physique. Autrement dit, le fautif contourne la couche mémoire virtuelle. Cela réduit fortement la liste des suspects.
Le code se décline en deux scénarios, distingués par ses paramètres. Quand les paramètres 3 et 4 valent zéro, le gestionnaire de mémoire a trouvé une erreur mono-bit sur une page qu’il s’apprêtait à mettre à zéro : erreur mémoire matérielle. Quand ils ne sont pas nuls, c’est le Gestionnaire de magasin compressé qui a échoué à décompresser une page, à cause d’une corruption de la mémoire physique. Le premier cas domine largement sur les machines grand public.
À noter, et c’est important pour comprendre pourquoi le plantage semble aléatoire : le Gestionnaire de magasin compressé corrige tout seul les erreurs mono-bit qu’il détecte, sans déclencher d’écran bleu. Vous ne voyez donc que la partie émergée du problème.
Solution 1 : vider la mémoire de tout soupçon avec mdsched.exe
L’outil est intégré à Windows 10 et 11. Tapez mdsched.exe dans la zone de recherche, choisissez « Redémarrer maintenant et rechercher les problèmes ». La machine redémarre dans un environnement de test avant le chargement du système.
Une passe standard dure une dizaine de minutes et attrape les défauts francs. Elle laisse passer les cellules qui ne fautent qu’à chaud ou sous charge. Si le test standard ne trouve rien alors que les écrans bleus continuent, appuyez sur F1 pendant le test pour passer en mode « Étendu » et laissez tourner plusieurs heures. Le résultat s’affiche dans une notification au retour sur le bureau, et dans l’Observateur d’événements sous la source MemoryDiagnostics-Results.
Solution 2 : isoler la barrette fautive
Un test qui échoue vous dit qu’une barrette est mauvaise, pas laquelle. Sur une tour avec deux barrettes ou plus, la méthode est mécanique : démarrez avec une seule barrette, testez, changez de barrette, testez à nouveau. Testez aussi chaque barrette dans un autre emplacement, parce que le défaut vient parfois du slot ou d’un contact encrassé, pas du module.
Sur un portable, l’accès dépend du modèle. Beaucoup de machines récentes ont une mémoire soudée : dans ce cas, le test étendu sert surtout à documenter la panne avant un passage en garantie.
Un cas très courant est passé sous silence : un profil XMP ou EXPO trop agressif rend une RAM parfaitement saine instable. Repassez la mémoire aux fréquences JEDEC par défaut dans le BIOS et relancez le test avant de commander quoi que ce soit.
Solution 3 : traquer le pilote qui écrit là où il ne faut pas
La deuxième cause listée par Microsoft est un pilote qui modifie mal des pages physiques via une opération DMA ou une MDL erronée. Les suspects habituels sont les pilotes de carte graphique, de contrôleur de stockage, de carte réseau et les pilotes fournis avec les utilitaires de réglage matériel.
Commencez par la voie simple : désinstallez proprement le pilote graphique puis réinstallez la version WHQL du fabricant, mettez à jour le chipset, et supprimez les logiciels d’overclocking ou de contrôle de ventilation installés récemment.
Si le plantage persiste, le Vérificateur de pilotes (verifier.exe) force les pilotes tiers à révéler leurs erreurs mémoire. Il fait planter la machine plus souvent, volontairement, mais le fichier de vidage désigne alors le fautif. Activez-le sur les pilotes non signés Microsoft uniquement, et prévoyez un point de restauration : la procédure est détaillée dans notre article sur les écrans bleus attribués à ntoskrnl.exe.
Solution 4 : mettre à jour le BIOS et le microprogramme
Microsoft cite le cas d’un périphérique ou d’un microprogramme qui corrompt la mémoire, par exemple en modifiant illégalement des pages physiques pendant une transition d’alimentation. Cela colle exactement aux plantages qui surviennent à la sortie de veille.
Rendez-vous sur la page support du fabricant de la carte mère ou du portable, comparez la version installée (visible avec msinfo32) à la dernière publiée, et lisez les notes de version. Les correctifs de compatibilité mémoire et de gestion d’énergie y sont fréquents. Mettez aussi à jour le microprogramme des SSD NVMe avec l’utilitaire du constructeur.
Solution 5 : désactiver la compression de mémoire pour le diagnostic
Si les paramètres 3 et 4 du code d’arrêt ne sont pas nuls, le plantage passe par le Gestionnaire de magasin compressé. Désactiver temporairement la compression mémoire ne corrige pas la cause, mais permet de savoir si les écrans bleus s’arrêtent, ce qui oriente le diagnostic vers la mémoire physique.
Dans une console PowerShell ouverte en administrateur : Disable-MMAgent -MemoryCompression, puis redémarrez. Pour revenir en arrière : Enable-MMAgent -MemoryCompression. Ne laissez pas la compression désactivée sur une machine à faible RAM, la pagination disque prendra le relais et les performances chuteront.
Solution 6 : vérifier l’intégrité du système, sans y croire trop fort
Un magasin de composants abîmé ne provoque pas ce code d’arrêt, mais un système déjà endommagé brouille les tests. Deux commandes, dans une invite en administrateur : DISM /Online /Cleanup-Image /RestoreHealth puis sfc /scannow. La marche à suivre complète et les erreurs classiques sont couvertes dans notre guide DISM /RestoreHealth.
Si ces commandes échouent avec un code du type 0x800f081f, réparez d’abord la pile de maintenance : voir l’erreur 0x80073712.
Quand ça ne vient pas de la RAM
Trois pistes restent quand la mémoire est testée bonne et les pilotes à jour.
- Alimentation instable. Une alimentation fatiguée fait fauter la mémoire sous charge. Le symptôme typique est un plantage au lancement d’un jeu ou d’un rendu, jamais au repos.
- Surchauffe du contrôleur mémoire. Sur les processeurs récents, le contrôleur mémoire est dans le CPU. Un refroidissement encrassé produit des erreurs qui ressemblent à de la RAM morte.
- Autre code d’arrêt derrière celui-ci. Si vous voyez alterner plusieurs codes mémoire, lisez aussi nos pages MEMORY_MANAGEMENT et MACHINE_CHECK_EXCEPTION, qui pointent vers le même matériel.
Tous les codes d’arrêt Windows et leur méthode de lecture sont regroupés dans notre guide des écrans bleus Windows 10 et 11.
La dernière étape : réinstaller, et pourquoi c’est presque toujours inutile ici
Réinstaller Windows est la solution la plus lourde et la moins pertinente sur ce code précis. La corruption est physique : un système neuf plantera de la même façon sur la même cellule mémoire. Ne réinstallez que si les tests mémoire sont propres sur plusieurs heures, que le BIOS est à jour, que les pilotes ont été remis à zéro, et que le plantage persiste. Sauvegardez avant.
Questions fréquentes
Est-ce que FAULTY_HARDWARE_CORRUPTED_PAGE veut toujours dire RAM morte ?
Non. C’est la cause la plus fréquente, mais Microsoft liste aussi les pilotes en DMA incorrect et les microprogrammes fautifs. Un profil mémoire overclocké entre aussi dans la catégorie « matériel instable » sans que la barrette soit défectueuse.
Le Diagnostic de mémoire Windows ne trouve rien, dois-je conclure que la RAM est bonne ?
Pas sur une seule passe standard. Les défauts intermittents demandent plusieurs heures de test étendu, à température de fonctionnement. Un test court négatif ne prouve rien.
Puis-je continuer à utiliser le PC en attendant ?
Une mémoire qui corrompt des pages peut corrompre des fichiers écrits sur le disque. Sauvegardez vos données avant toute manipulation, et évitez les travaux longs non enregistrés.
Où trouver le fichier de vidage pour analyser le plantage ?
Dans C:\Windows\Minidump. Le fichier porte la date du plantage et s’ouvre avec WinDbg, ce qui donne les quatre paramètres du code d’arrêt et le module en cause.
Faut-il remplacer les deux barrettes ou seulement la mauvaise ?
Sur un kit vendu apparié, remplacez le kit complet : mélanger deux modules de séries différentes est une source classique d’instabilité, même quand chaque module est sain pris isolément.
Photo d’en-tête : barrettes de RAM, par Wilbysuffolk, Wikimedia Commons, CC BY-SA 4.0. Les modules photographiés illustrent le type de matériel concerné, ils ne sont pas ceux d’une machine en panne.
Sources : Microsoft Learn, vérification de bogue 0x12B FAULTY_HARDWARE_CORRUPTED_PAGE · Microsoft Support, résoudre les erreurs d’écran bleu · Microsoft Learn, Vérificateur de pilotes · Microsoft Learn, vérification de bogue 0x124 WHEA_UNCORRECTABLE_ERROR
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.
