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.

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é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

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 4 = `0x2` : la faute survient sur une tentative d'exécution de code, pas une lecture/écriture de données.
`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. Suspect principalCause de la vague en cours : `amdfendr.sys` (AMD Crash Defender)

6.1 — La preuve : 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 se lit ainsi : Access Violation survenue dans le module amdfendr.sys. Les deux rapports, indépendants, aboutissent au même classement. L'adresse d'instruction fautive que j'avais relevée (déplacement 0x3ae, identique dans les trois écrans bleus) tombe donc à l'intérieur de amdfendr.sys — ce qui explique enfin pourquoi elle est constante d'un crash à l'autre.

6.2 — 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.3 — 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.

~~Élément~~Verdict ~~technique~~sur ~~qui renforce fortement l'hypothèse~~VBoxNetLwf : ~~les~~la ~~trois~~corrélation 0x50temporelle ~~partagent~~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 ~~même~~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 ~~dans~~était ~~l'adresse~~bien ~~d'instruction fautive~~ (…3c5903ae, …1db903ae, …091903ae~~), pour des adresses de base différentes. Autrement dit :~~ la ~~même~~bonne ~~ligne~~piste de; ~~code~~c'est ~~d'un~~son ~~même pilote plante~~attribution à ~~chaque fois~~~~, à une adresse de chargement différente selon le démarrage. C'est la signature d'un~~ ~~défaut logiciel reproductible~~~~, et non d'une cellule mémoire défectueuse — une RAM défaillante produirait des adresses dispersées et aléatoires.~~

VBoxNetLwf ~~est~~qui unétait ~~filtre NDIS léger : il s'insère dans la pile réseau et est sollicité à chaque transition d'alimentation. C'est un candidat cohérent à la fois pour les~~ 0x50 ~~récents et, dans son principe, pour la famille~~ 0x9F.fausse.

Correction6.4 d'une— attributionDeux antérieureattributions antérieures invalidées

LeRustDesk — le fichier CLAUDE.md ~~attribue~~attribuait les écrans bleus 0x50 du 31/07/2026 aux pilotes RustDesk (écran virtuel usbmmidd_v2 et, imprimante virtuelle), désactivés le jour ~~même~~même. ~~par renommage en~~ .disabled.

Cette explication ne tient ~~plus~~pas : un ~~quatrième~~troisième 0x50 s'est produit le 03/~~08/2026 à 07:43~~,08 avec la même ~~signature~~ 0x3ae,signature, alors que usbmmidd_v2 était désactivé depuis trois jours. LaLe ~~désactivation~~dossier ~~des~~C:\Program pilotesFiles\RustDesk\drivers ~~RustDesk~~— n'qui ne contenait déjà plus qu'un RustDeskPrinterDriver.disabled — a ~~donc~~été renommé en drivers.disabled par sécurité.

~~pas~~VirtualBox ~~résolu~~— levoir ~~problème.~~ci-dessus. ~~Les~~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 ~~ayant été~~ installés dans la même fenêtre de temps (VirtualBox le 24/07, RustDesk le 31/07), laont ~~coïncidence~~capté del'attention, ~~dates~~alors ~~avait masqué~~que le vrai ~~suspect.~~coupable Àétait ~~noter~~un ~~toutefois que le dossier~~ C:\Program Files\RustDesk\drivers ~~est~~ ~~toujours~~pilote présent depuis longtemps et ~~n'a~~sans ~~pas~~rapport ~~été~~avec ~~désactivé.~~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
Prédiction de panne SMART (WMI)	Aucune remontée	Voir la limite ci-dessous
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.

Limite sur SMART : Windows n'expose aucun compteur SMART pour ces disques via l'API standard (Get-StorageReliabilityCounter ne renvoie rien, y compris la température, les heures de fonctionnement et les secteurs réalloués). Le contrôleur SATA du chipset A320 ne relaie pas ces données. L'état réel du SSD Patriot Burst — notamment son taux d'usure et ses secteurs réalloués — est donc à ce jour inconnu. C'est une lacune à combler en priorité : ce SSD est le disque système, c'est un modèle d'entrée de gamme, et une usure avancée expliquerait des gels au démarrage.

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, ~~actif en ce moment,~~ identifié ~~avec~~formellement. unamdfendr.sys ~~bon~~(AMD ~~niveau~~Crash Defender, version 21.30.0.9 de ~~confiance.~~février Le2022) ~~pilote~~provoque ~~réseau~~ VBoxNetLwf ~~de VirtualBox 7.2.14 échoue à chaque transition d'alimentation depuis son installation le 24/07/2026, et a provoqué 3~~les écrans bleus 0x50. enLes 4rapports ~~jours.~~WER Lade Windows le désignent nommément, deux fois indépendamment (AV_amdfendr!unknown_function), et la signature d'adresse ~~identique~~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 ~~amplifie~~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.~~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 :

Alimentation vieillissante — condensateurs fatigués, tension instable sous charge. C'est l'hypothèse n°1 pour des coupures nettes sans trace, et c'est le composant le plus âgé et le plus sollicité de la machine.
Thermique — pâte thermique sèche après 6-7 ans, ventilateur de CPU encrassé, coupure de protection.
SSD système — un Patriot Burst d'entrée de gamme en fin de vie peut provoquer des gels totaux au démarrage. État actuellement inconnu, faute de données SMART.
Connectique / oxydation — barrette mémoire, connecteurs d'alimentation, câbles SATA. Neuf ans de poussière.
Mémoire — moins probable (aucune erreur WHEA, signature 0x50 non aléatoire), mais non écartée tant qu'un test complet n'a pas été passé.

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 — sansl'action risque, à faire tout de suitedécisive

#	Action	Objectif
16	~~Désactiver~~Réinstaller proprement le ~~filtre~~pilote ~~réseau~~AMD ~~VirtualBox~~Radeon. :Télécharger ~~décocher~~l'Adrenalin «actuel ~~VirtualBox~~pour ~~NDIS6~~RX ~~Bridged~~6500 ~~Networking~~XT sur le site AMD, désinstaller l'ancien avec DDU (Display Driver »Uninstaller) ~~dans~~en mode sans échec, puis installer le nouveau. Choisir une installation minimale/personnalisée, sans les ~~propriétés~~composants ~~de la carte réseau. Si VirtualBox n'est pas utilisé au quotidien, le désinstaller purement et simplement.~~

~~Traite le suspect n°1 de la vague en cours~~ 2optionnels. ~~Désactiver le démarrage rapide~~ ~~: Panneau de configuration → Options d'alimentation → « Choisir l'action des boutons » → décocher « Activer le démarrage rapide ».~~ ~~Supprime~~Traite la cause ~~n°1~~identifiée. ~~des~~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 ~~et évite de réinjecter un état de pilote corrompu à chaque démarrage~~ 3 ~~Activer les mini-vidages mémoire~~ ~~en complément du vidage noyau (~~MinidumpsCount ~~→ 50)~~. ~~Aujourd'hui seul~~ MEMORY.DMP ~~est écrit et~~ ~~il est écrasé à chaque crash~~ ~~: l'historique des dumps est perdu. Sans mini-vidages, chaque nouveau crash détruit la preuve du précédent.~~ 4 ~~Désactiver aussi le dossier~~ C:\Program Files\RustDesk\drivers~~, resté actif.~~ ~~Écarter définitivement la piste RustDesk~~

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 — nécessiteconfirmer uneet installationcombler oules unangles redémarragemorts

#	Action	Objectif
57

Installer WinDbg (winget install Microsoft.WinDbg) et analyser avec !analyze -v le mini-vidage C:\Windows\Minidump\073126-9718-01.dmp (1,1 Mo, valide) ou D:\MEMORY_20260803_0743_bugcheck50.DMP. Confirme le verdict WER et donne la pile d'appels complète — utile pour savoir ce qui déclenche amdfendr 8 Installer smartmontools (winget install smartmontools) et relever le SMART complet du SSD Patriot Burst et du HDD Toshiba : heures de fonctionnement, usure, secteurs réalloués, erreurs CRC. Comble la principale lacune du diagnostic. Windows n'expose rien ; c'est la seule façon de savoir si le SSD système est en fin de vie. 6 ~~Installer WinDbg~~ (winget install Microsoft.WinDbg~~) et analyser~~ C:\Windows\MEMORY.DMP ~~(2,4 Go, crash du 03/08 07:43) avec~~ !analyze -v. ~~Passe de « suspect fortement corrélé » à « coupable nommé »~~ ~~: le dump contient le nom exact du module fautif. C'est l'étape qui authentifie formellement la cause.~~ 79 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. 810 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
911	Relever les références de l'alimentation (marque, modèle, wattage, année).	Information manquante et déterminante
1012	Dépoussiérer : ventilateur et radiateur CPU, ventilateur de la carte graphique, ventilateurs de boîtier, filtres, bloc d'alimentation.	Cause thermique
1113	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
1214	Refaire la pâte thermique du processeur si elle n'a pas été changée depuis l'assemblage.	Cause thermique
1315	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
1416	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°11. À 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 :

L'historique ne remonte qu'au 29/10/2025 (réinstallation de Windows la veille). Les 9 années d'usage antérieures sont invisibles. On ne sait pas si le problème est ancien ou récent.
LeLes ~~vidage~~vidages mémoire dun'ont ~~03/08 n'a~~toujours pas été ~~analysé~~analysés : WinDbg n'est pas ~~installé~~installé. Le verdict amdfendr vient du classement automatique de Windows (Response.BucketId), qui identifie le module contenant l'adresse fautive. C'est un signal fort et convergent sur ladeux ~~machine.~~rapports VBoxNetLwfindépendants, mais l'analyse du vidage reste ~~donc~~à unfaire ~~suspect~~pour ~~corrélé~~,obtenir ~~pas~~la unpile ~~coupable~~ ~~prouvé~~.

~~Le dossier~~ C:\Windows\Minidumpd'appels et ~~les~~comprendre ~~rapports~~le ~~WER sont inaccessibles~~ ~~sans élévation de privilèges. Deux rapports~~ Kernel_50 ~~du 31/07 n'ont pas pu être lus.~~déclencheur. Aucune donnée SMART réelle n'a pu être obtenue (voir §7). Aucune donnée de température ni de tension n'est disponible sans capteur logiciel dédié. LaTrois ~~corrélation~~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 VBoxNetLwfvolmgr 161 ↔: Windows n'a pas réussi à écrire le vidage. Seul 0x50073126-9718-01.dmp (31/07 08:54, 1,1 Mo) est ~~temporellement très forte, mais l'erreur~~ VBoxNetLwf ~~se produit~~exploitable. Cette difficulté récurrente à ~~chaque~~écrire ~~transition~~un ~~(20~~vidage ~~fois) alors que seuls~~ 3 ~~crashes~~est en ~~ont~~soi ~~résulté. Le pilote est donc~~ un ~~facteur nécessaire mais pas suffisant~~signal : ilelle ~~faut~~peut ~~probablement~~trahir un ~~déclencheur~~problème ~~supplémentaire~~d'accès ~~(charge,~~au ~~séquence,~~disque ~~état)~~système ~~pour~~au ~~que~~moment ~~l'erreur~~du ~~dégénère~~crash. enLa ~~écran~~cause ~~bleu.~~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 identifiées.

Cause des ~~2026-08-03~~ 1 1 1x0x50 établie : amdfendr.sys. Actions 1 0à (a5 ~~completer)~~appliquées ~~demarrage~~le ~~rapide~~jour ~~TOUJOURS actif ; filtre VBoxNetLwf TOUJOURS actif~~même.

13. Indicateur de succès

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

Si les ~~BSOD~~écrans bleus cessent après ~~les~~la ~~actions~~réinstallation dedu ~~priorité~~pilote 1AMD 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.~~logicielle, L'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 ~~BSOD~~écrans bleus persistent malgré un pilote AMD à jour → il faut lel'analyse ~~dump~~du ~~analysé~~vidage sous WinDbg (action 6)7) pour ~~nommer~~trouver le ~~module~~déclencheur, ~~fautif.~~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.