Skip to main content

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

Suivi des dysfonctionnements du PC eliob — écrans bleus

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,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 journalpilote neAMD remonteavec pasDDU. plus30 loin)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 interrogéesexploitées

    sur

    Sans leprivilèges poste, sans installation d'outil tiersparticuliers :

    • Journal System — événements Kernel-Power 41 (arrêt inattendu), BugCheck 1001 (code d'erreur BSOD), WHEA-Logger (erreurs matérielles remontées par le firmware), volmgr, Ntfs, disk
    • Propriétés internes des événements 41 (BugcheckCode, BugcheckParameter1, PowerButtonTimestamp) — ce sont elles qui permettent de distinguer un vrai BSOD d'une coupure sèche
    • Corrélation temporelle événement par événement (dernier événement journalisé avant chaque redémarrage, présence ou non d'un arrêt propre 1074/13 juste avant))
    • Inventaire matériel WMI/CIM, état SMART exposé par Windows, configuration d'alimentation et de vidage mémoire, dates et versions des pilotes tiers

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

      Rapports WER (C:\ProgramData\Microsoft\Windows\WER\ReportArchive) — contiennent le classement de la panne par Microsoft Mini-vidages (C:\Windows\Minidump) et MEMORY.DMP SMART complet des disques via smartctl

      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 importantqui :ont lescompté

        Les événements 41 et 1001 sont horodatés au redémarrage suivant, pas à l'instant du crash. Comme leLe redémarrage automatique esté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. 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é. 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.

        ⚠ 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 activé— (HiberbootEnabledétait =activé, 1)✅ désactivé le 2026-08-03

        Le démarrage rapide (Fast Startup)Startup, estHiberbootEnabled actif.= 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 directes 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 (celui de VBoxNetLwf, par exemple) esté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 : le fichier MEMORY.DMP occupe à lui seul 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.

        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. Alimentation vieillissante — condensateurs fatigués, tension instable sous charge. C'est l'hypothèse n°1 pour des coupures nettes sans trace, c'est le composant le plus âgé et le plus sollicité, et c'est cohérent avec un problème qui traverse les réinstallations de Windows.
        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 :

        • Le journal d'événements ne remonte qu'au 29/10/2025 (réinstallation de Windows la veille). Le compteur SMART Unsafe_Shutdown_Count (146) permet toutefois d'affirmer que le phénomène est bien antérieur — mais sans en connaître ni la chronologie ni la nature.
        • Un seul vidage a pu être analysé (31/07 08:54). Il concerne un 0x50. Aucun vidage exploitable n'existe pour les 10 écrans bleus 0x9F de l'hiver — leur attribution à amdfendr reste une hypothèse plausible, pas un fait établi.
        • Aucune donnée de température ni de tension en fonctionnement n'est disponible sans capteur logiciel dédié (HWiNFO64). Les températures SMART relevées sont celles des disques, pas du processeur ni de la carte graphique.
        • Le déclencheur reste inconnu : on sait comment amdfendr plante (dépassement de tampon sur RtlCompressBuffer), pas pourquoi cela n'arrive que 3 fois sur des dizaines de transitions.
        • Trois des quatre mini-vidages présents font 0 octet (080326-9906-01.dmp du 03/08, deux du 31/07) — cohérent avec les erreurs volmgr 161 : Windows n'a pas réussi à écrire le vidage. Seul 073126-9718-01.dmp (31/07 08:54, 1,1 Mo) est exploitable. Cette difficulté récurrente à écrire un vidage est en soi un signal : elle peut trahir un problème d'accès au disque système au moment du crash.
        • La cause des 30 coupures sèches reste entièrement ouverte. Rien dans les logs ne permet de la désigner, par construction.

        12. Journal des relevés

        À compléter à chaque passage. Un relevé toutes les 1 à 2 semaines devrait suffiresuffit à 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-03 1 1 1x0x50 1 0 (a completer) pilote AMD 30.0.14023.3004 ; amdfendr 21.30 TOUJOURS en place ; SSD: 146 arrets brutaux / 1066 cycles, vie restante 88 %

        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 :

        • Si les écrans bleus cessent après la réinstallation du pilote AMD mais que les coupures sèches continuent → le problème logiciel est réglé, le problème matériel est confirmé et isolé. On passe à la priorité 3.
        • Si tout cesse → la cause était entièrement logicielle, et l'hypothèse du composant défectueux tombe. Un pilote graphique instable peut en effet provoquer aussi bien des écrans bleus que des gels totaux sans trace.
        • Si les écrans bleus persistent malgré un pilote AMD à jour → ilanalyser fautle l'analyse dunouveau vidage sous WinDbg (actionles 7)mini-vidages poursont trouvermaintenant leconservés, déclencheur,50 au lieu de 5), et l'hypothèse d'une carte graphique défaillante (— et non plus seulement de son pilote)pilote — devient sérieuse.

        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 XTXT.

        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 nonemplacements

        plus
        d'unsimpleproblèmeQuoi Où Script de pilote.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 eliob »

        Page tenue à jour par Claude Code. Analyse initiale duet investigation complète le 2026-08-03.

        Back to top