# 04_Claude et le PC Windows Elio+Jux

# 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) — 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** :
- Journal `System` — `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`)
- Inventaire matériel WMI/CIM, configuration d'alimentation et de vidage mémoire, dates et versions des pilotes tiers

**Avec é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 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.

### ⚠ 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.**

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

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

**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** → analyser le nouveau vidage sous WinDbg (les mini-vidages sont maintenant conservés, 50 au lieu de 5), 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.

**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 eliob » |

---

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