Écran bleu MACHINE_CHECK_EXCEPTION : les solutions

Un poste qui s’arrête sur MACHINE_CHECK_EXCEPTION signale presque toujours une défaillance signalée par le processeur lui-même, pas un fichier Windows abîmé. Dans la grande majorité des cas mesurés en atelier de dépannage, la piste utile se trouve du côté du matériel : mémoire instable, overclocking, chauffe ou alimentation qui décroche.

Points clés

• MACHINE_CHECK_EXCEPTION est le code d’arrêt 0x0000009C, déclenché quand une exception de vérification machine fatale remonte du processeur.
• Depuis Windows Vista, ce code ne subsiste que dans des cas très étroits : la plupart des exceptions du même type sortent désormais sous 0x00000124 WHEA_UNCORRECTABLE_ERROR.
• Microsoft rattache ce type d’arrêt à des défaillances physiques : chaleur, mémoire défectueuse, processeur qui commence à lâcher.
• Premier geste concret : désactiver tout overclocking et revenir aux réglages par défaut du BIOS ou de l’UEFI.
• Sur l’ensemble des codes d’arrêt Windows, Microsoft attribue 10 % des plantages au matériel et 70 % à du code de pilote tiers : le second scénario reste à écarter avant de démonter la machine.

Ce que dit exactement le code 0x9C

La documentation destinée aux développeurs de pilotes est claire sur le périmètre. Le code d’arrêt 0x0000009C indique qu’une exception de vérification machine fatale s’est produite, et il n’apparaît plus que dans deux situations : l’architecture WHEA n’est pas complètement initialisée, ou aucun des processeurs qui se synchronisent ne porte d’erreur dans ses registres. Toutes les autres exceptions de ce type passent par le code 0x00000124.

Concrètement, un écran bleu MACHINE_CHECK_EXCEPTION survient souvent tôt : pendant l’amorçage, juste après la fin de l’initialisation matérielle, ou sur une machine dont le firmware vient d’être modifié. Un poste qui plante plus tard, en pleine session, affichera plutôt WHEA_UNCORRECTABLE_ERROR. Les deux se traitent de la même façon, puisqu’ils viennent du même mécanisme de remontée d’erreur processeur.

Les causes matérielles, dans l’ordre de fréquence

Microsoft associe l’exception de vérification machine à des pannes physiques : problème de chaleur, matériel défectueux, mémoire abîmée, voire un processeur en fin de vie. La documentation ajoute deux consignes directes : désactiver l’overclocking s’il est actif, et vérifier que les systèmes de refroidissement fonctionnent.

• Overclocking ou profil mémoire trop agressif. Un profil XMP ou EXPO instable produit exactement ce symptôme, y compris des mois après avoir été activé sans incident.
• Mémoire vive défaillante. Un module qui se dégrade génère des erreurs non corrigibles que le processeur signale au noyau.
• Chauffe. Ventilateur encrassé, pâte thermique sèche, radiateur mal plaqué sur le socket.
• Alimentation qui décroche. Une tension qui s’effondre sous charge se traduit par des arrêts brutaux sans logique apparente.
• Firmware ancien. Sur les plateformes récentes, une version de BIOS obsolète face à un processeur récent provoque des instabilités de ce type.

1. Retirer l’overclocking et les profils mémoire

C’est la manipulation la moins risquée et la plus rentable. Entrez dans le BIOS ou l’UEFI au démarrage, chargez les réglages par défaut, puis désactivez explicitement le profil mémoire XMP ou EXPO. Si la machine tient plusieurs jours sans arrêt, la cause est là : le profil vendu comme certifié n’était pas stable sur ce couple carte mère et processeur.

Le même raisonnement vaut pour les utilitaires constructeur qui appliquent un mode « performance » au démarrage de Windows. Désinstallez-les le temps du diagnostic.

2. Tester la mémoire vive

Windows embarque le Diagnostic de mémoire Windows, accessible par Windows + R puis mdsched.exe. Le poste redémarre et lance une série de tests avant le chargement du système. Le résultat s’affiche à l’ouverture de session, et le journal détaillé se trouve dans l’Observateur d’événements sous la source MemoryDiagnostics-Results.

Un test qui passe ne prouve rien de définitif sur une erreur intermittente. La méthode la plus fiable reste physique : retirer tous les modules sauf un, faire tourner la machine, puis alterner. Si l’arrêt suit un module précis, la conclusion est immédiate.

3. Vérifier la température et le refroidissement

Ouvrez le boîtier, regardez l’état réel des ventilateurs et du radiateur du processeur. Une couche de poussière compacte sur les ailettes suffit à faire monter la température au point de déclencher les protections. Sur un portable, les grilles d’aération obstruées produisent le même résultat, avec en plus des arrêts qui arrivent toujours pendant les charges lourdes.

Un indice utile : si le plantage n’arrive que lors des jeux, des exports vidéo ou des compilations, la piste thermique et la piste alimentation passent devant tout le reste.

4. Mettre à jour les pilotes et le firmware par les canaux officiels

Microsoft recommande de passer d’abord par Windows Update pour récupérer les pilotes, puis de mettre à jour manuellement le pilote du périphérique désigné si l’écran bleu en nomme un. Cette étape n’est pas un détail dans un dossier matériel : un pilote de chipset ou de gestion d’énergie peut mal piloter des composants parfaitement sains.

Côté firmware, récupérez la version du BIOS ou de l’UEFI sur le site du fabricant de la carte mère ou du portable, jamais sur un site de téléchargement tiers. Une mise à jour de firmware interrompue laisse une machine morte, donc branchement secteur obligatoire et pas de manipulation pendant l’opération.

5. Lire le fichier de vidage pour cibler le composant

Chaque arrêt écrit un vidage mémoire dans C:\Windows\Minidump. Les paramètres du code 0x124 contiennent l’adresse de la structure d’enregistrement d’erreur WHEA et les 32 bits hauts puis bas du registre MCi_STATUS de la banque qui a détecté l’erreur. C’est ce registre qui dit si l’erreur vient d’un cache, d’un bus ou du contrôleur mémoire.

Cette lecture demande les outils de débogage Windows. Sur un poste de particulier, on s’en passe la plupart du temps : la séquence overclocking, mémoire, thermique, alimentation résout l’essentiel des cas sans jamais ouvrir un débogueur.

6. Écarter la piste logicielle avant de remplacer une pièce

Avant d’acheter un composant, il faut prouver que Windows n’est pas en cause. Trois vérifications suffisent :

• Démarrer en mode sans échec et regarder si le poste tient. Un environnement réduit qui reste stable pointe vers un pilote tiers.
• Lancer sfc /scannow pour écarter des fichiers système abîmés par les arrêts brutaux répétés.
• Revenir à un point de restauration antérieur si les plantages ont commencé après une mise à jour ou l’installation d’un logiciel.

Ces trois gestes ne réparent pas une barrette morte. Ils évitent de remplacer du matériel sain.

Quand ça ne vient pas du processeur

Un écran bleu unique après une coupure de courant ne mérite pas un démontage. Ce qui compte, c’est la répétition et le contexte. Si le code change d’un arrêt à l’autre, la piste matérielle se renforce nettement : une mémoire instable produit indifféremment des codes comme PFN_LIST_CORRUPT ou KERNEL_SECURITY_CHECK_FAILURE.

À l’inverse, un code identique à chaque fois, toujours dans la même application, ramène vers un pilote précis. Le guide des écrans bleus Windows répertorie les codes par famille et permet de vérifier dans quelle catégorie tombe le vôtre.

Questions fréquentes

MACHINE_CHECK_EXCEPTION signifie-t-il que le processeur est mort ?

Non. Le processeur est celui qui signale l’erreur, pas forcément celui qui la produit. La mémoire, l’alimentation et la chauffe arrivent bien avant un processeur défectueux dans les causes réelles.

Quelle différence avec WHEA_UNCORRECTABLE_ERROR ?

Les deux codes viennent du même mécanisme. Depuis Windows Vista, 0x9C est réservé à des situations où WHEA n’est pas encore initialisée ou où aucun registre processeur ne porte d’erreur ; le reste sort sous 0x124. La démarche de diagnostic est identique.

Une réinstallation de Windows peut-elle régler le problème ?

Rarement, et c’est la mauvaise porte d’entrée. Une exception de vérification machine ne se corrige pas en réécrivant le système. Si les tests matériels sont propres et que seul un pilote tiers reste suspect, une réinstallation devient défendable, en dernier recours et après sauvegarde complète des données.

Faut-il vérifier le disque dur ?

Ce n’est pas la piste principale, mais des arrêts brutaux répétés abîment le système de fichiers. Un passage de chkdsk après stabilisation de la machine est raisonnable.

Comment savoir si l’alimentation est en cause ?

Par élimination : la mémoire est testée, les températures sont correctes, l’overclocking est désactivé, et les arrêts n’arrivent que sous forte charge. Le remplacement temporaire par un bloc de puissance équivalente tranche la question, sans outil de mesure.

_{Photo d en-tete : processeur Intel Core i7-12700K installe dans son socket, par 4300streetcar, CC BY 4.0, via Wikimedia Commons. Le modele photographie n est pas lie a un code d arret particulier.
Sources : Microsoft Learn, Bug Check 0x9C MACHINE_CHECK_EXCEPTION ; Microsoft Learn, Bug Check 0x124 WHEA_UNCORRECTABLE_ERROR ; Microsoft Learn, Stop code error or bug check troubleshooting ; Microsoft Support, How to fix WHEA_UNCORRECTABLE_ERROR ; Microsoft Support, Troubleshooting Windows unexpected restarts and stop code errors.}