Trouvez votre cas en 30 secondes

« Mon PC s'éteint tout seul » recouvre cinq pannes très différentes, qui n'ont ni le même diagnostic ni le même coût. Commencez par identifier la vôtre, sinon vous appliquerez le remède d'une autre :

📘 Cet article est la suite logique de notre guide Écran bleu DRIVER_POWER_STATE_FAILURE (0x9F) : pourquoi votre PC coupe et comment trouver le pilote coupable. Celui-là explique le code d'erreur et les correctifs habituels. Celui-ci, c'est l'enquête, quand les correctifs habituels n'ont rien donné.

Sommaire

• Ce que Windows enregistre à votre insu

• La commande qui sort la liste des coupables

• Si la liste revient vide : cinq causes et comment réarmer WER

• Apprendre à lire un « bucket » en trois minutes

• Le dictionnaire des pilotes que vous allez croiser

• Pilote victime ou pilote coupable : la règle qui fait gagner des semaines

• Le raisonnement qui a désigné le coupable

• Le contre-test WHEA : ce que le matériel déclare lui-même

• Kernel-Power 41 : les deux champs que personne ne regarde

• « Mais ça coupe même sans mise en veille ! »

• Le test décisif : gratuit, réversible, sans rien démonter

• Quand il n'y a aucun écran bleu : la coupure franche

• Quand ça coupe sous charge : alimentation ou refroidissement

• Le cas d'atelier, de bout en bout

• Que faire une fois le coupable identifié

• Sept idées reçues qui font perdre du temps et de l'argent

• Combien de temps, combien ça coûte

• Tableau récapitulatif

• FAQ

• Se faire aider

⚠️ À lire avant de commencer. Tout ce qui consiste à lire des journaux et des rapports (la majorité de cet article) est sans aucun risque : rien n'est modifié, rien n'est désinstallé, et c'est parfaitement adapté à un diagnostic à distance. En revanche, désactiver un périphérique, toucher aux pilotes graphiques ou démonter une machine peut aggraver la situation si c'est appliqué à tort, en particulier sur un PC dont le disque est déjà fatigué. Sauvegardez avant. Comme indiqué dans nos mentions légales, BSC Informatique ne saurait être tenue responsable des conséquences de l'application de cet article.

Ce que Windows enregistre à votre insu

Le PC coupe. Pas d'écran bleu qu'on a le temps de lire, pas de message : l'écran devient noir, la machine redémarre, et Windows affiche au retour « Windows ne s'est pas arrêté correctement ». Vous ouvrez l'Observateur d'événements, et vous tombez sur une ligne :

À ce stade, tous les tutoriels vous envoient au même endroit : installer WinDbg, télécharger les symboles de débogage, ouvrir le minidump, taper !analyze -v. C'est efficace, mais c'est long, ça demande d'installer un outil de développeur sur une machine qui n'est déjà pas stable, et pour un particulier c'est franchement rebutant.

La bonne nouvelle : dans l'immense majorité des cas, c'est déjà fait. À chaque plantage, Windows produit deux choses bien distinctes :

C'est le second qui nous intéresse. WER (Windows Error Reporting) est le mécanisme qui, depuis Windows XP, propose d'« envoyer un rapport à Microsoft ». Ce que presque personne ne sait, c'est que ce rapport contient un champ nommé Response.BucketId : une signature de classement du plantage, calculée à partir de l'analyse du dump, exactement le même travail que !analyze, et qui contient le nom du fichier pilote incriminé.

Deux avantages décisifs sur le minidump :

• Aucun outil à installer. C'est du texte, lisible avec le Bloc-notes.

• L'historique est bien plus long. Les minidumps sont souvent purgés (nettoyage de disque, utilitaires « d'optimisation », réinstallation) ; les dossiers WER\ReportArchive et WER\ReportQueue conservent couramment des dizaines voire des centaines de rapports sur plusieurs mois. Sur un cas réel d'atelier, la machine ne conservait que quelques dumps, mais 92 rapports WER exploitables.

Et c'est là que ça devient intéressant : un minidump, c'est un plantage. Quatre-vingt-douze rapports, c'est une statistique. Un diagnostic construit sur une observation isolée est fragile ; un diagnostic construit sur une distribution de quatre-vingt-douze plantages, beaucoup moins.

La commande qui sort la liste des coupables

Ouvrez PowerShell (clic droit sur le menu Démarrer, puis Terminal ou Windows PowerShell), et collez ceci :

En une ligne : elle parcourt tous les rapports d'erreur, en extrait le champ Response.BucketId, et les regroupe par fréquence.

💡 Détail qui compte : le test if ($m) n'est pas cosmétique. Beaucoup de rapports WER ne contiennent pas de Response.BucketId (rapports d'application, rapports jamais envoyés à Microsoft). Sans ce garde-fou, la version courte de la commande, qu'on voit circuler un peu partout, s'interrompt sur une erreur d'index dès le premier rapport sans bucket, et on croit à tort que la machine n'a rien.

Ce n'est ni risqué ni intrusif : la commande lit des fichiers, elle n'écrit rien, ne modifie rien et ne désinstalle rien.

La même chose, mais datée

Le classement par fréquence donne le coupable. La chronologie, elle, donne le déclencheur, et c'est souvent ce qui manque :

Ce que vous cherchez dans cette liste :

• Les plantages ont-ils commencé à une date précise ? Si oui, que s'est-il passé ce jour-là (mise à jour Windows, nouveau pilote, nouveau périphérique, déménagement de la machine, début de l'été) ?

• La signature a-t-elle changé en cours de route ? Un bucket qui se transforme en un autre, c'est souvent un correctif qui a déplacé le problème sans le résoudre.

• Les plantages sont-ils groupés sur quelques jours, alors que le pilote suspecté est installé depuis des mois ? Dans ce cas, le déclencheur est presque toujours matériel (chaleur, contact, alimentation), pas logiciel. C'est un discriminant que nous utilisons systématiquement en atelier.

Voir l'historique des écrans bleus, autrement

Deuxième source, indépendante de WER, et utile quand les rapports ont été purgés :

L'événement 1001 contient le code d'arrêt et ses quatre paramètres, plus le chemin du dump. C'est là que vous lirez noir sur blanc le fameux 0x0000009f (0x0000000000000003, ...), dont le premier paramètre 3 est déjà, à lui seul, une information de diagnostic.

Si la liste revient vide : cinq causes et comment réarmer WER

Une liste vide ne veut pas dire « machine saine ». Dans l'ordre de fréquence :

1. Les rapports ont été supprimés par un nettoyage de disque, un utilitaire tiers « d'optimisation », ou une réinstallation récente. C'est de loin la première cause, et c'est la raison pour laquelle il vaut mieux lancer la commande avant de nettoyer quoi que ce soit.

2. WER est désactivé. Vérifiez dans Paramètres, Confidentialité et sécurité, Diagnostics et commentaires. Sur les postes d'entreprise, WER est souvent coupé par stratégie de groupe, et il faudra passer par le service informatique.

3. La machine n'a pas vraiment planté : les coupures étaient des arrêts francs, sans écran bleu. Ce cas a sa propre section, et c'est un tout autre diagnostic. → Coupure franche

4. Le disque système était plein au moment des plantages. Sans place, ni dump ni rapport ne s'écrivent.

5. L'écriture des dumps est désactivée. Clic droit sur Ce PC, Propriétés, Paramètres système avancés, Démarrage et récupération : choisissez Image mémoire partielle (minidump) et décochez Redémarrer automatiquement. Ainsi, le prochain écran bleu restera affiché assez longtemps pour être photographié, et il laissera une trace exploitable.

Puis attendez le prochain plantage. Cela paraît frustrant, mais un diagnostic reposant sur un seul incident bien capturé vaut mieux que trois semaines de manipulations à l'aveugle.

Apprendre à lire un « bucket » en trois minutes

Voici le résultat obtenu sur une machine réellement passée à l'atelier, un tout-en-un de bureautique d'environ six ans qui coupait plusieurs fois par semaine :

À première vue, c'est du charabia. En réalité, tout le diagnostic est là, et il est même écrit plusieurs fois.

Un bucket se lit de gauche à droite, comme une phrase. Prenons le troisième :

Deux préfixes à retenir, parce qu'ils changent complètement la lecture :

• 0x… = un vrai écran bleu, la machine s'est arrêtée.

• LKD_… = un incident capturé à chaud, sans arrêt du système. Ce sont des signaux précieux : ils passent totalement inaperçus pour l'utilisateur, mais ils s'accumulent dans les rapports. Beaucoup de machines « qui vont bien » ont en réalité des dizaines de LKD au compteur, et c'est parfois le tout premier signe d'un composant qui se dégrade.

Les autres paramètres possibles du 0x9F, plus rares mais qui orientent différemment :

Le dictionnaire des pilotes que vous allez croiser

Un bucket ne sert à rien si le nom de fichier ne vous dit rien. Voici les fichiers qui reviennent le plus souvent sur un 0x9F, et ce qu'ils désignent réellement :

Pilote victime ou pilote coupable : la règle qui fait gagner des semaines

C'est le point où se joue l'essentiel du diagnostic, et c'est celui que les tutoriels passent sous silence.

Dans notre tableau de résultats, les buckets 0x9F ne citent que des pilotes Microsoft : pci.sys et ACPI.sys sont des composants du cœur de Windows, installés sur des centaines de millions de PC. S'ils étaient bogués, cela se saurait. Ils apparaissent parce qu'ils sont les derniers à avoir tenu la requête avant qu'elle ne se perde dans le vide.

Et la réciproque est vraie, ce qui en fait un aiguillage utilisable tel quel :

⚠️ La nuance qui évite l'erreur inverse : un pilote Microsoft en tête ne prouve pas à lui seul un défaut matériel. Il l'indique fortement, et il demande une confirmation indépendante. C'est exactement ce que fournit la section suivante.

Le raisonnement qui a désigné le coupable

Relisons le tableau de la machine d'atelier, non plus ligne par ligne, mais comme un faisceau d'indices.

Premier constat : les buckets 0x9F ne citent que du Microsoft. Application directe de la règle ci-dessus : le problème est derrière pci.sys, donc sur un périphérique PCI Express.

Deuxième constat : le mot DXG oriente vers le graphique. La requête bloquée est celle de la pile graphique, et le composant qui ne rend pas la main est sous pci.sys. Donc une carte graphique branchée en PCI Express.

Troisième constat : trois buckets citent nommément nvlddmkm, le pilote NVIDIA, et pas pour dire n'importe quoi :

• nvlddmkm failed DdiStartDevice avec le statut 0xC000009A : le pilote n'arrive plus à démarrer la carte graphique ;

• Tdr:6 … Maxwell_3D : la puce se fige et doit être réinitialisée ;

• nvlddmkm!NvDispatchPower : plantage exactement dans la gestion d'énergie du circuit graphique.

Quatrième constat, et c'est celui qui clôt le débat : le bucket le plus fréquent est un 0x124. Ce code d'arrêt ne parle plus du tout de pilote : il signifie erreur matérielle irrécupérable, remontée par le processeur et le firmware de la carte mère. Le mot FIRMWARE dans la signature indique que c'est le BIOS lui-même qui a capturé l'erreur au moment du plantage et l'a transmise à Windows au démarrage suivant. C'est aussi pour cela que l'horodatage de ces événements est collé au démarrage, et non à l'heure réelle de la coupure : un détail qui déroute quand on croise les journaux, et qu'il faut connaître pour ne pas conclure de travers.

Trois familles d'indices indépendantes (les buckets graphiques, les échecs du pilote NVIDIA, et une erreur matérielle fatale confirmée par le firmware) convergent vers la même pièce : la carte graphique NVIDIA, soudée sur la carte mère.

Le contre-test WHEA : ce que le matériel déclare lui-même

Cette erreur 0x124 se vérifie directement dans l'Observateur d'événements, sous une source sans ambiguïté : WHEA-Logger (Windows Hardware Error Architecture). Une commande suffit :

Sur la machine en question : 35 événements WHEA-Logger ID 1, « erreur matérielle irrécupérable ». Un WHEA fatal ne s'invente pas et ne se corrige pas avec un pilote : c'est le matériel qui le déclare lui-même.

Pour croiser proprement les dates, comptez les événements par jour :

Cet histogramme en texte est étonnamment parlant : il montre d'un coup d'œil si le phénomène est ancien et stable, ou s'il s'est emballé à partir d'une date précise.

Kernel-Power 41 : les deux champs que personne ne regarde

L'événement Kernel-Power 41 est la trace universelle d'un arrêt non planifié. Tout le monde le trouve, presque personne ne l'exploite : on lit « le système a redémarré sans s'arrêter correctement », on en conclut « panne d'alimentation », et on part commander un bloc d'alimentation.

Cet événement porte pourtant deux champs qui changent complètement le diagnostic, et qui ne s'affichent pas dans l'onglet Général de l'Observateur d'événements :

BugcheckCode vous dit ce qui s'est réellement passé :

• différent de 0 (par exemple 0x9F) : il y a bien eu un écran bleu, même si vous ne l'avez pas vu. Windows a eu le temps d'écrire un dump, la méthode WER de cet article s'applique.

• égal à 0 : aucun écran bleu. La machine a été coupée net, comme si on avait retiré la prise. Windows n'a rien pu écrire, il n'y a donc rien à chercher dans les dumps. C'est un tout autre diagnostic, et c'est la section suivante.

PowerButtonTimestamp répond à une question qu'on ne pense même pas à poser :

• égal à 0 : personne n'a touché le bouton, la machine a bien été coupée toute seule.

• supérieur à 0 : quelqu'un a appuyé sur le bouton d'alimentation, et la date exacte de l'appui est inscrite là. Ce n'est pas une panne d'alimentation : c'est un arrêt forcé par l'utilisateur. La vraie question devient alors pourquoi a-t-il appuyé ? En pratique : Windows ne répondait plus, ou l'écran était resté noir.

Nous avons vu en atelier un cas où deux « coupures » sur trois portaient un appui bouton horodaté, dont le dernier 47 secondes après le dernier événement journalisé. Le client était parfaitement sincère en décrivant un PC qui s'éteint tout seul : il ne savait pas qu'un appui long était interprété par la machine comme un arrêt forcé, et le diagnostic « alimentation à changer » qu'on lui avait annoncé était à côté du sujet.

⚠️ Ne concluez pas « appui court » sur le champ LongPowerButtonPressDetected : sur les firmwares un peu anciens, il reste à false même après un appui long. Le champ fiable est bien l'horodatage.

Enfin, comparer les jours entre eux est souvent plus parlant que n'importe quel événement isolé. L'événement Kernel-Power 42 (entrée en veille) et l'événement 107 (sortie de veille) donnent le rythme de vie de la machine :

Un rythme régulier pendant des mois, puis une journée à sept cycles en une heure, situe le basculement à la demi-journée près. Et si ces sept arrêts-là sont propres (événements 1074 ou 6006, aucun 41), c'est que ce jour-là l'utilisateur voyait encore son écran et utilisait encore le menu Démarrer. Ce genre de recoupement vaut souvent mieux qu'un interrogatoire.

« Mais ça coupe même sans mise en veille ! »

C'est l'objection systématique, et elle mérite une vraie réponse, parce qu'elle fait passer à côté du diagnostic dans énormément de cas.

Le nom du code d'erreur (DRIVER_POWER_STATE_FAILURE) fait spontanément penser à la mise en veille. On vérifie donc les réglages d'alimentation, on met la veille sur « jamais », et ça continue de couper. On en conclut, à tort, que ce n'est pas ça.

Or une transition d'alimentation, ce n'est pas seulement la veille du PC entier. C'est aussi la mise en sommeil d'un seul composant, pendant que vous travaillez normalement. Windows le fait en permanence, sans rien vous demander :

• la veille sélective USB, qui endort un port inutilisé ;
• l'économie d'énergie de la carte Wi-Fi, qui s'endort entre deux paquets ;
• les états ASPM et APST du SSD NVMe, plusieurs fois par minute ;
• et surtout, sur les machines à deux circuits graphiques, la bascule du circuit dédié.

C'est ce dernier cas qui est le plus éclairant. Les portables et tout-en-un à double carte graphique (technologie Optimus chez NVIDIA, équivalents chez AMD) possèdent deux puces graphiques : celle intégrée au processeur, économe, qui gère la bureautique, et une puce dédiée, plus puissante, que Windows allume et éteint en permanence, à chaque application qui la sollicite puis la relâche.

Sur le poste de l'atelier, la veille secteur était réglée sur « jamais » depuis des mois. Cela n'avait strictement rien changé, et c'était en réalité une information, pas une impasse.

💡 Si vous voulez voir ces transitions plutôt que de me croire sur parole, deux rapports intégrés à Windows les listent, sans rien installer : powercfg /energy (à lancer en administrateur, produit un rapport HTML au bout de 60 secondes) et powercfg /sleepstudy. Ils nomment les périphériques et les pilotes qui bloquent les transitions, et c'est un excellent complément aux buckets WER.

Le test décisif : gratuit, réversible, sans rien démonter

Une fois la carte graphique dédiée suspectée, il reste à le prouver. Et il existe pour cela un test remarquablement simple : la désactiver.

Sur une machine Optimus, la puce dédiée n'a aucune sortie écran physique : l'affichage passe toujours par la puce intégrée au processeur. La désactiver ne noircit donc pas l'écran. C'est contre-intuitif, mais c'est bien le fonctionnement de cette architecture.

Étape 1 : vérifier qui pilote réellement l'écran

À ne surtout pas sauter.

Seule la puce intégrée (Intel UHD, Intel Iris, AMD Radeon Graphics) doit afficher une résolution active. Si c'est la carte NVIDIA ou AMD dédiée qui affiche la résolution, arrêtez-vous là : sur cette machine, elle pilote l'écran, et la désactiver vous laisserait devant un écran noir.

⚠️ Cas particulier des portables récents à commutateur MUX (gammes gamer surtout) : selon le mode choisi dans l'utilitaire du constructeur, la puce dédiée peut piloter l'écran directement. Si votre machine propose un mode Optimus / Standard / Hybride et un mode Ultimate / dGPU, repassez en mode hybride avant de tester, et redémarrez, le commutateur ne bascule qu'au démarrage.

Étape 2 : désactiver la puce dédiée

PowerShell en administrateur, en remplaçant le modèle par le vôtre :

Retour arrière, à tout moment :

Sans aucune ligne de commande, c'est tout aussi faisable : Gestionnaire de périphériques, Cartes graphiques, clic droit sur la puce dédiée, Désactiver l'appareil (puis Activer l'appareil pour revenir en arrière).

Vérification immédiate que la désactivation a bien pris, et surtout que l'affichage n'a pas bougé :

Le code 22 signifie « désactivé », le code 0 signifie « fonctionne normalement ».

Étape 3 : laisser tourner 48 heures

Notez impérativement la date et l'heure du dernier plantage avant de lancer le test. Sans ce point de référence, vous ne saurez pas interpréter les 48 heures qui suivent. Puis :

Plus aucun événement 41 ni aucun WHEA après la désactivation, alors qu'il y en avait environ un par jour avant : le verdict est posé.

Quand il n'y a aucun écran bleu : la coupure franche

C'est l'autre grande famille, et elle est au moins aussi fréquente. Signature : des Kernel-Power 41 avec BugcheckCode = 0, aucun minidump, aucun bucket WER correspondant. La machine n'a pas planté, elle a perdu le courant, au sens propre.

Cherchez alors dans cet ordre, du plus probable et du moins cher au plus lourd :

1. La chaleur. Un empoussièrement sévère, une pâte thermique de dix ans, un ventilateur qui ne tourne plus : la protection thermique coupe l'alimentation sans prévenir. Symptôme typique : ça coupe sous charge (jeu, visioconférence, export vidéo), et presque jamais au repos. Voir notre guide sur les plantages liés à la surchauffe.

2. Les contacts. Sur une tour, « ça coupe quand on la touche ou qu'on la bouge » est presque une signature : connecteurs PCI Express 6 ou 8 broches encrassés, connecteur ATX 24 broches, bouton de façade fatigué, entretoise mal placée qui met la carte mère en contact avec le boîtier. Nous avons eu le cas d'une machine créditée de vingt coupures en quatre-vingt-dix jours, dont seize sans le moindre écran bleu : après nettoyage complet, poussière et connecteurs reconnectés un par un, le défaut n'était plus reproductible. Nettoyez et reconnectez avant de commander une alimentation.

3. Le bloc d'alimentation. C'est le suspect que tout le monde nomme en premier et qu'il faut vérifier en troisième. Ce qui trahit une alimentation fatiguée, ce n'est pas une tension absolue lue dans un logiciel, c'est l'affaissement relatif entre le repos et la pleine charge, au-delà de 3 % environ.

4. La batterie et le chargeur, sur un portable : une batterie gonflée ou en fin de vie peut couper la machine sans prévenir, et un chargeur sous-dimensionné ou mal reconnu produit exactement le même symptôme. Nous détaillons les pièges du sujet dans quel chargeur pour votre PC portable.

5. La mémoire. Une barrette défaillante produit en général des codes d'arrêt variés et aléatoires (0x1A, 0x50, 0x4E, 0x1E), et non un code unique répété. C'est un discriminant à connaître : quatre plantages rigoureusement identiques ne ressemblent pas à un défaut mémoire. Testez malgré tout avec MemTest86, quatre passes minimum, et sachez lire la ligne d'erreur, parce qu'elle ne désigne pas toujours la mémoire.

6. L'installation électrique elle-même. Coupures brèves sur le réseau, multiprise fatiguée, onduleur en fin de vie. Un détail qui aide : si plusieurs appareils de la pièce redémarrent en même temps, ce n'est pas le PC. Les redémarrages à répétition finissent d'ailleurs par abîmer le système : c'est le sujet de notre article sur l'écran bleu au démarrage après une coupure de courant.

⚠️ Un Kernel-Power 41 isolé, juste après une intervention matérielle (remontage, débranchement, transport), n'est pas un symptôme. Ne le comptez pas dans vos statistiques, sinon vous vous fabriquez une panne.

Quand ça coupe sous charge : alimentation ou refroidissement

Cas fréquent sur les machines de jeu et les tours un peu anciennes : tout va bien en bureautique, et ça coupe (ou ça affiche un 0x116 VIDEO_TDR_ERROR) dès que la carte graphique travaille. Deux causes produisent exactement le même symptôme, et on les confond très facilement :

• le refroidissement du circuit graphique, pâte thermique sèche ou radiateur encrassé ;

• l'alimentation, qui n'encaisse plus les appels de courant.

Sur une carte NVIDIA, l'outil qui tranche est déjà installé avec le pilote, et il ne demande rien de plus :

⚠️ Le piège qui ruine la mesure : l'option d'enregistrement intégrée (nvidia-smi -f fichier.csv -l 2) met les données en tampon. Le fichier reste à zéro octet et se perd si la machine se coupe, c'est-à-dire exactement dans le cas qu'on cherche à capturer. La boucle ci-dessus ouvre et ferme le fichier à chaque ligne : les dernières secondes avant la coupure, les plus précieuses, sont sur le disque.

Grille de lecture :

Ce dernier point est le piège de lecture classique : bridage de puissance et bridage thermique produisent la même courbe descendante. Il faut éliminer le premier avant de conclure au second.

Le cas d'atelier, de bout en bout

Ce qui n'a pas été fait, et c'est volontaire : aucune mise à jour de pilote « au cas où » (ils étaient déjà récents, et une erreur matérielle WHEA ne se corrige pas par un pilote), aucune réinstallation de Windows, aucun démontage.

Et les pistes explorées puis écartées, car elles font aussi partie du travail : le stockage (SMART sain, aucune prédiction de défaillance), la veille et le démarrage rapide (aucune corrélation avec les plantages), et les deux VPN plus la suite de sécurité installés sur la machine, suspects tout à fait légitimes au départ sur un 0x9F, définitivement écartés par des buckets qui ne les citent jamais.

🔍 Honnêteté sur le niveau de preuve : le diagnostic repose sur trois sources indépendantes et le correctif a été appliqué et vérifié sur place, mais la fenêtre d'observation de 48 heures n'a pas pu être menée pendant l'intervention. Si une machine replante malgré la désactivation, il faut reprendre sur la mémoire, la chauffe et l'alimentation. Nous préférons l'écrire plutôt que de vous vendre une certitude que nous n'avons pas mesurée.

Que faire une fois le coupable identifié

Selon ce que désigne l'analyse, la suite n'a rien à voir. Reportez-vous au tableau d'aiguillage pour la nature du problème, puis :

Si c'est un pilote tiers. Reprenez-le sur le site du constructeur du PC (pas sur Windows Update, et surtout pas via un « driver updater »), ou revenez à la version précédente si la panne est apparue après une mise à jour. Testez aussi, c'est immédiat et réversible : Gestionnaire de périphériques, le périphérique suspect, onglet Gestion de l'alimentation, décochez « Autoriser l'ordinateur à éteindre ce périphérique pour économiser l'énergie ». Si les plantages cessent, le coupable est identifié.

Si c'est le démarrage rapide. powercfg /h off en administrateur supprime une bonne partie des 0x9F liés à l'hibernation partielle. C'est un test, pas une fatalité : on peut le réactiver ensuite.

Si c'est une puce graphique soudée défaillante, il y a trois issues, à arbitrer selon la valeur de la machine :

1. Vivre avec, puce désactivée. Sur une machine de bureautique, c'est souvent la meilleure décision : remise en service immédiate, coût nul, aucun démontage. L'utilisateur ne voit aucune différence, sauf s'il joue ou fait du montage vidéo.

2. Réparation au composant sur la carte mère, quand la machine le justifie. C'est le métier de BSC Électronique, qui reprend les cartes mères de PC portables et de Chromebooks au composant.

3. Remplacement de la machine, si la réparation dépasse sa valeur résiduelle. Nous détaillons les critères de cet arbitrage dans réparer ou remplacer son ordinateur.

Sept idées reçues qui font perdre du temps et de l'argent

« Ça coupe, donc c'est l'alimentation. » Pas si l'événement 41 porte un BugcheckCode différent de zéro : dans ce cas, il y a eu écran bleu, Windows fonctionnait encore, et le courant n'a rien à voir. C'est le tout premier tri à faire, et il prend dix secondes.

« 0x9F, donc il faut changer le chargeur. » Le code parle de la gestion d'énergie logicielle des périphériques, pas d'électricité. Changer le chargeur sur un 0x9F ne corrige rien, et nous voyons régulièrement des clients qui en ont acheté deux.

« Je vais mettre tous les pilotes à jour, on verra bien. » Sur une erreur matérielle confirmée par WHEA, cela ne peut rien corriger par construction. Et si l'un des pilotes installés est plus récent que celui du constructeur, vous ajoutez une variable au lieu d'en retirer une. Les utilitaires de mise à jour automatique de pilotes sont, eux, à proscrire purement et simplement.

« Une réinstallation de Windows va régler ça. » Sur un défaut matériel, non. Et elle efface l'historique WER, c'est-à-dire précisément la preuve qui contenait la réponse. C'est la manipulation la plus coûteuse du lot : plusieurs heures perdues, données à risque, et un diagnostic à reprendre de zéro.

« Le pilote nommé dans le bucket est forcément le coupable. » Non, et c'est tout le sujet de la règle victime/coupable. pci.sys désigne presque toujours le matériel qui est derrière lui.

« Il n'y a pas de minidump, donc il n'y a rien à analyser. » Les rapports WER survivent bien plus longtemps que les dumps. Commencez toujours par eux.

« J'ai appliqué trois correctifs, ça va bien maintenant. » Peut-être. Mais sur une panne qui se produit tous les deux jours, trois jours sans incident ne prouvent rien, et vous ne saurez jamais lequel des trois a agi. Un changement à la fois, avec une date de référence notée.

Combien de temps, combien ça coûte

Pour situer les ordres de grandeur avant de vous lancer, ou avant de confier la machine :

Notre principe : un devis avant toute intervention, et un diagnostic qui désigne une pièce plutôt qu'un « on va réinstaller pour voir ».

Tableau récapitulatif

La phrase à retenir : Windows a déjà fait le diagnostic, il ne l'affiche simplement nulle part. Une commande, trois minutes de lecture, et vous savez si vous cherchez un pilote ou une pièce.

FAQ

Mon PC s'éteint tout seul sans écran bleu. Par où commencer ?
Par l'événement Kernel-Power 41 et son champ BugcheckCode. S'il vaut 0, il n'y a eu aucun écran bleu et il est inutile de chercher un pilote : orientez-vous vers l'alimentation, les contacts et la chauffe. La commande est dans cette section.

Où sont exactement les rapports WER ?
Dans C:\ProgramData\Microsoft\Windows\WER\, principalement dans les sous-dossiers ReportArchive (rapports déjà envoyés ou traités) et ReportQueue (en attente). Le dossier ProgramData est masqué par défaut, ce qui explique que presque personne n'en connaisse l'existence.

La commande PowerShell est-elle dangereuse ?
Non. Elle lit des fichiers texte et n'écrit rien, ne modifie aucun réglage, ne désinstalle rien. Elle ne nécessite même pas les droits administrateur dans la plupart des cas. C'est précisément pour cela qu'elle convient à un diagnostic à distance.

Elle ne renvoie rien du tout. C'est bon signe ?
Pas forcément. Voir les cinq causes d'une liste vide : le plus souvent, les rapports ont été effacés par un nettoyage de disque, ou WER est désactivé.

J'ai une erreur « Impossible d'appeler une méthode sur une expression de valeur Null ». Pourquoi ?
Parce que vous utilisez la version courte de la commande, sans le test if ($m). Elle s'interrompt sur le premier rapport qui ne contient pas de Response.BucketId. Utilisez la version de cet article.

Quelle différence entre 0x9F et 0x124 ?
0x9F dit qu'une requête d'alimentation n'a pas abouti : cela peut être un pilote. 0x124 dit que le processeur ou le firmware a détecté une erreur matérielle irrécupérable : ce n'est plus une question de pilote. Quand les deux coexistent, le 0x124 l'emporte dans la lecture.

J'ai des WHEA-Logger dans mon journal, mon PC est-il condamné ?
Regardez l'identifiant. Les ID 17 et 19 correspondent à des erreurs corrigées : quelques-unes sont normales. L'ID 1 correspond à une erreur fatale : répétée et corrélée à vos plantages, elle désigne un vrai défaut matériel.

Pourquoi l'heure des WHEA ne correspond-elle pas à l'heure de mes plantages ?
Parce que certaines de ces erreurs sont capturées par le firmware au moment du plantage, puis remontées à Windows au démarrage suivant. L'horodatage est donc collé au démarrage. Ne concluez pas que les événements ne sont pas liés.

Désactiver la carte graphique dédiée, ça ne va pas éteindre mon écran ?
Sur une machine Optimus classique, non : l'affichage passe par le circuit intégré au processeur et la puce dédiée n'a pas de sortie écran. Mais vérifiez-le avant avec la commande de l'étape 1, et méfiez-vous des portables récents à commutateur MUX.

Je perds quoi si je laisse la puce dédiée désactivée ?
Les performances 3D : jeux, montage vidéo, certains calculs accélérés et parfois l'accélération matérielle de quelques logiciels. Pour de la bureautique, du web et de la vidéo, la différence est en pratique invisible.

Ma puce désactivée s'est réactivée toute seule.
C'est courant après une mise à jour Windows ou une réinstallation du pilote graphique. Revérifiez ConfigManagerErrorCode avant de relancer un diagnostic complet.

Est-ce que ça peut être la mémoire ?
Oui, mais la signature est différente : une barrette défaillante produit des codes d'arrêt variés, pas un code unique répété des dizaines de fois. Testez avec MemTest86 sur au moins quatre passes, et lisez la ligne d'erreur correctement, elle n'accuse pas toujours la mémoire.

Ça coupe toujours au bout de vingt minutes de jeu. Même méthode ?
Non, orientez-vous d'abord vers la mesure sous charge : à cette régularité, c'est la chauffe ou l'alimentation, pas une transition d'alimentation aléatoire.

Mon PC portable coupe uniquement sur batterie, ou uniquement branché.
C'est une information de diagnostic à part entière. Sur batterie uniquement : batterie en fin de vie, ou profil d'alimentation qui endort agressivement les composants. Branché uniquement : chargeur, connecteur d'alimentation, ou carte fille de charge.

Faut-il installer WinDbg malgré tout ?
Si les buckets WER sont contradictoires ou trop dispersés, oui, WinDbg reste l'outil de référence. Mais dans neuf cas sur dix, la commande de cet article suffit et évite d'installer un environnement de développement sur une machine déjà instable.

Et BlueScreenView ou WhoCrashed ?
Ce sont de bons outils, plus simples que WinDbg, qui listent le .sys incriminé à partir des minidumps. Leur limite est la même que celle des dumps : l'historique est court, et souvent purgé. Les rapports WER couvrent des mois.

Puis-je faire tout cela à distance, sans déplacer la machine ?
Oui, et c'est un des grands avantages de la méthode : elle ne consiste qu'à lire des fichiers. Nous traitons couramment ce diagnostic en prise en main à distance, depuis notre page support.

Se faire aider

Lire des buckets WER, distinguer un pilote victime d'un pilote coupable, décider si une puce graphique soudée se répare ou se contourne : c'est un travail d'atelier, et il vaut mieux le faire avant que la machine ne finisse par ne plus démarrer du tout.

BSC Informatique prend ce type de panne en atelier, pour les particuliers comme pour les professionnels : diagnostic complet des plantages (journaux, rapports WER, tests mémoire et stockage sur banc, mesures de température et de tension sous charge), avec un devis avant toute intervention. Nous intervenons aussi à distance, par prise en main, quand le diagnostic ne demande que de la lecture de journaux, et nous vendons et installons le matériel de remplacement.

📍 Atelier : 18 Avenue Olbius Riquier, 83400 Hyères · ☎️ 04 94 27 65 95 · ✉️ contact@bsc-informatique.fr

Selon votre situation, une autre structure du groupe sera plus adaptée :

• Vous êtes un particulier et vous préférez une intervention chez vous (Hyères et alentours) : BSC Assistance, agréée service à la personne, se déplace pour le diagnostic et la remise en état.

• Puce graphique ou carte mère à reprendre au composant : BSC Électronique, spécialiste de la réparation de cartes mères de PC portables et de Chromebooks.

• Des fichiers perdus ou un disque devenu illisible après une série de coupures brutales : BSC DataRecovery, récupération de données en laboratoire sur disque dur, SSD, carte mémoire, clé USB et systèmes RAID. N'écrivez plus rien sur le disque concerné.

• Il vous faut un ordinateur pendant l'immobilisation du vôtre : BSC Location, location de PC fixes et portables, en courte comme en longue durée.

• Notifications douteuses, faux support technique, machine polluée : BSC Sécurité, nettoyage et sécurisation des postes des particuliers.

Les manipulations décrites (lecture des journaux, désactivation d'un périphérique, tests matériels) sont réversibles, mais peuvent aggraver la situation si elles sont appliquées à tort, en particulier sur une machine dont le disque est déjà fatigué. En cas de doute, ou de données importantes, faites-vous accompagner.

Sources : Microsoft Learn, Bug Check 0x9F DRIVER_POWER_STATE_FAILURE et Bug Check 0x124 WHEA_UNCORRECTABLE_ERROR ; Microsoft Learn, documentation Windows Error Reporting et Windows Hardware Error Architecture (WHEA) ; CodeMachine, Debugging Bug Check 0x9F ; Sysnative Forums, méthodes de débogage du 0x9F avec premier paramètre 0x3 ; NVIDIA, documentation nvidia-smi et technologie Optimus. Cas d'atelier BSC Informatique, Hyères, 2026 : tout-en-un Intel + NVIDIA MX130 sous Windows 11, tour Intel Z77 avec BSOD 0x116 répétés, poste de bureau avec arrêts forcés horodatés. EURL BSC INFORMATIQUE, 18 Avenue Olbius Riquier, 83400 Hyères, 04 94 27 65 95.

Votre PC s'éteint tout seul ? On identifie la cause à Hyères

Analyse des rapports d'erreur Windows, lecture des journaux WHEA et Kernel-Power, tests mémoire, chauffe et alimentation sur banc :
on désigne la pièce ou le pilote fautif au lieu de tout réinstaller. Particuliers et professionnels.

Tél. 04 94 27 65 95