260803-suivi des logs de dysfonctionnement du PC - écrans bleus de la mort

Suivi des dysfonctionnements du PC eliob — écrans bleus

⚠ Mise à jour du 2026-08-25 — après réinstallation de Windows : les écrans bleus ont quasiment cessé, les coupures sèches non.

Deux précisions qui modifient la lecture de toute cette page :

1. eliob et julie sont la même machine. Le poste décrit ici n'a pas disparu : Windows y a été réinstallé le 2026-08-08 à 12:21, précisément à cause des plantages analysés dans cette page. Le compte eliob ayant perdu ses identifiants, un nouveau profil a été créé à 12:36 sous le nom julie (faute de frappe pour julien), adossé au compte Microsoft julien.bertrand@live.fr. C'est le seul profil de la machine. Matériel identique vérifié le 2026-08-25 : MSI A320M-A PRO (MS-7C51), BIOS 1.40 du 08/12/2020, Ryzen 5 2600X, une seule barrette 16 Go à 2400 MHz, RX 6500 XT.

2. Les deux populations ont divergé, et c'est le fait nouveau le plus important.

  • Écrans bleus : amélioration nette et vécue comme telle. Ils étaient incessants avant la réinstallation — 3 × 0x50 en 4 jours du 31/07 au 03/08. Depuis le système neuf : 2 × 0x9F le 12/08, puis plus rien pendant 13 jours.
  • Coupures sèches : inchangées. Elles ont traversé la reconstruction complète du système. Mais 2 des 6 arrêts de la période sont d'origine électrique externe établie — coupure Enedis le 24/08 à 06:24, débranchement volontaire face aux orages — ce qui fait passer la qualité du secteur en tête des hypothèses. Restent 4 épisodes inexpliqués.

3. Les mesures du 2026-08-03 ont été effacées par la réinstallation — voir § 8 et § 10. Le démarrage rapide est de nouveau actif, la rétention des vidages est retombée à 5. À réappliquer.

Voir le journal (§ 12) et la révision du diagnostic (§ 9).

Machine : PC Windows eliob (pcelio) Analyse initiale : 2026-08-03 — Claude Code Fenêtre observée : 29/10/2025 → 03/08/2026 pour le journal d'événements (Windows réinstallé le 28/10/2025) — les compteurs SMART, eux, couvrent toute la vie des disques

En bref

  • Deux problèmes distincts, pas un seul.
  • Écrans bleus 0x50 : cause établie — amdfendr.sys (AMD Crash Defender), embarqué dans un pilote Radeon de janvier 2022 jamais mis à jour. Confirmé par trois déterminations indépendantes, mécanisme du plantage compris. Correctif : réinstaller le pilote AMD avec DDU.
  • 30 coupures sèches sans écran bleu : cause inconnue. Aucune trace exploitable. Le compteur SMART montre que le phénomène précède la réinstallation de Windows — piste matérielle, alimentation en tête.
  • Aucun composant électronique défectueux identifié à ce jour : 0 erreur WHEA, 4 disques SMART impeccables, SSD système à 88 % de vie restante.
  • Actions déjà appliquées : voir §10. Action restante à la charge de Julien : réinstallation du pilote AMD.

Mise à jour du 2026-08-03, 08h30 — après élévation de privilèges, les rapports WER ont pu être lus et désignent nommément le module fautif : amdfendr.sys (AMD Crash Defender). Le pilote réseau VirtualBox, suspect n°1 de la première version de cette analyse, est disculpé comme cause des écrans bleus. Voir §6.

Mise à jour du 2026-08-03, 09h00 — WinDbg et smartmontools installés. Le vidage mémoire a été analysé : la pile d'appels confirme amdfendr.sys et donne le mécanisme exact du plantage (§6.1). Les données SMART complètes des 4 disques ont été relevées : aucun n'est défaillant, mais le compteur d'arrêts brutaux du SSD système révèle que l'instabilité est bien antérieure à la réinstallation de Windows (§7).

1. Configuration matérielle

Élément Valeur
Carte mère MSI A320M-A PRO (MS-7C51), BIOS AMI 1.40 du 08/12/2020
Processeur AMD Ryzen 5 2600X — 6 cœurs, 3,6 GHz
Carte graphique AMD Radeon RX 6500 XT (4 Go) — pilote 30.0.14023.3004 du 18/01/2022, soit 4 ans et demi de retard
Mémoire 1 seule barrette 16 Go TEAMGROUP UD4-2666 (DIMM 0, canal B) — cadencée à 2400 MHz (sous sa fréquence nominale de 2666)
Disque système SSD SATA Patriot Burst 240 Go (C: — 71 Go libres)
Disque secondaire HDD SATA Toshiba HDWD110 1 To (D:)
Périphériques USB ASMT 2115 1 To (E:), Seagate Backup+ Hub 8 To (F:), SanDisk 3.2Gen1 64 Go
OS Windows 10 Famille 22H2 — build 19045, installé le 28/10/2025
Boîtier / assemblage Megaport, modèle 130430

Remarque sur l'âge : Julien évalue le PC à 9 ans d'usage intensif. Le Ryzen 2600X date de 2018 et la carte A320M-A PRO de 2019-2020 — le cœur de la machine a donc plutôt 6-7 ans. Le boîtier, l'alimentation et les ventilateurs peuvent être plus anciens s'ils ont été repris d'une configuration précédente. L'alimentation n'a pas pu être identifiée par logiciel — c'est une information à relever physiquement (marque, modèle, wattage, année), elle est déterminante pour la suite du diagnostic.

2. Méthode

Sources exploitées

Sans privilèges particuliers :

Avec élévation (c'est ce qui a permis d'aboutir) :

Outils installés le 2026-08-03

Outil Version Usage
smartmontools 7.5 C:\Program Files\smartmontools\bin\smartctl.exe — SMART réel, à lancer en administrateur
Microsoft.WinDbg 1.2606 Expose de vrais alias console dans %LOCALAPPDATA%\Microsoft\WindowsApps : cdbX64.exe, kdX64.exe, WinDbgX.exe

Analyse d'un vidage en ligne de commande :

cdbX64.exe -z dump.dmp -y "srv*C:\symbols*https://msdl.microsoft.com/download/symbols" -c "!analyze -v; q" -logo sortie.txt

Trois points de méthode qui ont compté

  1. Les événements 41 et 1001 sont horodatés au redémarrage suivant, pas à l'instant du crash. Le redémarrage automatique étant activé (AutoReboot=1), les deux coïncident à la minute près pour les BSOD — mais il ne faut jamais lire ces horodatages comme « l'heure de la panne » sans cette vérification.
  2. Une corrélation temporelle, même serrée, ne vaut pas une preuve. Trois crashes à 12 secondes d'une erreur VBoxNetLwf m'ont fait désigner le mauvais coupable. Seule la lecture du vidage a tranché.
  3. Les preuves les plus utiles sont derrière une élévation de privilèges. Tant qu'on lit le journal en session standard, on tourne autour du problème.

3. Chiffres clés

Indicateur Valeur
Arrêts anormaux (Kernel-Power 41) 45 en 9 mois
dont écrans bleus réels (avec code bugcheck) 15 (33 %)
dont coupures sèches sans BSOD (BugcheckCode = 0) 30 (67 %)
Erreurs matérielles WHEA-Logger 0
Erreurs disque / NTFS critiques (90 j) 2 Ntfs 50, 3 volmgr 161 (échec d'écriture du dump)
Bouton d'alimentation maintenu (arrêt forcé manuel) 1 seul cas — 20/05/2026 20:35
Arrêt propre demandé (1074/13) juste avant le crash 0 cas sur 45
Arrêts brutaux au compteur SMART du SSD système 146 pour 1 066 mises sous tension (13,7 %)

Fréquence : environ 1 arrêt anormal tous les 6 jours en moyenne, avec des grappes (2 crashes le même jour à 5 reprises).

Écart entre les deux compteurs : 146 arrêts brutaux au SMART contre 45 dans le journal Windows. La centaine manquante est antérieure à la réinstallation du 28/10/2025 — voir §7.

4. Deux populations de pannes bien distinctes

Population A — 30 coupures sèches, sans écran bleu (67 %)

BugcheckCode = 0, PowerButtonTimestamp = 0 : le système s'est arrêté sans produire de vérification d'erreur, sans que le bouton d'alimentation ait été maintenu, et sans qu'un arrêt ait été demandé. Le dernier événement journalisé précède le redémarrage de moins d'une minute dans la quasi-totalité des cas.

C'est le profil d'une coupure d'alimentation, d'un reset matériel ou d'un gel total du noyau — Windows n'a pas eu le temps d'écrire quoi que ce soit.

Ces 30 événements sont répartis sur toute la période (octobre 2025 → juillet 2026), sans lien avec les vagues de BSOD. C'est la population la plus préoccupante pour une hypothèse matérielle, et c'est aussi celle sur laquelle les logs sont, par construction, muets.

Population B — 15 écrans bleus avec code d'erreur (33 %)

Code Nb Nom Signification
0x0000009F 10 DRIVER_POWER_STATE_FAILURE Un pilote bloque une requête de changement d'état d'alimentation (mise en veille, reprise, arrêt). Paramètre 1 = 0x3 dans les 10 cas : un objet de périphérique bloque une IRP trop longtemps.
0x00000050 3 PAGE_FAULT_IN_NONPAGED_AREA Accès à une adresse mémoire invalide. Paramètre 2 = 0 → il s'agit d'une lecture (confirmé par WinDbg : AV.Type = Read).
0x0000003B 1 SYSTEM_SERVICE_EXCEPTION Exception 0xC0000005 (violation d'accès) en mode noyau.
0x000000A0 1 INTERNAL_POWER_ERROR Erreur interne du gestionnaire d'alimentation.

12 des 15 BSOD (80 %) sont des erreurs liées à une transition d'alimentation (0x9F + 0xA0). Aucun n'est précédé d'une demande d'arrêt propre → il s'agit de transitions veille S3 / reprise / démarrage rapide, pas d'un arrêt lancé depuis le menu Démarrer.

5. Chronologie — trois régimes successifs

Période Régime dominant
29/10/2025 → 23/12/2025 Uniquement des coupures sèches (2 événements)
25/12/2025 → 29/03/2026 Vague de 10 × 0x9F — DRIVER_POWER_STATE_FAILURE, souvent 2 le même jour, entremêlée de coupures sèches
16/04/2026 → 19/05/2026 1 × 0xA0, 1 × 0x3B — puis les BSOD cessent
19/05/2026 → 28/07/2026 Retour aux seules coupures sèches (7 événements)
31/07/2026 → 03/08/2026 Nouvelle vague : 3 × 0x50 en 4 jours

Les BSOD ne sont donc pas un phénomène continu : ce sont des vagues qui apparaissent et disparaissent, ce qui est le comportement typique d'une cause logicielle (installation ou mise à jour d'un pilote). Les coupures sèches, elles, sont présentes en continu du premier au dernier jour — comportement typique d'une cause matérielle.

6. Cause de la vague en cours : amdfendr.sys (AMD Crash Defender)

6.1 — La preuve : l'analyse du vidage mémoire

!analyze -v sur C:\Windows\Minidump\073126-9718-01.dmp (crash du 31/07/2026 08:54) donne la pile d'appels complète :

nt!KeBugCheckEx
nt!MiSystemFault
nt!MmAccessFault
nt!KiPageFault
nt!LZNT1FindMatchStandard+0xce      <-- instruction fautive
nt!LZNT1CompressChunk+0xd7
nt!RtlCompressBufferLZNT1+0x80
nt!RtlCompressBuffer+0x6f
amdfendr+0x13e1b                    <-- L'APPELANT

MODULE_NAME:        amdfendr
IMAGE_NAME:         amdfendr.sys
FAILURE_BUCKET_ID:  AV_amdfendr!unknown_function
AV.Type:            Read
AV.Page.Virtual:    0xffff830288400000
Adresse fautive:    0xffff830288401000

Le mécanisme est limpide. amdfendr.sys appelle RtlCompressBuffer, la fonction de compression du noyau Windows, en lui passant un tampon dont la taille annoncée dépasse la taille réellement allouée. Le compresseur LZNT1 lit donc au-delà de la fin du tampon, tombe sur une page non mappée, et le noyau plante.

L'adresse fautive …88401000 est exactement à 0x1000 octets (une page mémoire) du début de la page valide …88400000. C'est la signature manuelle du dépassement de tampon : la lecture a franchi la frontière de page juste après la fin de la zone légitime.

Correction d'un point technique de la première version : le déplacement constant 0x3ae que j'avais relevé sur les trois écrans bleus se situe dans ntoskrnl (nt!LZNT1FindMatchStandard+0xce), pas dans amdfendr.sys. C'est pour cette raison qu'il est identique d'un crash à l'autre : c'est toujours la même fonction du noyau qui est mise en défaut. L'intuition — « le même chemin de code plante à chaque fois » — était juste ; son attribution à un pilote tiers ne l'était pas.

Notons enfin que l'horodatage réel du binaire est le 4 juin 2021 — encore plus ancien que sa date de fichier.

6.2 — Confirmation par les rapports WER

Après élévation de privilèges, les deux rapports d'erreur Windows du 31/07/2026 ont pu être lus. Ils contiennent le verdict de Microsoft :

EventType            = BlueScreen
Response.BucketId    = AV_amdfendr!unknown_function
Sig[0] Code          = 50
Sig[3] Paramètre 3   = fffff8031db903ae   /   fffff805091903ae
Sig[4] Paramètre 4   = 2

AV_amdfendr!unknown_function : Access Violation imputée au module amdfendr.sys. Les deux rapports du 31/07, produits indépendamment, aboutissent au même classement — et au même que l'analyse du vidage ci-dessus. Trois déterminations convergentes.

6.3 — Ce qu'est ce pilote

Fichier Description Version Date
amdfendr.sys AMD Crash Defender 21.30.0.9 07/02/2022
amdfendrmgr.sys AMD Crash Defender Manager Driver 21.30.0.9 07/02/2022

AMD Crash Defender est un composant des pilotes Radeon Adrenalin de la génération 21.30 / 22.x. Son rôle est d'intercepter les plantages du pilote graphique pour tenter de rétablir l'affichage sans redémarrer. Autrement dit : c'est le mécanisme censé éviter les écrans bleus qui les provoque.

Ce composant est connu pour être instable dans cette génération de pilotes. AMD l'a profondément remanié dans les versions ultérieures.

Le pilote graphique de cette machine date du 18/01/2022 (version 30.0.14023.3004) pour une Radeon RX 6500 XT — soit quatre ans et demi sans mise à jour, alors que la carte est toujours pleinement prise en charge par les pilotes Adrenalin actuels.

Le pilote graphique est également un candidat classique pour la famille 0x9F (DRIVER_POWER_STATE_FAILURE) : c'est typiquement lui qui bloque une transition de mise en veille ou de reprise. La vague de 10 × 0x9F de l'hiver 2025-2026 pourrait donc relever de la même origine — à confirmer par l'analyse des vidages.

6.4 — Anomalie secondaire : le pilote réseau VirtualBox

VBoxNetLwf — VirtualBox NDIS6 Bridged Networking Driver, version 7.2.14.174565

Le journal System contient 20 erreurs VBoxNetLwf (ID 12) : « Le pilote a détecté une erreur de pilote interne sur \Device\VBoxNetLwf ».

Toutes sont comprises entre le 24/07/2026 06:55 et le 03/08/2026 07:43 — soit exactement depuis l'installation d'Oracle VirtualBox 7.2.14 le 24/07/2026 (fichiers pilotes datés du 17/07/2026). Aucune avant.

Le rythme est de deux erreurs par jour — une le matin, une le soir :

Date Matin Soir
24/07 06:55 18:02
27/07 08:02 18:22
29/07 06:27 17:36
30/07 07:25 19:10
02/08 06:36 21:54

C'est-à-dire à chaque allumage et à chaque extinction — exactement le symptôme décrit par Julien.

Corrélation avec les 3 écrans bleus 0x50 :

Erreur VBoxNetLwf Écran bleu correspondant Écart
31/07/2026 06:27:21 BugCheck 0x50 à 06:27:34 13 s
31/07/2026 08:54:01 BugCheck 0x50 à 08:54:14 13 s
03/08/2026 07:43:26 BugCheck 0x50 à 07:43:37 11 s

Et le 28/07/2026 07:52:02, une erreur VBoxNetLwf coïncide à la seconde près avec une coupure sèche sans BSOD.

Verdict sur VBoxNetLwf : la corrélation temporelle est réelle, mais elle ne fait pas de lui la cause des écrans bleus. Les rapports WER placent le code fautif dans amdfendr.sys. L'explication cohérente est que les deux pilotes sont sollicités à la même seconde, lors de la même transition d'alimentation : VBoxNetLwf y journalise une erreur interne à chaque fois (20 fois), et amdfendr.sys y plante occasionnellement (3 fois).

VBoxNetLwf reste néanmoins un défaut logiciel réel à traiter : un filtre NDIS qui signale une erreur interne à chaque démarrage et à chaque extinction n'est pas un fonctionnement normal. Il a été désactivé (voir §10). Mais il faut être clair : ce n'est pas lui qui provoquait les écrans bleus.

Leçon de méthode : une corrélation temporelle à 12 secondes sur 3 événements, aussi frappante soit-elle, ne vaut pas une preuve. C'est la lecture du rapport WER — qui a nécessité une élévation de privilèges — qui a tranché. La constance du déplacement 0x3ae était bien la bonne piste ; c'est son attribution à VBoxNetLwf qui était fausse.

6.5 — Deux attributions antérieures invalidées

RustDesk — le fichier CLAUDE.md attribuait les écrans bleus 0x50 du 31/07/2026 aux pilotes RustDesk (écran virtuel usbmmidd_v2, imprimante virtuelle), désactivés le jour même. Cette explication ne tient pas : un troisième 0x50 s'est produit le 03/08 avec la même signature, alors que usbmmidd_v2 était désactivé depuis trois jours. Le dossier C:\Program Files\RustDesk\drivers — qui ne contenait déjà plus qu'un RustDeskPrinterDriver.disabled — a été renommé en drivers.disabled par sécurité.

VirtualBox — voir ci-dessus. Suspect n°1 de la première version de cette page, disculpé par les rapports WER.

Ces deux erreurs ont la même origine : trois logiciels installés dans la même fenêtre de temps (VirtualBox le 24/07, RustDesk le 31/07) ont capté l'attention, alors que le vrai coupable était un pilote présent depuis longtemps et sans rapport avec ces installations.

7. Ce que les logs ne permettent PAS d'accuser

Il faut être clair sur ce point : à ce stade, aucune donnée ne désigne un composant électronique défectueux.

Vérification Résultat Interprétation
WHEA-Logger (erreurs machine remontées par le firmware : CPU, mémoire, bus PCIe, cache) 0 événement sur 9 mois Aucune erreur matérielle corrigible ou fatale détectée par le processeur. C'est un signal négatif fort contre une défaillance CPU ou mémoire franche.
État de santé des 5 disques Tous Healthy / OK Aucune alerte
Erreurs disque / NTFS 2 Ntfs 50 + 3 volmgr 161 en 90 jours Les volmgr 161 sont des conséquences des crashes (échec d'écriture du fichier de vidage), pas des causes

Nuance importante sur WHEA : l'absence d'erreur WHEA ne disculpe pas le matériel pour la Population A. Une coupure d'alimentation brutale ou un gel total ne laisse par définition aucune trace, puisque le système n'a plus le temps d'écrire. WHEA ne couvre pas non plus les défaillances d'alimentation, de VRM ou de connectique.

SMART complet — relevé du 2026-08-03 via smartmontools 7.5

Windows n'exposait aucun compteur SMART sur ce chipset A320 (Get-StorageReliabilityCounter ne renvoie rien). smartctl a permis de lire directement les contrôleurs.

Disque Rôle Santé Heures Cycles Secteurs réalloués Erreurs CRC Temp. Usure
Patriot Burst 240 Go (SSD) Système (C:) PASSED 11 111 1 066 0 0 33 °C SSD_Life_Left = 88 % — 15 To écrits
Toshiba HDWD110 1 To (P300 CMR) Données (D:) PASSED 14 481 1 416 0 0 41 °C (max 49) —
Seagate/Samsung ST1000LM024 1 To Boîtier USB (E:) PASSED 60 187 5 800 0 0 39 °C (max 56) —
Seagate ST8000AS0002 8 To (SMR) Sauvegarde USB (F:) PASSED 19 823 2 166 0 0 46 °C (seuil 45 dépassé par le passé) —

Conclusion : aucun disque n'est défaillant. Zéro secteur réalloué, zéro secteur en attente, zéro erreur CRC, aucun journal d'erreurs SMART sur les quatre. Le SSD système conserve 88 % de sa durée de vie et n'a que 15 To d'écriture au compteur — il est hors de cause. L'hypothèse « SSD en fin de vie » est écartée.

Deux points annexes : le disque du boîtier USB affiche 60 187 heures, soit près de 7 ans d'allumage cumulé — sans le moindre défaut, mais il mérite une surveillance. Et le Seagate 8 To de sauvegarde a franchi son seuil de température de flux d'air (46 °C pour un seuil à 45 °C) : à surveiller, sans rapport avec les plantages.

⚠ Réglages du 2026-08-03 effacés par la réinstallation — à réappliquer

Constat du 2026-08-25 : la réinstallation de Windows du 08/08 a remis les valeurs par défaut. État actuel relevé au registre :

Réglage Voulu (03/08) État au 25/08 Effet
HiberbootEnabled (démarrage rapide) 0 1 — réactivé Amplificateur n°1 des 0x9F
MinidumpsCount 50 5 Moins d'historique de vidages
AlwaysKeepMemoryDump 1 absent MEMORY.DMP écrasé à chaque crash

Les deux derniers sont des réglages de diagnostic : sans eux, le prochain écran bleu laissera moins de traces exploitables. À réappliquer en session élevée.

En revanche, deux pilotes suspects ont bel et bien disparu et n'ont pas été réinstallés : VBoxNetLwf.sys (VirtualBox) et les pilotes RustDesk. Seul amdfendr.sys (07/02/2022) est revenu, avec le pilote AMD.

⚠ Le compteur qui change la perspective

Unsafe_Shutdown_Count du SSD système : 146 arrêts brutaux pour 1 066 mises sous tension — soit 13,7 % des extinctions qui se sont mal passées.

Or le journal d'événements ne recense que 45 arrêts anormaux depuis octobre 2025. Une centaine d'arrêts brutaux sont donc antérieurs à la réinstallation de Windows du 28/10/2025.

C'est une information importante : le problème n'est ni récent, ni né de la réinstallation. Il est installé de longue date, et la réinstallation de Windows ne l'a pas réglé — ce qui affaiblit d'autant les hypothèses purement logicielles pour la Population A, et renforce la piste matérielle.

8. Facteurs aggravants identifiés dans la configuration

Démarrage rapide — était activé, ✅ désactivé le 2026-08-03

Le démarrage rapide (Fast Startup, HiberbootEnabled = 1) était actif jusqu'au 03/08/2026. Avec ce réglage, « Arrêter » n'éteint pas réellement Windows : le noyau et les pilotes sont mis en hibernation dans un fichier, puis rechargés tels quels au démarrage suivant.

Conséquences sur ce cas :

  1. C'est la première cause connue des écrans bleus 0x9F — qui représentent 10 des 15 BSOD relevés ici.
  2. Cela explique qu'aucun crash ne soit précédé d'un arrêt propre dans les logs : les transitions concernées sont des hibernations/reprises, pas de vrais arrêts.
  3. Un état de pilote corrompu était réinjecté à chaque démarrage au lieu d'être réinitialisé — ce qui transforme un bug ponctuel en panne récurrente.

Depuis la désactivation, chaque arrêt réinitialise complètement l'état des pilotes. Effet de bord attendu : le démarrage est un peu plus lent — c'est normal et souhaitable ici.

Mémoire : une seule barrette, sous-cadencée

Un seul module de 16 Go occupant DIMM 0 (canal B) — donc pas de double canal, et la barrette tourne à 2400 MHz au lieu de 2666. Ce n'est pas une cause de panne en soi, mais c'est une configuration à connaître. Point positif pour le diagnostic : avec une seule barrette, un test mémoire est simple à interpréter et il n'y a pas de problème d'appairage possible.

BIOS de 2020

Version 1.40 datée du 08/12/2020, jamais mise à jour depuis. MSI a publié des révisions ultérieures pour l'A320M-A PRO, comportant des correctifs AGESA sur la gestion de l'alimentation et la compatibilité mémoire — directement pertinents pour des erreurs 0x9F et 0xA0.

Pilote graphique de 2022 — le facteur central

Pilote Radeon 30.0.14023.3004 du 18/01/2022 sur une RX 6500 XT, alors que la carte est toujours pleinement prise en charge par les Adrenalin actuels. C'est ce pilote qui embarque le amdfendr.sys fautif (binaire du 4 juin 2021). Plus qu'un facteur aggravant : c'est la cause identifiée des 0x50, et un suspect sérieux pour les 0x9F.

Espace disque système

71 Go libres sur 223 Go (C:) — suffisant, mais à surveiller : MEMORY.DMP occupe 2,4 Go, et sa copie de sauvegarde 2,31 Go de plus sur D:. Avec AlwaysKeepMemoryDump = 1 désormais actif, le vidage complet ne sera plus supprimé automatiquement par le nettoyage de disque — c'est voulu, mais cela demande de surveiller l'espace libre.

9. Diagnostic de synthèse

Il y a très probablement deux problèmes distincts, pas un seul.

Révision du 2026-08-25 — le test à variable unique a eu lieu, et il est négatif.

La réinstallation complète de Windows du 2026-08-08 constitue l'expérience que cette page appelait de ses vœux : logiciel intégralement remis à zéro, matériel inchangé. Résultat sur 17 jours de système neuf — 6 arrêts anormaux journalisés, dont 2 d'origine électrique externe établie : une coupure de courant Enedis le 24/08 à 06:24, et un débranchement volontaire face aux orages le 24/08 (journalisé au démarrage du 25/08 à 08:22).

Restent 4 épisodes inexpliqués : 2 coupures sèches sans code (12/08 05:49, 17/08 19:41) et 2 écrans bleus 0x9F (paramètre 0x3, 12/08 à 10:30 et 15:27).

Aucun écran bleu depuis le 12/08, soit 13 jours au 2026-08-25 — sans qu'aucune action n'ait été engagée entre-temps. Cohérent avec le régime par vagues décrit au § 5 : l'accalmie ne vaut pas correction, et ne dispense pas de la priorité 1.

Nuance importante sur les écrans bleus. Dire que « la réinstallation n'a rien réglé » serait faux pour cette population : le vécu est celui d'une amélioration franche, et les chiffres le corroborent — 2 BSOD dans les 4 jours suivant l'installation, puis 13 jours sans aucun. Trois raisons de rester prudent avant d'en conclure à une guérison :

  • Le régime historique est fait de vagues (§ 5) : l'hiver a connu 10 × 0x9F de décembre à mars, puis des mois de calme sans qu'aucune action n'ait été engagée. Treize jours ne suffisent pas à distinguer une correction d'une accalmie.
  • La machine est aujourd'hui dans une configuration moins protégée qu'au 03/08 : le démarrage rapide, désigné comme amplificateur n°1 des 0x9F, a été réactivé par la réinstallation, et amdfendr.sys est revenu avec le pilote AMD que Windows Update réinstalle automatiquement. L'accalmie se produit donc malgré des réglages défavorables.
  • En revanche, deux suspects ont réellement disparu : VBoxNetLwf.sys (VirtualBox) et les pilotes RustDesk (usbmmidd, imprimante virtuelle) sont absents du système neuf, et ni VirtualBox ni RustDesk ne sont réinstallés. Si l'accalmie se confirme au-delà d'un mois, ce sont eux qu'il faudra regarder — et non amdfendr, qui est toujours là.

Ce que la réinstallation établit en revanche sans ambiguïté :

  • Le Problème 2 (coupures sèches) n'a plus aucune explication logicielle plausible. Il a survécu à une reconstruction totale du système. L'hypothèse matérielle — alimentation en tête — passe du statut de conjecture à celui d'explication par défaut. La priorité 3 (intervention physique) devient la priorité réelle.
  • Le Problème 1 n'est pas disculpé pour autant. Windows Update réinstalle exactement le même pilote Radeon 30.0.14023.3004 du 18/01/2022, et amdfendr.sys (binaire du 07/02/2022) est de nouveau en place sur le système neuf. La réinstallation n'a donc pas testé cette variable-là : le pilote fautif est revenu tout seul. L'action de priorité 1 garde tout son sens.
  • La signature 0x9F réapparaît à l'identique — même code, même paramètre 0x3 (périphérique trop lent à honorer un IRP d'alimentation) que la vague de 10 × 0x9F de l'hiver 2025-2026. Ce n'était donc pas un accident de configuration : c'est reproductible sur une installation vierge.

La condition posée au § 10 — « ne pas engager d'intervention physique avant 2-3 semaines de relevés » — est remplie, et par la voie la plus radicale qui soit.

Problème 1 — logiciel, identifié formellement. amdfendr.sys (AMD Crash Defender, version 21.30.0.9 de février 2022) provoque les écrans bleus 0x50. Les rapports WER de Windows le désignent nommément, deux fois indépendamment (AV_amdfendr!unknown_function), et la signature d'adresse constante (0x3ae) confirme un défaut de code reproductible. Il est embarqué dans un pilote Radeon de janvier 2022, jamais mis à jour depuis. Le démarrage rapide amplifiait le phénomène. Ce même pilote est un candidat sérieux pour la vague de 0x9F de l'hiver. C'est traitable immédiatement et sans risque : il suffit d'installer un pilote AMD à jour.

Problème 2 — cause encore indéterminée, présent en continu depuis au moins octobre 2025. 30 coupures sèches réparties sur 9 mois, sans aucune trace exploitable. La vague de 10 × 0x9F de l'hiver 2025-2026 relève probablement aussi d'un pilote (autre que VirtualBox, installé bien plus tard), mais les coupures sèches restent inexpliquées. Les hypothèses ouvertes, par ordre de vraisemblance sur une machine de cet âge :

Le SMART apporte ici un élément décisif : avec 146 arrêts brutaux pour 1 066 démarrages, dont une centaine antérieurs à la réinstallation de Windows, le phénomène est ancien et a survécu à une remise à zéro complète du système. Hypothèses ouvertes, par ordre de vraisemblance :

  1. Qualité du secteur électrique — hypothèse ajoutée le 2026-08-25, désormais en tête. Micro-coupures et creux de tension venant du réseau, et non du bloc d'alimentation. Elle produit exactement la même signature que les hypothèses internes — coupure nette, aucune trace, insensible aux réinstallations de Windows — mais elle dispose de quelque chose qu'aucune autre n'a : des preuves directes.

Sur les 17 jours de suivi, 2 des 6 arrêts sont d'origine électrique externe établie : une coupure Enedis le 24/08 à 06:24, et un débranchement volontaire face aux orages. Autrement dit, le réseau électrique de ce logement a produit au moins un incident avéré en deux semaines et demie. Une installation qui subit des coupures franches subit aussi, statistiquement, des creux plus brefs — trop courts pour être remarqués, largement suffisants pour faire tomber un PC dont l'alimentation n'a plus de marge.

Cela réconcilie aussi les données anciennes : les 146 arrêts brutaux au compteur du SSD et les 30 coupures sèches sur 9 mois n'ont jamais eu d'explication interne convaincante. Un secteur instable les explique toutes, sans supposer de composant défectueux.

Effet de second ordre à ne pas négliger : chaque coupure franche est elle-même un stress pour le matériel — condensateurs, contrôleur du SSD, système de fichiers. Un secteur instable ne se contente pas de provoquer des arrêts, il use la machine et peut fabriquer, à terme, le défaut d'alimentation qu'on cherche par ailleurs.

Action : un onduleur. Il tranche l'hypothèse et la corrige d'un même geste — si les coupures sèches cessent, la cause était le secteur ; si elles persistent, elle est interne. Aucun démontage, aucun risque, matériel utile quoi qu'il arrive, et protection immédiate lors du prochain orage. C'est le test le moins invasif de la liste et il doit passer avant l'intervention physique du § 10 priorité 3.

  1. Alimentation vieillissante — condensateurs fatigués, tension instable sous charge. Hypothèse interne n°1 : composant le plus âgé et le plus sollicité, cohérente avec un problème qui traverse les réinstallations. À noter qu'elle n'est pas exclusive de la précédente — une alimentation fatiguée tient moins bien un creux de tension qu'une neuve, les deux causes se renforcent.
  2. Thermique — pâte thermique sèche après 6-7 ans, ventilateur de CPU encrassé, coupure de protection.
  3. Connectique / oxydation — barrette mémoire, connecteurs d'alimentation, câbles SATA.
  4. Mémoire — moins probable (aucune erreur WHEA), mais non écartée tant qu'un test complet n'a pas été passé.
  5. SSD système — écarté : SMART impeccable, 88 % de durée de vie restante, aucune erreur.

10. Actions recommandées, par ordre de priorité

✅ Déjà appliqué le 2026-08-03 à 08h29

# Action Résultat
1 Filtre VirtualBox NDIS6 Bridged Networking désactivé sur les cartes Ethernet et Ethernet 2 ✅ Enabled = False sur les deux
2 Démarrage rapide désactivé (HiberbootEnabled : 1 → 0) ✅
3 Mini-vidages portés à 50 (MinidumpsCount : 5 → 50) et AlwaysKeepMemoryDump = 1 ✅ Le vidage complet ne sera plus supprimé par le nettoyage de disque
4 C:\Program Files\RustDesk\drivers renommé en drivers.disabled ✅ (ne contenait déjà plus qu'un RustDeskPrinterDriver.disabled)
5 MEMORY.DMP du crash du 03/08 sauvegardé → D:\MEMORY_20260803_0743_bugcheck50.DMP (2,31 Go) ✅ La preuve est préservée du prochain écrasement

Priorité 1 — l'action décisive

# Action Objectif
6 Réinstaller proprement le pilote AMD Radeon. Télécharger l'Adrenalin actuel pour RX 6500 XT sur le site AMD, désinstaller l'ancien avec DDU (Display Driver Uninstaller) en mode sans échec, puis installer le nouveau. Choisir une installation minimale/personnalisée, sans les composants optionnels. Traite la cause identifiée. Remplace amdfendr.sys 21.30.0.9 (2022) par une version où AMD Crash Defender a été remanié. Susceptible de régler à la fois les 0x50 et les 0x9F.

Pourquoi DDU et pas une simple mise à jour : l'installateur AMD ne remplace pas systématiquement les pilotes de la génération 21.30 et peut laisser amdfendr.sys en place. DDU garantit une table rase.

Priorité 2 — confirmer et combler les angles morts

# Action Objectif
7 Installer WinDbg et analyser le vidage ✅ Fait le 03/08 à 09h00 — voir §6.1. Verdict confirmé et mécanisme établi
8 Installer smartmontools et relever le SMART ✅ Fait le 03/08 à 09h00 — voir §7. Aucun disque défaillant
9 Test mémoire complet : MemTest86 sur clé USB, au moins 4 passes complètes, de préférence une nuit entière. L'outil intégré à Windows est insuffisant. Écarte ou confirme la RAM de façon définitive. Simple ici : une seule barrette.
10 Mettre à jour le BIOS MSI A320M-A PRO (actuel : 1.40 de 2020). Correctifs AGESA sur la gestion d'alimentation, directement liés aux 0x9F/0xA0

Priorité 3 — intervention physique, pour la Population A

À n'engager qu'après avoir traité le pilote AMD et laissé passer deux ou trois semaines de relevés : si les coupures sèches s'arrêtent aussi, cette section devient inutile.

# Action Objectif
11 Relever les références de l'alimentation (marque, modèle, wattage, année). Information manquante et déterminante
12 Dépoussiérer : ventilateur et radiateur CPU, ventilateur de la carte graphique, ventilateurs de boîtier, filtres, bloc d'alimentation. Cause thermique
13 Réextraire et réinsérer la barrette mémoire et les connecteurs d'alimentation ATX 24 broches et EPS 8 broches. Nettoyer les contacts. Cause connectique / oxydation
14 Refaire la pâte thermique du processeur si elle n'a pas été changée depuis l'assemblage. Cause thermique
15 Surveiller les températures et les tensions en fonctionnement (HWiNFO64), en particulier les rails 12 V, 5 V et 3,3 V sous charge. Détecte une alimentation qui décroche
16 Si les coupures sèches persistent après tout ce qui précède : tester avec une autre alimentation. Test décisif de l'hypothèse n°1. À noter : la RX 6500 XT est peu gourmande (~107 W), mais une alimentation fatiguée décroche sur les pics de la carte graphique

11. Limites de cette analyse

À mentionner pour que les conclusions soient lues à leur juste valeur :

12. Journal des relevés

Un relevé toutes les 1 à 2 semaines suffit à mesurer l'effet des actions engagées. Le script ajoute automatiquement une ligne à ce tableau :

powershell -ExecutionPolicy Bypass -File "D:\Syncthing\Jux_univers\Jux-scripts\PC-Health\collect_bsod.ps1"

À lancer en administrateur pour que les compteurs SMART soient lus ; sinon la ligne est écrite sans eux. L'option -DryRun affiche le résultat sans rien écrire dans BookStack. Le script relève les arrêts anormaux, les codes bugcheck, les erreurs VBoxNetLwf, les erreurs WHEA, la version du pilote AMD (pour dater sa réinstallation), et signale tant que amdfendr 21.30 est en place.

La colonne « Actions faites depuis » est à compléter à la main.

Date du relevé Arrêts anormaux depuis le dernier relevé dont BSOD Codes rencontrés Erreurs VBoxNetLwf WHEA Actions faites depuis Observations
2026-08-03 45 (cumul 9 mois) 15 10×9F, 3×50, 1×3B, 1×A0 20 0 — (état initial) Analyse initiale. Deux populations distinctes. Cause des 0x50 établie par analyse du vidage : amdfendr.sys déborde un tampon sur RtlCompressBuffer. Actions 1 à 5 + 7 + 8 faites. SMART : 4 disques sains, mais 146 arrêts brutaux au compteur du SSD → problème antérieur à la réinstallation.
2026-08-25 4 inexpliqués / 6 journalisés (17 jours, système neuf) 2 2×9F (param. 0x3) n/c n/c Windows réinstallé le 2026-08-08 — profil eliob perdu, profil julie créé Relevé par Get-WinEvent (ID 41/6008/1001), session non élevée donc SMART non lu. Épisodes : 12/08 05:49, 12/08 10:30 (9F), 12/08 15:27 (9F), 17/08 19:41, puis deux épisodes d'origine électrique externe confirmée — 24/08 06:24 coupure de courant Enedis, et 25/08 08:22 qui journalise le débranchement volontaire du 24/08 (orages ; l'arrêt sale est écrit au démarrage suivant). Aucun BSOD depuis le 12/08. Système neuf sans effet sur les deux populations. Pilote AMD revenu en 30.0.14023.3004 (18/01/2022) par Windows Update, amdfendr.sys du 07/02/2022 réinstallé. Test à variable unique négatif → priorité déplacée vers le matériel (§ 9).

⚠ Attention au compteur SMART depuis le 2026-08-25 : Unsafe_Shutdown_Count est un compteur du SSD, pas de Windows — il n'a donc pas été remis à zéro par la réinstallation et reste directement comparable au relevé du 2026-08-03. C'est aujourd'hui le meilleur indicateur disponible pour la Population A : l'écart attendu depuis le 03/08 est d'environ 6. À relever en session élevée au prochain passage.

Référence — état au 2026-08-03 : SSD système 11 111 h / 1 066 cycles / 146 arrêts brutaux / 88 % de vie restante. Comparer Unsafe_Shutdown_Count d'un relevé à l'autre donne un compteur de coupures indépendant du journal Windows :

& 'C:\Program Files\smartmontools\bin\smartctl.exe' -A /dev/pd0

13. Indicateur de succès

Le suivi doit permettre de trancher entre les deux problèmes :

Point de vigilance sur la carte graphique : c'est le composant qui concentre désormais le plus de signaux. Si des artefacts visuels, des écrans noirs momentanés ou des gels pendant un jeu ou une vidéo apparaissent, il faut le noter dans le journal — ce serait l'indice d'un défaut matériel de la RX 6500 XT.

Deuxième indicateur, indépendant du journal Windows : l'écart de Unsafe_Shutdown_Count entre deux relevés. Il compte les coupures réelles même quand Windows n'a rien pu journaliser — donc il capte la Population A, celle qui est invisible autrement. C'est le chiffre à surveiller pour trancher la question matérielle.

14. Fichiers et emplacements

Quoi Où
Script de relevé D:\Syncthing\Jux_univers\Jux-scripts\PC-Health\collect_bsod.ps1 (Syncthing, disponible sur toutes les machines)
Vidage du crash du 03/08, sauvegardé D:\MEMORY_20260803_0743_bugcheck50.DMP (2,31 Go)
Mini-vidage exploitable du 31/07 C:\Windows\Minidump\073126-9718-01.dmp (1,1 Mo) — accès administrateur
Vidages suivants C:\Windows\Minidump\ — 50 conservés désormais (au lieu de 5)
smartctl C:\Program Files\smartmontools\bin\smartctl.exe
Débogueur console cdbX64.exe (dans le PATH via %LOCALAPPDATA%\Microsoft\WindowsApps)
Contexte projet CLAUDE.md du dépôt Claude-pcelio+jux, section « Stabilité du PC Windows (poste julie, ex-eliob) »

Page tenue à jour par Claude Code. Analyse initiale et investigation complète le 2026-08-03. Révision du 2026-08-25 : réinstallation de Windows sans effet, priorité déplacée vers le matériel.

Relevé du 2026-09-03 — pilote AMD mis à jour

L'action en attente depuis le 2026-08-03 est exécutée.

Avant Après
Pilote graphique 30.0.14023.3004 du 18/01/2022 32.0.21045.5002 du 17/08/2026
amdfendr.sys actif 21.30.0.9 (07/02/2022) 25.10.0.7 (25/02/2026)
amdpsp.sys 5.24.0.0 5.46.0.0

Méthode : AMD Software Adrenalin Edition 26.8.1 WHQL, paquet complet de 942 Mo depuis amd.com, Factory Reset coché, installation Driver Only (la suite Adrenalin, l'enregistrement vidéo et l'AI Bundle ont été écartés — ce dernier est un mode d'échec connu de l'installeur). Point de restauration 11 créé au préalable, non utilisé. Aucun incident pendant l'opération.

La cause établie des écrans bleus 0x50 est donc corrigée : amdfendr.sys (AMD Crash Defender) passe de la version de février 2022 à celle de février 2026.

⚠ Ne pas se fier au fichier dans System32\drivers

C:\Windows\System32\drivers\amdfendr.sys affiche toujours 21.30.0.9 du 07/02/2022 après la mise à jour. C'est un résidu inutilisé. Le pilote réellement chargé est celui que désigne le service :

(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\amdfendr').ImagePath
# -> ...\DriverStore\FileRepository\amdfendr.inf_amd64_bea53a1d416fbcfa\amdfendr.sys  (v25.10.0.7)

Le script collect_bsod.ps1 doit être corrigé sur ce point — fait le 2026-09-03 : s'il lit le fichier de System32\drivers, il continuera de signaler la version 21.30 à tort.

Ce que cette mise à jour ne traite pas

Les 30 coupures sèches (BugcheckCode = 0, aucune trace exploitable) restent hors périmètre. Elles sont réparties en continu sur toute la période, ont survécu à la réinstallation complète de Windows d'octobre 2025, et le compteur SMART du SSD en recense une centaine antérieures à celle-ci. Hypothèse en tête : qualité du secteur électrique, qu'un onduleur trancherait sans démontage.

Si des coupures sèches persistent dans les semaines qui viennent, ce n'est pas un échec de cette intervention — c'est au contraire l'élément qui isolerait définitivement les deux populations.

Suite

Relancer Jux-scripts\PC-Health\collect_bsod.ps1 (en élevé) dans deux à trois semaines. Attendu : plus aucun 0x50, et une réponse sur la persistance ou non des coupures sèches.

Détail complet de l'intervention : page 295. Effets sur l'émulateur Android : page 282.

Correction de collect_bsod.ps1 (2026-09-03)

Deux défauts corrigés, sauvegarde collect_bsod.ps1.bak-260903 :

1. Il lisait le mauvais fichier. C:\Windows\System32\drivers\amdfendr.sys reste périmé après une mise à jour de pilote. Le script lit désormais l'ImagePath du service, résout \SystemRoot\ et rapporte la version réellement chargée. Il affiche maintenant la version quelle qu'elle soit, au lieu de ne signaler que la 21.30.

2. Get-WinEvent faisait planter le script. Le fournisseur VBoxNetLwf n'existe plus depuis la réinstallation de Windows, et Get-WinEvent -FilterHashtable lève alors une erreur que -ErrorAction SilentlyContinue ne supprime pas. Les deux appels passent par une fonction Compter-Evenements avec try/catch et -ErrorAction Stop — le seul moyen fiable de rendre l'échec non fatal.

Premier relévé après correction

Periode : 2026-08-25 -> 2026-09-03
Arrets anormaux : 6 | BSOD : 0 | VBoxNetLwf : 0 | WHEA : 0
pilote AMD 32.0.21045.5002 ; amdfendr 25.10.0.7
demarrage rapide TOUJOURS actif

⚠ Ce relévé ne mesure PAS encore l'effet du nouveau pilote : la fenêtre couvre le 25/08 au 03/09, alors que la mise à jour date du 03/09 au matin. C'est une référence de départ, pas un résultat.

Deux points à relever tout de même :

Revision #13
Created 2026-08-03 06:05:41 UTC by Julien
Updated 2026-09-03 05:48:57 UTC by Julien