Accueil » Blog » Informatique » Windows » Ecran bleu aleatoire : methode de diagnostic complete

Ecran bleu aleatoire : methode de diagnostic complete

Un écran bleu qui tombe au hasard, sans application déclenchante ni horaire régulier, se diagnostique par élimination : le code d’arrêt d’abord, le fichier de vidage ensuite, puis les pilotes, la mémoire et l’alimentation. La cause est logicielle dans la majorité des cas, mais rien ne le prouve avant d’avoir lu un minidump.

Points clés

  • Sans code d’arrêt, aucun diagnostic sérieux n’est possible : commencez par forcer la conservation des vidages.
  • Le réglage utile se trouve dans Paramètres système avancés, Démarrage et récupération, en choisissant au minimum le vidage de mémoire du noyau.
  • Un plantage aléatoire qui suit une mise à jour de pilote se règle presque toujours par un retour en arrière, pas par une réinstallation.
  • Le vérificateur de pilotes provoque volontairement des plantages : il s’active sur une machine dont vous pouvez vous passer, jamais en pleine journée de travail.
  • Les tests se font un par un. Trois modifications simultanées rendent le résultat illisible.
Ordre des tests pour diagnostiquer un ecran bleu aleatoire
Une modification a la fois, dans cet ordre.

Aléatoire ne veut pas dire sans cause

Un écran bleu qui apparaît toujours au lancement du même logiciel désigne son coupable. Un écran bleu aléatoire, lui, ne donne rien : dix minutes après l’ouverture de session un jour, quatre heures plus tard le lendemain, parfois trois fois en une heure. C’est ce caractère erratique qui pousse à tout changer en même temps, et c’est exactement ce qu’il ne faut pas faire.

Quatre familles de causes produisent ce profil : un pilote en mode noyau qui accède à une zone mémoire au mauvais moment, une barrette de mémoire vive instable, une alimentation ou une surchauffe qui coupe le processeur sous charge, et plus rarement un fichier système corrompu. Chacune se teste séparément, et la méthode ci-dessous les prend dans l’ordre du moins coûteux au plus lourd.

Chaque code d’arrêt a sa propre logique. Le guide des écrans bleus par code d’arrêt recense les codes traités un par un ; cette page-ci sert quand aucun code n’est encore identifié, ou quand le code change d’un plantage à l’autre.

A lire  Écran bleu SYSTEM_PTE_MISUSE : les solutions

Étape 1 : récupérer le code d’arrêt

Le code s’affiche sous le visage triste, sous la forme d’un nom en majuscules (IRQL_NOT_LESS_OR_EQUAL) ou d’une valeur hexadécimale. S’il est passé trop vite, deux endroits le conservent.

Le premier est l’Observateur d’événements : journal Système, source BugCheck, événement 1001. La description contient les quatre paramètres du plantage et le chemin du fichier de vidage. Le second est le fichier de vidage lui-même, dans C:\Windows\Minidump.

Si ce dossier est vide alors que la machine a planté, la conservation des vidages est désactivée. C’est le premier réglage à corriger.

Étape 2 : configurer les paramètres de défaillance système

Ouvrez les paramètres système avancés (raccourci : sysdm.cpl puis onglet Paramètres système avancés), section Démarrage et récupération, bouton Paramètres.

Dans Écriture d’informations de débogage, choisissez au minimum Vidage de mémoire du noyau. Le vidage automatique, réglage par défaut, suffit dans la plupart des cas mais peut produire un fichier plus pauvre. Le vidage de mémoire complet capture toute la mémoire physique : il est le plus riche, il exige un fichier d’échange au moins égal à la mémoire installée, et Microsoft le réserve aux cas où le support le demande explicitement.

Décochez Redémarrer automatiquement le temps du diagnostic : l’écran bleu reste affiché et vous pouvez noter le code. Vérifiez aussi que le fichier d’échange n’est pas désactivé et qu’il reste géré par le système sur le volume de démarrage, sinon aucun vidage ne sera écrit.

Quatre familles de causes d ecran bleu aleatoire et leur test decisif
Chaque famille a sa signature et son test.

Étape 3 : lire le minidump

Un minidump fait quelques centaines de kilo-octets et contient l’essentiel : le code d’arrêt, ses paramètres, et la pile d’appels au moment de la défaillance. C’est là qu’apparaît le nom du pilote fautif, sous la forme d’un fichier .sys.

L’outil officiel est WinDbg, avec la commande !analyze -v et le serveur de symboles Microsoft. La procédure complète, y compris la configuration du chemin des symboles, est détaillée dans notre article sur l’analyse d’un fichier de vidage mémoire.

Un point de prudence : le pilote nommé dans la pile n’est pas toujours le coupable. ntoskrnl.exe ou win32kbase.sys apparaissent constamment parce qu’ils sont au cœur du noyau, sans être en cause. Un fichier tiers identifiable (pilote réseau, antivirus, gestion de LED, outil d’overclocking) est un signal beaucoup plus solide. Et si trois minidumps successifs pointent trois modules différents, c’est le matériel qu’il faut regarder, pas le logiciel.

A lire  Écran bleu APC_INDEX_MISMATCH : les solutions

Étape 4 : le vérificateur de pilotes

Quand les vidages n’accusent personne, le vérificateur de pilotes force le système à surveiller chaque pilote tiers et à planter au premier écart, en nommant le responsable. Il est intégré à Windows sous le nom verifier.exe.

Microsoft rappelle que l’outil peut rendre la machine instable ou non démarrable et recommande de ne l’utiliser que sur un poste dédié aux tests. Trois précautions minimales : créer un point de restauration, savoir accéder au mode sans échec, et ne cocher que les pilotes non signés par Microsoft.

Lancez verifier en administrateur, choisissez de créer des paramètres personnalisés, sélectionnez les vérifications standard, puis ciblez les pilotes tiers. Redémarrez et utilisez la machine normalement. Au plantage suivant, le minidump désigne le module fautif. Désactivez ensuite tout avec verifier /reset et redémarrez : l’outil ne doit jamais rester actif en usage courant.

Étape 5 : tester la mémoire

La mémoire vive instable est la première cause matérielle des écrans bleus aléatoires, et les codes qu’elle produit sont trompeurs : PAGE_FAULT_IN_NONPAGED_AREA, MEMORY_MANAGEMENT, ou un code différent à chaque plantage.

L’outil intégré, mdsched.exe, fait un premier tri. Son verdict se retrouve dans l’Observateur d’événements, source MemoryDiagnostics-Results. Il est rapide mais peu sévère : une mémoire défaillante peut le passer sans erreur.

Pour trancher, MemTest86 lancé depuis une clé USB tourne hors de Windows et enchaîne plusieurs passes. Comptez au moins quatre passes complètes, idéalement une nuit. Une seule erreur suffit à condamner la barrette.

Si le test remonte des erreurs, testez les barrettes une par une, dans le même emplacement, pour distinguer une barrette morte d’un slot défaillant. Vérifiez aussi le profil XMP ou EXPO activé dans le BIOS : une mémoire vendue pour une fréquence donnée n’est pas toujours stable à cette fréquence sur toutes les cartes mères. Revenir aux fréquences par défaut est un test gratuit et souvent décisif.

Étape 6 : températures, alimentation et stockage

Un plantage qui survient surtout sous charge, en jeu ou pendant un export vidéo, oriente vers la thermique ou l’alimentation. Relevez les températures du processeur et de la carte graphique pendant l’usage habituel : au-delà de 95 °C sur le processeur, la stabilité n’est plus garantie même si la machine ne s’éteint pas.

Côté alimentation, un bloc vieillissant ou sous-dimensionné produit des coupures franches plutôt que des écrans bleus, mais les deux se croisent. Les extinctions brutales laissent une trace dans l’Observateur d’événements sous Kernel-Power, événement 41.

A lire  Écran bleu MEMORY_MANAGEMENT : les solutions

Le disque système mérite un contrôle rapide : chkdsk C: /scan pour les erreurs de système de fichiers, et la lecture des attributs SMART du SSD ou du disque dur avec l’utilitaire du fabricant. Un support en fin de vie produit des lectures ratées qui se traduisent par des plantages sans motif apparent.

L’ordre des tests, et pourquoi il compte

La règle tient en une phrase : une modification, puis plusieurs jours d’usage normal, puis conclusion. Un écran bleu qui tombe deux fois par semaine demande deux semaines d’observation pour être déclaré résolu.

  1. Activer les vidages et relever le code d’arrêt.
  2. Mettre à jour ou restaurer le pilote désigné par le minidump.
  3. Retirer les logiciels bas niveau récents : antivirus tiers, VPN, outils d’overclocking, pilotes de périphériques de jeu.
  4. Contrôler le système avec sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth.
  5. Tester la mémoire, désactiver XMP ou EXPO.
  6. Surveiller températures et alimentation.
  7. En dernier recours, réinstallation propre, uniquement si tout le reste est sorti indemne.

La réinstallation ferme le débat entre logiciel et matériel, mais elle coûte une journée et efface les preuves. Elle vient à la fin, jamais au milieu.

FAQ

Combien de minidumps faut-il avant de conclure ?

Au moins trois. Un seul vidage peut désigner un module par hasard. Trois vidages qui pointent le même fichier .sys constituent une piste solide.

Le dossier Minidump est vide, pourquoi ?

Soit l’écriture des informations de débogage est réglée sur aucune, soit le fichier d’échange est désactivé ou trop petit sur le volume système, soit un utilitaire de nettoyage supprime les vidages automatiquement.

Un écran bleu différent à chaque fois, est-ce du matériel ?

C’est le scénario typique d’une mémoire instable ou d’une alimentation défaillante. Un problème logiciel produit en général un code stable. Commencez par MemTest86 et par le retour aux fréquences mémoire par défaut.

Faut-il laisser le vérificateur de pilotes activé en permanence ?

Non. Il dégrade les performances et provoque des plantages volontaires. Il s’utilise sur une session de test, puis se désactive avec verifier /reset.

Une réinstallation de Windows règle-t-elle un écran bleu aléatoire ?

Elle règle les causes logicielles et laisse intactes les causes matérielles. Si les plantages reviennent sur un système fraîchement installé, sans pilote tiers, le matériel est en cause.

Photo d’en-tete : ecran bleu Windows, par Tony Webster, licence CC BY 2.0, via Wikimedia Commons. Le code d’arret visible sur la photo n’est pas celui traite ici.
Sources : Microsoft Learn, générer un vidage sur incident du noyau ou complet ; Microsoft Learn, vérificateur de pilotes ; Microsoft Learn, isoler un pilote avec Driver Verifier ; Microsoft Learn, lire un petit fichier de vidage mémoire ; MemTest86.

Laisser un commentaire

Pin It on Pinterest