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 (Windows réinstallé le 28/10/2025, le journal ne remonte pas plus loin)
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.syset 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ées sur le poste, sans installation d'outil tiers :
- Journal
System— événementsKernel-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/13juste 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
Point de méthode important : les événements 41 et 1001 sont horodatés au redémarrage suivant, pas à l'instant du crash. Comme le redémarrage automatique est 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.
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 |
Fréquence : environ 1 arrêt anormal tous les 6 jours en moyenne, avec des grappes (2 crashes le même jour à 5 reprises).
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 àVBoxNetLwfqui é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 = 1)
Le démarrage rapide (Fast Startup) est actif. 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 :
- C'est la première cause connue des écrans bleus
0x9F— qui représentent 10 des 15 BSOD relevés ici. - 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.
- Un état de pilote corrompu (celui de
VBoxNetLwf, par exemple) est réinjecté à chaque démarrage au lieu d'être réinitialisé — ce qui transforme un bug ponctuel en panne récurrente.
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.
Espace disque système
71 Go libres sur 223 Go (C:) — suffisant, mais à surveiller : le fichier MEMORY.DMP occupe à lui seul 2,4 Go.
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 :
- 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.
- Thermique — pâte thermique sèche après 6-7 ans, ventilateur de CPU encrassé, coupure de protection.
- Connectique / oxydation — barrette mémoire, connecteurs d'alimentation, câbles SATA.
- Mémoire — moins probable (aucune erreur WHEA), mais non écartée tant qu'un test complet n'a pas été passé.
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.sysen place. DDU garantit une table rase.
Priorité 2 — confirmer et combler les angles morts
| # | Action | Objectif |
|---|---|---|
| ✅ Fait le 03/08 à 09h00 — voir §6.1. Verdict confirmé et mécanisme établi | ||
| ✅ 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 bleus0x9Fde l'hiver — leur attribution àamdfendrreste 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
amdfendrplante (dépassement de tampon surRtlCompressBuffer), 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.dmpdu 03/08, deux du 31/07) — cohérent avec les erreursvolmgr 161: Windows n'a pas réussi à écrire le vidage. Seul073126-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 suffire à mesurer l'effet des actions engagées.
| 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. |
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 → il faut l'analyse du vidage sous WinDbg (action 7) pour trouver le déclencheur, et l'hypothèse d'une carte graphique défaillante (et non plus seulement de son 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 XT et non plus d'un simple problème de pilote.
Page tenue à jour par Claude Code. Analyse initiale du 2026-08-03.