# 04_Claude et les dépannages informatiques

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

# Suivi des dysfonctionnements du PC eliob — écrans bleus

> **⚠ Mise à jour du 2026-08-25 — après réinstallation de Windows : les écrans bleus ont quasiment cessé, les coupures sèches non.**
>
> Deux précisions qui modifient la lecture de toute cette page :
>
> **1. `eliob` et `julie` sont la même machine.** Le poste décrit ici n'a pas disparu : Windows y a été **réinstallé le 2026-08-08 à 12:21**, précisément à cause des plantages analysés dans cette page. Le compte `eliob` ayant perdu ses identifiants, un nouveau profil a été créé à 12:36 sous le nom **`julie`** (faute de frappe pour `julien`), adossé au compte Microsoft `julien.bertrand@live.fr`. C'est le seul profil de la machine. Matériel identique vérifié le 2026-08-25 : MSI A320M-A PRO (MS-7C51), BIOS 1.40 du 08/12/2020, Ryzen 5 2600X, une seule barrette 16 Go à 2400 MHz, RX 6500 XT.
>
> **2. Les deux populations ont divergé, et c'est le fait nouveau le plus important.**
>
> - **Écrans bleus : amélioration nette et vécue comme telle.** Ils étaient incessants avant la réinstallation — 3 × `0x50` en 4 jours du 31/07 au 03/08. Depuis le système neuf : 2 × `0x9F` le 12/08, puis **plus rien pendant 13 jours**.
> - **Coupures sèches : inchangées.** Elles ont traversé la reconstruction complète du système. Mais 2 des 6 arrêts de la période sont d'**origine électrique externe établie** — coupure Enedis le 24/08 à 06:24, débranchement volontaire face aux orages — ce qui fait passer la **qualité du secteur** en tête des hypothèses. Restent **4 épisodes inexpliqués**.
>
> **3. Les mesures du 2026-08-03 ont été effacées par la réinstallation** — voir § 8 et § 10. Le démarrage rapide est **de nouveau actif**, la rétention des vidages est retombée à 5. À réappliquer.
>
> Voir le journal (§ 12) et la révision du diagnostic (§ 9).

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

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

> **Mise à jour du 2026-08-03, 08h30** — après élévation de privilèges, les rapports WER ont pu être lus et **désignent nommément le module fautif : `amdfendr.sys` (AMD Crash Defender)**. Le pilote réseau VirtualBox, suspect n°1 de la première version de cette analyse, est **disculpé** comme cause des écrans bleus. Voir §6.
>
> **Mise à jour du 2026-08-03, 09h00** — WinDbg et smartmontools installés. **Le vidage mémoire a été analysé : la pile d'appels confirme `amdfendr.sys` et donne le mécanisme exact du plantage** (§6.1). Les données SMART complètes des 4 disques ont été relevées : **aucun n'est défaillant**, mais le compteur d'arrêts brutaux du SSD système révèle que **l'instabilité est bien antérieure à la réinstallation de Windows** (§7).

---

## 1. Configuration matérielle

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

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

---

## 2. Méthode

### Sources exploitées

**Sans privilèges particuliers** :
- 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.

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

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

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

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

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

### ⚠ Le compteur qui change la perspective

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

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

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

---

## 8. Facteurs aggravants identifiés dans la configuration

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

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

Conséquences sur ce cas :

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

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

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

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

### BIOS de 2020

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

### Pilote graphique de 2022 — le facteur central

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

### Espace disque système

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

---

## 9. Diagnostic de synthèse

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

> **Révision du 2026-08-25 — le test à variable unique a eu lieu, et il est négatif.**
>
> La réinstallation complète de Windows du 2026-08-08 constitue l'expérience que cette page appelait de ses vœux : **logiciel intégralement remis à zéro, matériel inchangé**. Résultat sur 17 jours de système neuf — 6 arrêts anormaux journalisés, dont **2 d'origine électrique externe établie** : une **coupure de courant Enedis** le 24/08 à 06:24, et un **débranchement volontaire** face aux orages le 24/08 (journalisé au démarrage du 25/08 à 08:22).
>
> Restent **4 épisodes inexpliqués** : **2 coupures sèches** sans code (12/08 05:49, 17/08 19:41) et **2 écrans bleus `0x9F`** (paramètre `0x3`, 12/08 à 10:30 et 15:27).
>
> **Aucun écran bleu depuis le 12/08**, soit 13 jours au 2026-08-25 — sans qu'aucune action n'ait été engagée entre-temps. Cohérent avec le régime par vagues décrit au § 5 : l'accalmie ne vaut pas correction, et ne dispense pas de la priorité 1.
>
> **Nuance importante sur les écrans bleus.** Dire que « la réinstallation n'a rien réglé » serait faux pour cette population : le vécu est celui d'une amélioration franche, et les chiffres le corroborent — 2 BSOD dans les 4 jours suivant l'installation, puis 13 jours sans aucun. Trois raisons de rester prudent avant d'en conclure à une guérison :
>
> - **Le régime historique est fait de vagues** (§ 5) : l'hiver a connu 10 × `0x9F` de décembre à mars, puis des mois de calme sans qu'aucune action n'ait été engagée. Treize jours ne suffisent pas à distinguer une correction d'une accalmie.
> - **La machine est aujourd'hui dans une configuration *moins* protégée qu'au 03/08** : le démarrage rapide, désigné comme amplificateur n°1 des `0x9F`, a été réactivé par la réinstallation, et `amdfendr.sys` est revenu avec le pilote AMD que Windows Update réinstalle automatiquement. L'accalmie se produit donc *malgré* des réglages défavorables.
> - **En revanche, deux suspects ont réellement disparu** : `VBoxNetLwf.sys` (VirtualBox) et les pilotes RustDesk (`usbmmidd`, imprimante virtuelle) sont absents du système neuf, et ni VirtualBox ni RustDesk ne sont réinstallés. Si l'accalmie se confirme au-delà d'un mois, ce sont eux qu'il faudra regarder — et non `amdfendr`, qui est toujours là.
>
> Ce que la réinstallation établit en revanche sans ambiguïté :
>
> - **Le Problème 2 (coupures sèches) n'a plus aucune explication logicielle plausible.** Il a survécu à une reconstruction totale du système. L'hypothèse matérielle — alimentation en tête — passe du statut de conjecture à celui d'explication par défaut. **La priorité 3 (intervention physique) devient la priorité réelle.**
> - **Le Problème 1 n'est pas disculpé pour autant.** Windows Update réinstalle exactement le même pilote Radeon **30.0.14023.3004 du 18/01/2022**, et `amdfendr.sys` (binaire du 07/02/2022) est de nouveau en place sur le système neuf. La réinstallation n'a donc **pas** testé cette variable-là : le pilote fautif est revenu tout seul. L'action de priorité 1 garde tout son sens.
> - **La signature `0x9F` réapparaît à l'identique** — même code, même paramètre `0x3` (périphérique trop lent à honorer un IRP d'alimentation) que la vague de 10 × `0x9F` de l'hiver 2025-2026. Ce n'était donc pas un accident de configuration : c'est reproductible sur une installation vierge.
>
> La condition posée au § 10 — « ne pas engager d'intervention physique avant 2-3 semaines de relevés » — est remplie, et par la voie la plus radicale qui soit.

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

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

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

0. **Qualité du secteur électrique — hypothèse ajoutée le 2026-08-25, désormais en tête.** Micro-coupures et creux de tension venant du réseau, et non du bloc d'alimentation. Elle produit exactement la même signature que les hypothèses internes — coupure nette, aucune trace, insensible aux réinstallations de Windows — mais elle dispose de quelque chose qu'aucune autre n'a : **des preuves directes**.
>
   Sur les 17 jours de suivi, **2 des 6 arrêts sont d'origine électrique externe établie** : une coupure Enedis le 24/08 à 06:24, et un débranchement volontaire face aux orages. Autrement dit, le réseau électrique de ce logement a produit **au moins un incident avéré en deux semaines et demie**. Une installation qui subit des coupures franches subit aussi, statistiquement, des creux plus brefs — trop courts pour être remarqués, largement suffisants pour faire tomber un PC dont l'alimentation n'a plus de marge.

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

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

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

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

---

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

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

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

### Priorité 1 — l'action décisive

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

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

### Priorité 2 — confirmer et combler les angles morts

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

### Priorité 3 — intervention physique, pour la Population A

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

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

---

## 11. Limites de cette analyse

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

- **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. |
| 2026-08-25 | 4 inexpliqués / 6 journalisés (17 jours, système neuf) | 2 | 2×`9F` (param. `0x3`) | n/c | n/c | **Windows réinstallé le 2026-08-08** — profil `eliob` perdu, profil `julie` créé | Relevé par `Get-WinEvent` (ID 41/6008/1001), session non élevée donc **SMART non lu**. Épisodes : 12/08 05:49, 12/08 10:30 (`9F`), 12/08 15:27 (`9F`), 17/08 19:41, puis **deux épisodes d'origine électrique externe confirmée** — 24/08 06:24 **coupure de courant Enedis**, et 25/08 08:22 qui journalise le **débranchement volontaire** du 24/08 (orages ; l'arrêt sale est écrit au démarrage suivant). Aucun BSOD depuis le 12/08. Système neuf **sans effet** sur les deux populations. Pilote AMD revenu en 30.0.14023.3004 (18/01/2022) par Windows Update, `amdfendr.sys` du 07/02/2022 réinstallé. **Test à variable unique négatif** → priorité déplacée vers le matériel (§ 9). |

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

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

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

---

## 13. Indicateur de succès

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

- **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 (poste `julie`, ex-`eliob`) » |

---

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


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

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

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

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

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

## ⚠ Ne pas se fier au fichier dans `System32\drivers`

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

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

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

## Ce que cette mise à jour ne traite pas

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

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

## Suite

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

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

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

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

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

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

### Premier relévé après correction

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

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

Deux points à relever tout de même :

- **6 arrêts anormaux pour 0 écran bleu** sur neuf jours — exactement le profil de la population « coupures sèches », celle que le pilote ne peut pas corriger
- **le démarrage rapide est toujours actif** (`HiberbootEnabled = 1`), réactivé par la réinstallation d'août. C'est l'amplificateur n°1 des `0x9F` : le remettre à 0 reste un levier disponible, en session élevée

# 260813 - solutions de page Internet pour transfert des epub sur la liseuse Kobo Aura 2

# Transfert d'epub sur la Kobo Aura Edition 2 sans câble USB

**Date** : 2026-08-13 — **Statut** : en production, validé sur l'appareil
**Matériel** : Kobo Aura Edition 2 (6 pouces, micro-USB)
**URL de service** : `juxjux.ovh/56ifciz` — répond en HTTP **et** en HTTPS

---

## 1. Le problème

Le port USB de la liseuse ne permet plus aucun transfert. Le PC ne détecte **rien du tout** — pas même un périphérique en erreur.

Diagnostic mené sur le poste Windows `julie` :

| Vérification | Résultat |
|---|---|
| Périphérique `VID_2237` (Kobo Inc.) présent | **absent** |
| Périphérique inconnu ou en erreur (`Status ≠ OK`) | **aucun** |
| Historique registre `Enum\USB` — trace d'un `VID_2237` | **aucune** |
| Historique `USBSTOR` | un seul boîtier ASMT, jamais de Kobo |
| Disques vus | Patriot (C:), Toshiba (D:), ASMT (E:), Seagate (F:) — rien de plus |

**Conclusion** : Windows ne reçoit aucun handshake USB. Le problème est **en amont du système** — ce n'est ni un pilote, ni une lettre de lecteur, ni une base de registre à nettoyer. Aucune piste logicielle n'est exploitable.

Causes matérielles possibles, par probabilité décroissante :

1. **Câble *charge seule*** — cause n°1 et de loin. Beaucoup de câbles micro-USB ne câblent que 2 fils sur 4
2. **Port de la liseuse encrassé** — la micro-USB accumule peluches et poussière de poche
3. **Batterie profondément déchargée** — une Kobo à plat ne s'énumère pas, même branchée. Il faut la laisser une heure sur un chargeur secteur avant de retenter
4. **Port physiquement HS**

> Le contournement décrit ci-dessous rend la liseuse pleinement utilisable, mais **ne remplace pas** un test câble. Voir § 7.

**Commandes de diagnostic réutilisables** (PowerShell) :

```powershell
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB' } |
    Select-Object Status,Class,FriendlyName,InstanceId | Sort-Object Class

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Enum\USB' |
    Where-Object { $_.PSChildName -match 'VID_2237' }
```

---

## 2. Solutions écartées, et pourquoi

Ce tableau évite de refaire le tour des mêmes impasses.

| Piste | Verdict | Raison |
|---|---|---|
| **GUI Syncthing** | impossible | Ne permet **aucun téléchargement de fichier** — Syncthing synchronise, il ne sert pas de fichiers. Et c'est une application JS moderne, illisible sur ce navigateur |
| **FileBrowser** (`files.juxjux.ovh`) | impossible | SPA + login JWT — injouable sur le WebKit de la liseuse |
| **OPDS** (Komga, Kavita, Ubooquity) | impossible | Le navigateur stock de la Kobo ne lit pas l'OPDS. Ne deviendrait pertinent qu'avec KOReader installé |
| **Kobo Sync natif de Calibre-web** | **bloqué** | C'est la bonne solution sur le papier : synchronisation native par Wi-Fi. Mais elle impose de modifier `api_endpoint` dans `.kobo/Kobo/Kobo eReader.conf` **sur la liseuse** — donc **exige l'USB**, précisément ce qui est en panne. À reconsidérer si le port refonctionne |
| **Yourls pour raccourcir l'URL** | inutile | `juxjux.ovh/56ifciz` est déjà court à taper au doigt, et éviter la redirection supprime un point de fragilité |
| **Page HTML nue en `autoindex`** | **retenu** | Pas de JavaScript, pas de session, pas de cookie. Le navigateur Kobo télécharge le fichier et l'ajoute à la bibliothèque |

---

## 3. La solution retenue

Un `location` nginx en `autoindex` greffé sur le vhost `juxjux.ovh` existant, servant un dossier de l'arbre Syncthing.

```
Dépôt du fichier            Syncthing              nginx autoindex         Navigateur bêta
D:\Syncthing\Kobo\    →   (n'importe quelle   →   juxjux.ovh/56ifciz  →   de la liseuse
                           machine du maillage)     (port 80)                → bibliothèque
```

**Aucun DNS ni certificat n'a été créé** — la location est greffée sur un vhost déjà en place.

| Élément | Valeur |
|---|---|
| URL liseuse | `juxjux.ovh/56ifciz` (**HTTP**, pas HTTPS) |
| Dossier VPS | `/home/debian/Documents/Kobo/` |
| Équivalent Windows | `D:\Syncthing\Kobo\` |
| Propriétaire | `debian:debian` (Syncthing tourne sous cet utilisateur) |
| Vhost modifié | `/etc/nginx/sites-available/juxjux.ovh` |
| Sauvegarde | `/etc/nginx/sites-available/juxjux.ovh.bak-260813` |

### Mode d'emploi

**Déposer un livre** : le glisser dans `D:\Syncthing\Kobo\` depuis n'importe quelle machine du maillage. Syncthing le pousse au VPS, il apparaît dans la page — aucune autre manipulation.

**Le récupérer sur la liseuse** : Menu → Plus → *Navigateur bêta* → taper `juxjux.ovh/56ifciz` → toucher le lien de l'epub. Téléchargement, puis ajout automatique à la bibliothèque.

---

## 4. Les quatre pièges, et leur correctif

Ce sont les points à ne pas défaire par inadvertance.

### 4.1 Le chemin doit exister dans les **deux** blocs — la liseuse force HTTPS

C'est le point qui a demandé une correction après coup, et l'hypothèse de départ était fausse.

**Hypothèse initiale (erronée)** : le navigateur de l'Aura Edition 2 étant un WebKit ancien, on a supposé qu'il échouerait sur la config TLS actuelle — soit par une version TLS trop vieille (`options-ssl-nginx.conf` impose TLS 1.2+), soit par un magasin de racines ignorant la chaîne Let's Encrypt (ISRG Root X2 → ISRG Root X1). La `location` n'a donc d'abord été posée que dans le bloc `listen 80`, en HTTP volontaire.

**Ce que l'appareil a montré** : le navigateur bêta **force HTTPS**. Avec la location absente du bloc 443, il tombait sur un `404`. Et le magasin de racines de la liseuse connaît parfaitement ISRG Root X1 — le TLS n'a jamais été le problème.

**Correctif appliqué le 2026-08-13 à 14:49** : la `location /56ifciz/` a été **dupliquée à l'identique** dans le bloc `listen 443 ssl`, le bloc `listen 80` étant conservé pour la robustesse. Les deux répondent aujourd'hui `200`.

> **Aucun assouplissement TLS n'a été nécessaire ni appliqué** — pas de TLS 1.0/1.1 réactivé, pas de ciphers CBC hérités. Ne pas en ajouter « au cas où » : ce serait dégrader la sécurité de tout le domaine pour un problème qui n'existe pas.

Sauvegarde avant cet ajout : `/etc/nginx/sites-available/juxjux.ovh.bak-260813-https`

**Contrepartie** : la liseuse passant par 443, le chemin et les fichiers **ne circulent plus forcément en clair**. Mais le bloc HTTP reste ouvert, et surtout le seul rempart demeure l'obscurité de l'URL (§ 7). **Ne rien déposer de sensible dans ce dossier.**

### 4.2 La redirection 80 → 443 devait être restructurée

Le vhost portait la redirection sous cette forme, posée par Certbot :

```nginx
if ($host = juxjux.ovh) { return 301 https://$host$request_uri; }
```

Écrit **au niveau serveur**, ce `if` s'évalue en phase *rewrite* — c'est-à-dire **avant** le choix de la location. Il est donc impossible d'y soustraire un chemin : `/56ifciz/` partait en redirection HTTPS comme tout le reste.

**Correctif** : remplacer le `if` par un `location /` explicite. Une location plus spécifique (`/56ifciz/`) l'emporte alors naturellement.

```nginx
location / {
    return 301 https://$host$request_uri;
}
```

### 4.3 nginx ne connaît pas le type MIME epub

`/etc/nginx/mime.types` ne contient **ni `epub`, ni `mobi`, ni `azw`**. Sans déclaration, le fichier est servi en `text/plain` et la liseuse **l'affiche au lieu de le télécharger**.

**Piège dans le piège** : un bloc `types { }` placé dans une `location` **remplace intégralement la table MIME** pour cette location — il ne s'y ajoute pas. Tout type utile doit donc y figurer, d'où le `default_type application/octet-stream` en filet de sécurité.

### 4.4 Permissions — Syncthing dépose parfois en 640

`www-data` doit pouvoir lire les fichiers déposés. Or Syncthing crée parfois des fichiers en `640`, ce qui produirait un **403 silencieux**.

**Correctif** — une ACL par défaut sur le dossier, qui force la lisibilité des fichiers à venir :

```bash
setfacl -m  o::rx /home/debian/Documents/Kobo
setfacl -d -m o::r  /home/debian/Documents/Kobo
setfacl -d -m u::rw /home/debian/Documents/Kobo
setfacl -d -m g::r  /home/debian/Documents/Kobo
```

> **Attention** : si le dossier est créé avec `sudo`, il appartient à `root` et **Syncthing ne peut plus y écrire**. Vérifier `chown -R debian:debian` après création.

---

## 5. Configuration nginx appliquée

Fichier `/etc/nginx/sites-available/juxjux.ovh`. **Le bloc `location /56ifciz/` est identique dans les deux `server`** — c'est délibéré (§ 4.1) : la liseuse force HTTPS, le port 80 est conservé pour la robustesse.

```nginx
server {
    server_name juxjux.ovh www.juxjux.ovh;

    root /var/www/juxjux.ovh/html;
    index index.html index.htm;

    # --- Acces liseuse Kobo Aura Edition 2 (ajout 2026-08-13, volet HTTPS)
    # Duplique le location du bloc :80. La liseuse impose HTTPS -> ce chemin
    # doit exister aussi en 443. Ne rien mettre de sensible dans Documents/Kobo.
    location /56ifciz/ {
        alias /home/debian/Documents/Kobo/;
        autoindex on;
        autoindex_exact_size off;
        autoindex_localtime on;
        charset utf-8;
        add_header X-Robots-Tag "noindex, nofollow" always;

        types {
            application/epub+zip            epub;
            application/pdf                 pdf;
            application/x-mobipocket-ebook  mobi;
            application/vnd.amazon.ebook    azw3;
            application/vnd.comicbook+zip   cbz;
            text/plain                      txt;
        }
        default_type application/octet-stream;
    }

    location / {
        try_files $uri $uri/ =404;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate     /etc/letsencrypt/live/juxjux.ovh/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/juxjux.ovh/privkey.pem;   # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;   # managed by Certbot
}

server {
    listen 80;
    server_name juxjux.ovh www.juxjux.ovh;

    # --- Acces liseuse Kobo Aura Edition 2 (ajout 2026-08-13)
    location /56ifciz/ {
        # ... bloc strictement identique a celui du server 443 ...
    }

    location / {
        return 301 https://$host$request_uri;
    }
}
```

> **En cas de modification**, penser à reporter le changement dans **les deux** blocs. Une divergence entre les deux produirait un comportement dépendant du protocole, très déroutant à diagnostiquer depuis la liseuse.

---

## 6. Vérifications de bon fonctionnement

Depuis le VPS **et** depuis l'extérieur :

```bash
# Page d'index dans les deux protocoles — les deux doivent repondre 200
for u in http https; do
  curl -s -o /dev/null -w "$u : HTTP %{http_code}  type=%{content_type}\n" \
       $u://juxjux.ovh/56ifciz/
done

# Type MIME du fichier — doit repondre application/epub+zip
curl -s -o /dev/null -D - "https://juxjux.ovh/56ifciz/<fichier>.epub" | grep -iE 'HTTP/|content-type'

# La racine doit toujours rediriger en HTTPS
curl -s -o /dev/null -w 'HTTP %{http_code} -> %{redirect_url}\n' http://juxjux.ovh/
```

Résultats attendus, relevés le 2026-08-23 :

| Test | Attendu | Obtenu |
|---|---|---|
| Index **HTTP** | `200` / `text/html; charset=utf-8` | conforme |
| Index **HTTPS** | `200` / `text/html; charset=utf-8` | conforme |
| Epub | `200` / `application/epub+zip` | conforme |
| Racine `/` en HTTP | `301` vers `https://juxjux.ovh/` | conforme |
| Lecture par `www-data` | autorisée | conforme |

> Un `404` sur **un seul** des deux protocoles signifie que la `location` a disparu du bloc correspondant — c'est le symptôme exact de la panne corrigée le 13 août (§ 4.1).

---

## 7. Limites et suites

### Sécurité

**La seule protection est l'obscurité du chemin.** Il n'y a aucune authentification — le navigateur Kobo gère mal les invites Basic Auth, ce qui l'excluait. Un `X-Robots-Tag: noindex, nofollow` évite l'indexation par les moteurs.

Le passage en HTTPS (§ 4.1) chiffre le transport, mais **ne change rien à ce point** : quiconque connaît l'URL accède à tout le dossier, et le bloc HTTP reste ouvert.

Conséquence pratique : **ce dossier est à considérer comme public**. Y déposer uniquement des livres, jamais un document personnel.

### Nommage des fichiers

Éviter accents et espaces. L'autoindex les encode correctement (`%20`), mais le navigateur de la liseuse est capricieux sur les URL encodées.

### À faire — tester le câble USB

Le contournement fonctionne, mais la panne USB reste non élucidée. Dans l'ordre :

1. **Tester un autre câble** dont on sait qu'il transporte des données (celui d'un disque externe ou d'un téléphone déjà utilisé en transfert)
2. Inspecter et nettoyer le port de la liseuse à la lampe, appareil éteint, avec un cure-dent en bois — jamais en force
3. Laisser une heure sur **chargeur secteur** (pas le PC) avant de retenter
4. Reset matériel : bouton d'alimentation maintenu **30 secondes**
5. Croiser les variables : ce câble sur un autre appareil, cette liseuse sur un autre PC

**Si l'USB revient**, basculer sur le **Kobo Sync de Calibre-web** — synchronisation native, bidirectionnelle, avec suivi de la position de lecture. Nettement supérieur à cette page. Il ne faut l'USB qu'une seule fois, pour écrire `api_endpoint` dans `.kobo/Kobo/Kobo eReader.conf`.

---

## Voir aussi

- `CLAUDE.md` — section « Liseuse Kobo Aura Edition 2 — dépôt epub par le navigateur »
- Page **249** — stabilité du PC Windows (même chapitre, dépannages)

# 260823-Le réglage du pare-feu Portmaster

# Portmaster — la découverte réseau et le NAS maison

Poste **`julie`** (`DESKTOP-B7J2KGP`), Windows 10. Installation de **Safing Portmaster 2.2.1** le **22/08/2026 à 10:58**, réglage le **23/08/2026**.

Portmaster est un pare-feu applicatif qui s'insère au niveau **WFP** via son pilote `portmaster-kext.sys`. Il **double** le pare-feu Windows et c'est lui qui tranche : inutile d'aller chercher du côté de Defender.

| Élément | Valeur |
|---|---|
| Version | 2.2.1 (éditeur `safing`) |
| Service | `PortmasterCore`, démarrage automatique |
| Binaires | `C:\Program Files\Portmaster` |
| Données et journaux | `C:\ProgramData\Portmaster` |
| API locale | `http://127.0.0.1:817` |

---

## 1. Le symptôme, et ce qui n'était pas en cause

Plus aucune découverte réseau sur le poste : le NAS Synology maison (`192.168.1.17`, `\\NASMAISON`) n'apparaissait plus dans le volet **Réseau** de l'Explorateur.

Le premier réflexe — soupçonner le réseau ou le NAS — était **faux**. Tout répondait :

| Contrôle | Résultat |
|---|---|
| Poste | `192.168.1.26/24`, passerelle et DNS `192.168.1.1` |
| Ping `192.168.1.17` | répond |
| MAC du NAS | `00-11-32-9C-8E-C9` — OUI **Synology** |
| Ports TCP | **445, 139, 22, 80 ouverts** (5000/5001 fermés) |
| Résolution du nom | `NASMAISON` → `NASMAISON.local` = 192.168.1.17, par **mDNS** |
| Lecteur `A:` → `\\NASMAISON\foxy` | **monté et lisible**, 55 entrées |

**Leçon : l'accès n'a jamais été rompu, seule la découverte l'était.** Distinguer les deux dès le départ fait gagner beaucoup de temps.

Détail annexe, non symptomatique : `\\192.168.1.17\foxy` échoue alors que `\\NASMAISON\foxy` fonctionne. L'identifiant Windows est enregistré sous la cible `NASMAISON` (utilisateur `juxjux`), pas sous l'adresse IP — comportement normal de `cmdkey`.

---

## 2. Le diagnostic

La preuve est dans le journal de Portmaster, `C:\ProgramData\Portmaster\logs\2026-08-22_10-57-46.log` :

```
2026-08-23 07:12:50  filter: connection AUTORITE NT\SERVICE LOCAL:
  C:\Windows\System32\svchost.exe:12184 <- 192.168.1.17
  dropped: inbound connections blocked
```

`svchost.exe` **PID 12184** héberge le service **SSDPSRV (Découverte SSDP)** — identifié par `Get-CimInstance Win32_Service -Filter "ProcessId=12184"`.

Cadence des rejets : 05:56, 06:11, 06:26, 06:42, 06:57, 07:12 — **toutes les ~15 minutes**, soit exactement le rythme des annonces SSDP périodiques du NAS.

Répartition des **1 802 blocages** du même motif :

| Source | Occurrences | Destinataire |
|---|---|---|
| `92.184.113.225` | 441 | `syncthing.exe` |
| `192.168.1.26` (le poste lui-même) | 421 | — |
| `192.168.1.1` (Livebox) | 330 | — |
| **`192.168.1.17` (NAS)** | **249** | **SSDPSRV** |
| `192.168.1.19` | 153 | — |
| IPv6 globales `2a01:cb1c:…` | ~80 | `syncthing.exe`, SSDPSRV |

À noter : le trafic **sortant** passait bien (287 requêtes SSDP acceptées vers `239.255.255.250:1900`). Le poste interrogeait, mais les annonces du NAS, qui arrivent en **entrant non sollicité**, étaient jetées.

---

## 3. La cause

Le réglage **`filter/blockInbound`** — « Force Block Incoming Connections » — **activé par défaut** à l'installation.

Sa propre description est sans ambiguïté : *« Is stronger than Rules »*. Aucune règle entrante ne peut le contourner, ce qui explique qu'aucun réglage fin ne suffisait tant qu'il restait coché.

État des réglages liés au moment du diagnostic :

| Clé | Valeur | Rôle |
|---|---|---|
| `filter/blockInbound` | `True` (défaut) | **la cause** |
| `filter/defaultAction` | `permit` (défaut) | action si aucune règle ne correspond |
| `filter/serviceEndpoints` | `[]` | Incoming Rules, vides |
| `filter/blockLAN` | `False` (défaut) | non impliqué |

---

## 4. La configuration retenue

*Incoming Rules*, **dans cet ordre impératif** :

| Ordre | Menu | Champ |
|---|---|---|
| 1 | Allow | `Localhost` |
| 2 | Allow | `LAN` |
| 3 | Block | `*` |

puis **décocher** *Force Block Incoming Connections*.

`Localhost`, `LAN` et `Internet` sont des **mots-clés de portée** reconnus par Portmaster, au même titre qu'une adresse ou un CIDR. Les utiliser vaut mieux que d'écrire `192.168.1.0/24` : la portée suit le réseau, la règle ne devient jamais caduque.

### Variante resserrée

Si l'on veut n'ouvrir que le strict nécessaire à la découverte, plutôt que tout le LAN — cela laisse notamment les partages administratifs `C$`, `D$`, `E$` et le RPC fermés y compris depuis le réseau local :

| Menu | Champ | Rôle |
|---|---|---|
| Allow | `Localhost` | boucle locale |
| Allow | `LAN UDP/1900` | SSDP — les annonces du NAS |
| Allow | `LAN UDP/3702` | WS-Discovery |
| Allow | `LAN TCP/5357` | WSDAPI, l'échange qui construit l'icône |
| Block | `*` | tout le reste |

Pour Syncthing en direct sur le LAN, ajouter avant le `Block` : `LAN TCP/22000`, `LAN UDP/22000`, `LAN UDP/21027`.

---

## 5. Les pièges — à ne pas redécouvrir

**1. `Incoming Rules` est invisible en mode Simple.**
`filter/serviceEndpoints` est de niveau **expert** (`ExpertiseLevel 1`), tandis que `filter/endpoints` (Outgoing Rules) est de niveau `user` — d'où l'impression trompeuse que seules les règles sortantes existent. Basculer l'interface sur **Advanced Interface** : sélecteur en haut à droite de la fenêtre, ou Settings → *User Interface* → **UI Mode**. Les réglages masqués **restent actifs**.

**2. Ne jamais taper le `+` ou le `-` dans le champ de la règle.**
Le menu Allow/Block fournit déjà le signe. Saisir `+ LAN` produit `+ + LAN` et déclenche :

```
Invalid Value: validation of filter/serviceEndpoints failed:
entry #1 did not match validation regex
```

La regex de validation est :

```
^(\+|\-) (! +)?[A-z0-9\.:\-*/]+( [A-z0-9*]+(/[A-z0-9]+(\-[A-z0-9]+)?)?)?( +#.*)?
```

Le `+` n'appartient pas à la classe de caractères qui suit le signe. La syntaxe `+ LAN` / `- *` est celle du **fichier de configuration**, pas de l'interface graphique.

**3. `Block *` sans `Allow Localhost` au-dessus casse la boucle locale.**
Constaté en direct :

```
07:43:31  firefox.exe    <- 127.0.0.1  dropped: denied by rule: matches *
07:43:18  syncthing.exe  <- 127.0.0.1  changed from accepted to dropped
07:43:18  steam.exe      <- 127.0.0.1  changed from accepted to dropped
07:43:18  dasHost.exe    <- ::1        changed from accepted to dropped
```

L'interface Syncthing sur `127.0.0.1:8384` est tombée en timeout. Portmaster **ré-évalue les connexions déjà établies** et les coupe à chaud. Sur une machine de travail, une grande part du trafic légitime passe par la boucle locale.

Piège dans le piège : **l'API de Portmaster s'auto-exempte** et continue de répondre — elle ne sert donc pas de témoin pour détecter la panne.

**4. L'ordre des règles fait tout.** Évaluation de haut en bas, la première correspondance l'emporte. `Block *` doit être la **dernière** ligne. Les flèches à gauche de chaque ligne permettent de réordonner.

**5. `filter/defaultAction` vaut `permit`.** Une liste de règles sans `Block *` final **n'est pas restrictive** : tout ce qui ne correspond à aucune règle est autorisé. Décocher *Force Block Incoming* sans poser ce garde-fou ouvre la machine — point critique compte tenu de l'IPv6 (section 6).

**6. L'API locale ment par omission.** `GET http://127.0.0.1:817/api/v1/config/options` répond à n'importe quel processus, mais ne renvoie que les **définitions et les valeurs par défaut** : le champ `Value` reste vide même pour un réglage effectivement modifié, ce qui fait croire à tort que rien n'a été enregistré. Les endpoints qui exposent l'état réel (`/api/v1/sync/settings/export`) répondent :

```
403 The requesting process is not authorized to access the Portmaster API.
```

**Vérifier par le journal, jamais par l'API.**

**7. Le profil réseau Windows n'a pas eu à être modifié.** Il est resté sur **Public** et la découverte fonctionne. L'hypothèse initiale — passer en Privé et redémarrer `FDResPub` et `upnphost` — s'est révélée inutile. Ne pas y consacrer de temps.

---

## 6. IPv6 — le point de sécurité

Ce poste possède des adresses **IPv6 globales routables** : `2a01:cb1c:833b:d00:4958:51b1:629a:a6b4` et `2a01:cb1c:833b:d00:28cb:cac8:3621:d7d0` (préfixe Orange, obtenu par *Router Advertisement*).

**En IPv6 il n'y a pas de NAT.** La Livebox ne fait pas écran comme en IPv4 : Portmaster est la seule barrière. Ce que le poste expose au réseau :

| Port | Processus |
|---|---|
| 445 | SMB — partages `ADMIN$`, `C$`, `D$`, `E$`, `IPC$` |
| 135 + 49664-49675 | RPC (`lsass`, `wininit`, `spoolsv`, `services`) |
| 5357 | WSDAPI |
| 22000 | Syncthing |
| 27036 | Steam |

La portée `LAN` **ne couvre pas** ces adresses globales — elles sont classées `Global`, pas `LAN`. Le `Block *` les refuse donc, ce qui est le comportement voulu.

**Conséquence assumée** : les liens **Syncthing directs en IPv6 restent bloqués**. Sans impact aujourd'hui, la synchronisation passant par le hub VPS (`syncthing-vps`, `tcp-client` vers `51.77.141.54:22000`). Pour les rétablir, ajouter `2a01:cb1c:833b:d00::/64` au-dessus du `Block *` — en sachant que **ce préfixe peut changer au redémarrage de la Livebox** et rendre la règle caduque sans le moindre signal.

---

## 7. Vérification

État constaté après réglage :

| Portée | Verdict |
|---|---|
| `127.0.0.1` / `::1` | **accepté** — `scope matches Localhost` |
| LAN (`192.168.1.x`, `fe80::`) | **accepté** — `scope matches LAN`, 8 acceptations NAS, zéro rejet |
| IPv6 globales `2a01:cb1c:…` | **rejeté** — `denied by rule: matches *` |

- Interface Syncthing `127.0.0.1:8384` : **HTTP 200**
- `A:` → `\\NASMAISON\foxy` : accessible, 55 entrées
- `fdPHost`, `SSDPSRV`, `FDResPub`, `upnphost` : les quatre `Running`

Commande de contrôle, à relancer si le NAS redisparaît :

```bash
grep "192.168.1.17" /c/ProgramData/Portmaster/logs/*.log | tail -20
```

Attendu :

```
svchost.exe:12184 <- 192.168.1.17  accepted: allowed by rule: scope matches LAN
dasHost.exe:3608  to nasmaison. (192.168.1.17)  accepted
```

`dasHost.exe` est le *Device Association Host* : le voir dialoguer avec `nasmaison.`, c'est littéralement l'icône du NAS en train de se construire dans l'Explorateur.

Si l'on lit `dropped: inbound connections blocked`, c'est que *Force Block Incoming Connections* a été réactivé.

---

## 8. Chronologie

| Horodatage | Événement |
|---|---|
| 22/08 10:58 | Installation de Portmaster 2.2.1 |
| 22/08 → 23/08 | Découverte réseau muette, ~1 800 blocages entrants silencieux |
| 23/08 ~05:45 | Diagnostic : NAS joignable, seule la découverte est cassée |
| 23/08 ~07:30 | Cause identifiée — `filter/blockInbound` et les annonces SSDP |
| 23/08 07:41 | `Allow LAN` posé, *Force Block Incoming* décoché → **NAS visible** |
| 23/08 07:43 | `Block *` ajouté → **boucle locale coupée**, Syncthing GUI en timeout |
| 23/08 07:45 | `Allow Localhost` ajouté en tête → état final correct |
| 23/08 07:46 | Vérification des trois niveaux, conforme |

---

## 9. Références

- `CLAUDE.md` — section « Portmaster (pare-feu applicatif) sur `julie` », insérée le 23/08/2026
- Journal Portmaster : `C:\ProgramData\Portmaster\logs\`
- Aide intégrée à Portmaster : la syntaxe complète des règles (portées, domaines, pays, AS, listes de filtrage, protocoles et ports) est dans l'infobulle des champs *Outgoing Rules* et *Incoming Rules*

# 260826-Secure Virtual Machine et Emulateur Android

Mise en place d'un émulateur Android sur le poste `julie` pour faire tourner des applications de presse (The Guardian, Le Monde) et d'autres APK. Séance du 2026-08-26.

Trois obstacles se sont enchaînés, chacun avec un diagnostic trompeur : la virtualisation matérielle absente, un pilote d'accélération dont l'installation échoue en silence, et un faux écran noir. Cette page retient surtout **les pièges**, parce que chacun a coûté plusieurs allers-retours.

# Contexte et matériel

| Élément | Valeur |
|---|---|
| Poste | `julie` — MSI A320M-A PRO (MS-7C51), BIOS `E7C51AMS.140` du 12/08/2020 |
| CPU | AMD Ryzen 5 2600X, 6 cœurs / 12 threads |
| RAM | 16 Go |
| GPU | Radeon RX 6500 XT, pilote **du 18/01/2022** (voir page 249) |
| Écran | dalle 4K 3840x2160, bureau logique 2560x1440 (mise à l'échelle 150 %) |
| OS | Windows 10 19045, firmware **UEFI**, démarrage rapide **actif** |

# 1. Activer la virtualisation (SVM)

## Le symptôme

`systeminfo` répondait `Virtualisation activée dans le microprogramme : Non`, alors que le CPU est parfaitement capable de SVM. Sans virtualisation, **aucun émulateur Android ne fonctionne** — BlueStacks, LDPlayer, MEmu, Nox, Genymotion et l'AVD d'Android Studio sont tous des machines virtuelles x86. Changer d'émulateur ne contourne pas le problème.

Vérification préalable qu'aucune cause logicielle n'était en jeu :

```powershell
Get-CimInstance Win32_ComputerSystem | Select-Object HypervisorPresent          # False
(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard).VirtualizationBasedSecurityStatus               # 0
```

Aucun hyperviseur actif, pas de VBS : ni Hyper-V ni l'isolation du noyau ne confisquaient la virtualisation. La cause était donc bien dans le firmware.

## Le chemin dans le BIOS

Ce poste a l'**ancienne interface MSI Click BIOS à onglets horizontaux**, pas la version récente à tuiles. Donc **ni EZ Mode, ni touche F7, ni OC Explore Mode** à chercher — toutes indications que l'on trouve partout en ligne et qui ne s'appliquent pas ici.

Touche d'entrée dans le BIOS sur cette machine : **F11**. Plus fiable, le démarrage rapide étant actif : *Paramètres → Mise à jour et sécurité → Récupération → Démarrage avancé → Redémarrer maintenant → Dépannage → Options avancées → Changer les paramètres du microprogramme UEFI*.

Chemin réel du réglage :

```
Overclocking → (section Other Setting, tout en bas) → Caractéristique du CPU → SVM Mode
```

`Caractéristique du CPU` est la traduction française de **CPU Features**.

## Piège n°1 — deux sous-menus qui se ressemblent

La section *Other Setting* du menu Overclocking contient trois entrées :

```
CPU Specifications        -> INFORMATIONS, lecture seule
MÉMOIRE-Z                 -> informations RAM
Caractéristique du CPU    -> LES RÉGLAGES
```

`CPU Specifications → CPU Technology Support` affiche une fiche technique :

```
Secure Virtual Machine        YES
```

**Ce « YES » ne signifie pas que SVM est activé** — seulement que le processeur en est capable. C'est une page de consultation.

**Règle pour distinguer d'un coup d'œil** : dans ce BIOS, un réglage modifiable est **toujours entre crochets** (`A-XMP [Désactivé]`, `NX Mode [Activé]`, `SVM Mode [Activé]`). Une valeur en texte nu (`YES`, `N/A`, `3.60GHz`) est informative.

## Piège n°2 — la vraie cause : il faut couper le secteur

Contenu réel de `Overclocking\Caractéristique du CPU` :

```
Simultaneous Multi-Threading   [AUTO]
Global C-state Control         [AUTO]
Opcache Control                [AUTO]
IOMMU                          [AUTO]
Spread Spectrum                [AUTO]
Relaxed EDC throttling         [AUTO]
AMD Cool'n'Quiet               [Activé]
NX Mode                        [Activé]
SVM Mode                       [Activé]   <-- déjà correct
Power Supply Idle Control      [AUTO]
```

**Le réglage était déjà bon**, et Windows répondait pourtant `Non`.

**Ce qui a débloqué : le débranchement de la prise pendant 10 secondes.** Après quoi :

```
Virtualisation activée dans le microprogramme : Oui
VirtualizationFirmwareEnabled                 : True
```

> Sur cette carte, un `SVM Mode` correctement réglé peut rester invisible du système tant qu'il n'y a pas eu de vraie coupure secteur. Un redémarrage, et même un arrêt Windows normal, ne suffisent pas — le démarrage rapide maintient un état résiduel. **Débrancher d'abord, diagnostiquer ensuite.**

Ne pas toucher aux autres lignes, en particulier laisser `IOMMU` et `Simultaneous Multi-Threading` sur `[AUTO]`.

Fiche pas-à-pas réutilisable : `Jux-scripts/PC-Health/bios_svm_a320m.md`.

# 2. Android Studio

```powershell
winget install -e --id Google.AndroidStudio --accept-package-agreements --accept-source-agreements
```

Version installée : **2026.1.3.7**, 3,29 Go dans `C:\Program Files\Android\Android Studio`.

Installation en mode **Custom** pour accéder aux composants. Composants retenus :

| Composant | Version | Rôle |
|---|---|---|
| Android Emulator | 37.1.11 | l'émulateur |
| Android SDK Platform-Tools | 37.0.1 | `adb` |
| Android SDK Command-line Tools | 23.0.0 | `avdmanager`, diagnostics |
| Android Emulator hypervisor driver | 2.2.0 | **accélération AMD** — voir section suivante |

**Symptôme si le pilote manque** : l'assistant marque *Android Virtual Device* comme **indisponible**, et n'installe ni l'émulateur ni les platform-tools. Ce n'est pas un échec du BIOS — il manque juste la couche d'accélération.

Note : `sdkmanager` est **déprécié** et son remplaçant `android` est encore incomplet (`android sdk list` ne liste que l'installé). Passer par l'interface pour tout ce qui touche aux images système.

# 3. Le pilote AEHD — installation manuelle

## Pourquoi ce pilote

Sur un CPU **AMD** sous Windows, l'émulateur a besoin de l'un des deux mécanismes suivants :

| Mécanisme | Prérequis | Retenu ? |
|---|---|---|
| **AEHD** (Android Emulator Hypervisor Driver) | SVM activé, **Hyper-V absent** | **Oui** — correspond à la configuration du poste |
| WHPX | Hyper-V + Windows Hypervisor Platform installés | Non — alourdirait le système |

## Piège n°3 — le SDK Manager échoue et efface ses traces

Sortie observée :

```
Installing Android Emulator hypervisor driver (installer) in ...\extras\google\Android_Emulator_Hypervisor_Driver
"Install Android Emulator hypervisor driver (installer) v.2.2.0" complete.
Failed to update status to COMPLETE
"Install Android Emulator hypervisor driver (installer) v.2.2.0" failed.
```

Le paquet se télécharge et s'extrait, puis **l'étape d'installation du pilote échoue faute d'élévation**, et le gestionnaire **annule l'extraction** : `extras\google` se retrouve **vide**. Il ne reste donc rien à réparer sur place — il faut repartir du paquet d'origine.

## La réparation

```powershell
New-Item -ItemType Directory -Force 'D:\temp_aehd' | Out-Null
Invoke-WebRequest -Uri 'https://dl.google.com/android/repository/aehd-windows_v2.2.zip' `
                  -OutFile 'D:\temp_aehd\aehd.zip'
Expand-Archive 'D:\temp_aehd\aehd.zip' -DestinationPath 'D:\temp_aehd\x' -Force
Start-Process -FilePath 'cmd.exe' -Verb RunAs -Wait -ArgumentList `
  '/c','"cd /d D:\temp_aehd\x && silent_install.bat > D:\temp_aehd\out.txt 2>&1"'
```

> **Piège MSIX — utiliser `D:` et non le dossier temporaire habituel.** Claude Code tourne dans un conteneur MSIX : ce qu'il écrit sous `%LOCALAPPDATA%` atterrit en réalité dans `…\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\`. Un installeur lancé **en élevé sort du conteneur** et ne verrait pas ces fichiers. Même famille de piège que le home Syncthing (voir la section « Poste Windows julie » du `CLAUDE.md`).

Contenu du paquet : `aehd.Sys` (403 Ko), `aehd.cat`, `aehd.Inf`, `silent_install.bat`. Le script installe via `RUNDLL32 SETUPAPI.DLL,InstallHinfSection` puis lance le service. Désinstallation : `silent_install.bat -u`.

Résultat :

```
SERVICE_NAME: aehd
        TYPE  : 1  KERNEL_DRIVER
        STATE : 4  RUNNING
```

## Vérification

```powershell
& 'D:\Android\Sdk\emulator\emulator.exe' -accel-check
```

Attendu : `AEHD (version 2.2) is installed and usable.` et code de retour `0`.

# 4. L'AVD

## Choix retenus

Profil **Pixel Tablet** en paysage : l'écran du PC est large, et Guardian comme Le Monde ont de vraies mises en page tablette (multi-colonnes). Un profil téléphone donnerait une colonne étroite au milieu d'un grand écran.

Ce qui déclenche la mise en page tablette, c'est la **largeur en dp**, pas en pixels : `1600 / (320/160) = 800 dp`, au-delà du seuil de 600 dp.

> **Si aucun profil tablette ne porte l'icône Play Store**, ne pas se rabattre sur un téléphone : prendre un profil téléphone **avec** Play Store, puis régler dans *Edit* une résolution de 1920x1200 en 240 dpi (soit 800 dp). On garde le Play Store **et** la mise en page large.

## Image système

```
system-images\android-35\google_apis_playstore_tablet\x86_64
Android 15, API 35
```

La variante **« Google Play »** est indispensable pour installer les applications depuis le Store. C'est une build de production : `adb root` y est impossible, mais `adb install` fonctionne normalement.

**Traduction ARM confirmée** — point décisif pour les APK récupérés ailleurs :

```
ro.product.cpu.abilist = x86_64,arm64-v8a
```

Les images x86_64 en **API 30 et plus** traduisent l'ARM 64 bits à la volée. Sans cela, un APK ARM échoue sur `INSTALL_FAILED_NO_MATCHING_ABIS`.

## Piège n°4 — les réglages avancés ne s'appliquent pas à la création

Valeurs demandées dans l'assistant, valeurs réellement écrites :

| Réglage | Demandé | Obtenu | Corrigé en |
|---|---|---|---|
| `hw.ramSize` | 4096 | **2048** | **6144** |
| `vm.heapSize` | — | **192** | **512** |
| `disk.dataPartition.size` | 16 Go | 10 Go | 10 Go (suffisant) |
| `hw.cpu.ncore` | 4 | 4 | 4 |

Plus simple que de rechercher le Device Manager dans l'interface : éditer directement, **émulateur arrêté** (il réécrit son fichier en quittant).

`C:\Users\julie\.android\avd\Pixel_Tablet.avd\config.ini`

```ini
hw.ramSize=6144
vm.heapSize=512
hw.cpu.ncore=4
disk.dataPartition.size=10G
hw.gpu.mode=auto
```

**`vm.heapSize` est le réglage sous-estimé** : c'est le plafond mémoire par *application*, distinct de la RAM totale. À 192 Mo, une application de presse chargeant beaucoup d'images se fait tuer sans message. C'était le vrai goulet d'étranglement, davantage que les 2 Go de RAM.

Sauvegarde : `config.ini.bak-260826`. Vérification côté invité : `MemTotal: 6072156 kB` — l'écart avec 6144 Mo est la part réservée par le noyau, c'est normal.

**Augmenter le stockage après coup impose un effacement des données.** C'est le seul réglage à ne pas rater à la création.

# 5. Piège n°5 — le faux écran noir

## Le symptôme

Après quelques minutes, écran entièrement noir. La capture prise **depuis l'intérieur d'Android** était noire elle aussi — ce qui semblait exclure un simple problème de fenêtre Windows et accusait la pile graphique, d'autant que le journal de l'émulateur contenait :

```
UpdateLayeredWindowIndirect failed ... (Un périphérique attaché au système ne fonctionne pas correctement)
```

avec un pilote AMD de janvier 2022 comme suspect tout désigné.

## La vraie cause

```
mWakefulness=Dozing
```

**L'écran s'était simplement mis en veille**, comme sur une vraie tablette. Et le volet de notifications était resté déployé par-dessus (`mCurrentFocus=NotificationShade`), ce qui gardait l'affichage noir même après réveil.

Aucune erreur graphique dans `logcat`. Le pilote AMD était hors de cause.

## Méthode de diagnostic, dans cet ordre

```powershell
$adb = 'D:\Android\Sdk\platform-tools\adb.exe'
& $adb devices                                              # le système répond-il ?
& $adb shell getprop sys.boot_completed                     # 1 = démarrage fini
& $adb shell dumpsys power   | Select-String mWakefulness   # Dozing / Asleep / Awake
& $adb shell dumpsys window  | Select-String mCurrentFocus  # quelle fenêtre au premier plan
```

- `Dozing` ou `Asleep` → simple veille, réveiller
- `Awake` **et** écran noir → là seulement, suspecter le rendu graphique

Réveil et retour à l'accueil :

```powershell
& $adb shell input keyevent 224        # KEYCODE_WAKEUP
& $adb shell cmd statusbar collapse    # referme le volet de notifications
& $adb shell input keyevent 3          # HOME
```

**`BACK` et `HOME` ne referment PAS le volet de notifications** quand il reste bloqué ouvert après un réveil. Seul `cmd statusbar collapse` y parvient. Symptôme : `mWakefulness=Awake` mais `mCurrentFocus=NotificationShade` et une capture toujours à ~19 Ko.

## Le piège de `stay_on_while_plugged_in`

Ce réglage n'agit que **si l'appareil se déclare en charge**. Après un `-wipe-data`, la batterie virtuelle repart sur `AC powered: false` — et l'écran se remet donc en veille malgré `stay_on = 7`. Il faut forcer l'alimentation secteur :

```powershell
& $adb shell dumpsys battery set ac 1
& $adb shell dumpsys battery set status 2
```

Vérification :

```powershell
& $adb shell dumpsys battery | Select-String 'AC powered|status'
```

Attendu : `AC powered: true` et `status: 2`. **À refaire après chaque effacement des données**, en même temps que les deux `settings put`.

**Indice utile** : le poids de la capture d'écran. 23 Ko = écran noir, ~3 Mo = interface réellement dessinée.

```powershell
& $adb shell screencap -p /sdcard/s.png; & $adb pull /sdcard/s.png D:\s.png
```

## Le correctif

```powershell
& $adb shell settings put global stay_on_while_plugged_in 7
& $adb shell settings put system screen_off_timeout 1800000
```

`stay_on_while_plugged_in = 7` couvre secteur + USB + sans-fil. L'émulateur se déclarant toujours « en charge », l'écran ne s'éteint plus jamais. Le réglage **persiste au redémarrage** (il vit sur la partition de données).

# 6. Piège n°6 — le plus coûteux : ne jamais lancer un installeur depuis Claude Code

**Android Studio a été lancé par Claude Code via `Start-Process`.** Un processus enfant **hérite du conteneur MSIX** du parent. Android Studio a donc tourné *dans* le conteneur, et tout ce qu'il a écrit sous `%LOCALAPPDATA%\Android\Sdk` est parti dans :

```
C:\Users\julie\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Android\Sdk
```

## Pourquoi c'est indétectable de l'intérieur

- l'interface d'Android Studio affichait `Android SDK Location: D:\Android\Sdk`
- `Test-Path` sur ce chemin répondait `True` depuis une session Claude
- les deux chemins renvoyaient **exactement la même taille (4,12 Go)** — parce que le « vrai » est redirigé vers le virtualisé

Le symptôme n'apparaît qu'**en dehors** de Claude : un double-clic sur le raccourci du bureau donnait

```
Windows ne trouve pas 'D:\Android\Sdk\emulator\emulator.exe'
```

## Le même piège sur les raccourcis

Un `.lnk` créé par `WScript.Shell` depuis le conteneur **résout et fige la cible en chemin virtualisé** :

```
Target : C:\Users\julie\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Android\Sdk\emulator\emulator.exe
```

Le raccourci ne fait alors rien du tout, sans message. Les **arguments**, eux, sont stockés littéralement — d'où un contournement possible : viser `cmd.exe` (dans `System32`, non virtualisé) et passer le vrai chemin en argument.

## Correctif retenu

Le SDK a été **sorti sur `D:\Android\Sdk`**, hors de toute virtualisation :

```powershell
robocopy 'C:\Users\julie\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Android\Sdk' `
         'D:\Android\Sdk' /E /MT:8
```

Puis : `skin.path` corrigé dans `config.ini`, raccourci repointé sur `D:\Android\Sdk\emulator\emulator.exe`. L'émulateur retrouve seul sa racine SDK à partir de son propre emplacement (`Found systemPath D:\Android\Sdk\system-images\...`). Le dossier `.android` (les AVD) n'était **pas** concerné : il vit à la racine du profil, hors `LocalAppData`.

**Preuve directe de la redirection de `%APPDATA%`** (2026-08-26) : après que l'utilisateur a repointé le SDK, le fichier `%APPDATA%\Google\AndroidStudio2026.1.3\options\android.sdk.path.xml` affichait

- `C:\Users\julie\AppData\Local\Android\Sdk` **lu depuis une session Claude**
- `D:\Android\Sdk` **lu par l'utilisateur dans sa propre console**

Deux contenus différents pour un chemin identique. **La redirection ne concerne donc pas que `%LOCALAPPDATA%` : `%APPDATA%` (Roaming) l'est aussi.** Conséquence pratique : depuis une session Claude, **on ne peut pas relire un réglage écrit par une application lancée hors conteneur** — la vérification revient à l'utilisateur.

> **Règles à retenir**
> 1. **Ne jamais faire lancer un installeur ou un IDE par Claude Code.** L'utilisateur le lance lui-même depuis le menu Démarrer.
> 2. Ne jamais installer sous `%LOCALAPPDATA%` sur ce poste — préférer `D:`.
> 3. Un `.lnk` créé depuis Claude vers une cible sous `%LOCALAPPDATA%` est cassé par construction.
> 4. Pour vérifier : comparer le chemin réel et `…\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\…`. **Deux tailles identiques = c'est le même dossier redirigé.**

Même famille que le piège du home Syncthing (`D:\SyncthingHome`) documenté dans `CLAUDE.md`.

# 7. Piège n°7 — le multi-écrans casse l'AVD

Une configuration d'écrans multiples essayée depuis l'interface a rendu la tablette inutilisable. Elle laisse des lignes dans `config.ini` :

```ini
hw.display1.width = 2160
hw.display1.height = 3840
hw.display1.density = 640
hw.display1.flag = 1739
```

Un `Wipe Data` seul **ne les enlève pas** — elles vivent dans `config.ini`, pas dans les données invité. Remise en état, émulateur arrêté :

1. supprimer toutes les lignes `hw.displayN.*` de `config.ini`
2. redémarrer avec `-wipe-data -no-snapshot-load`
3. **réappliquer les réglages invités** — `stay_on_while_plugged_in` et `screen_off_timeout` sont effacés par le wipe

Vérification du retour à un seul écran :

```powershell
& 'D:\Android\Sdk\platform-tools\adb.exe' shell dumpsys SurfaceFlinger --display-id
```

Une seule ligne attendue.

# 8. Point de restauration de la tablette

Une fois la tablette configuree - langue francaise, **compte Google connecte**, Play Store fonctionnel - cet etat vaut la peine d'etre fige. Le reconstituer a la main prend une bonne demi-heure.

## Ce qu'il ne faut PAS utiliser : l'instantane interne

L'emulateur sait enregistrer des instantanes (`snapshots\\`), mais ils sont a ecarter comme sauvegarde :

- ils contiennent une **image de la RAM** - avec 6 Go d'AVD, c'est **6 Go pour l'instantane seul** (9,06 Go de dossier AVD, dont 6 pour le seul `snapshots\\`)
- ils se cassent au moindre changement de version d'emulateur ou de configuration d'AVD
- ils vivent **dans** le dossier AVD : une corruption de l'AVD les emporte avec elle

Ce sont des caches de demarrage rapide, pas des sauvegardes.

## La bonne methode : copie froide du dossier AVD

**Emulateur arrete** - copier un `qcow2` en cours d'ecriture donne une image incoherente.

```powershell
& 'D:\Android\Sdk\platform-tools\adb.exe' -s emulator-5554 emu kill
Get-Process emulator,qemu-system-x86_64 -ErrorAction SilentlyContinue | Stop-Process -Force

$d = "D:\Android\Backups\Pixel_Tablet_$(Get-Date -Format 'yyMMdd')"
robocopy 'C:\Users\julie\.android\avd\Pixel_Tablet.avd' "$d\Pixel_Tablet.avd" /E /XD snapshots tmpAdbCmds /R:1 /W:1
Copy-Item 'C:\Users\julie\.android\avd\Pixel_Tablet.ini' "$d\Pixel_Tablet.ini" -Force
compact /c /s /i /f /exe:LZX "$d\*"
```

`/XD snapshots tmpAdbCmds` retire l'instantane : **9,06 Go -> 4,06 Go**. Apres restauration, le premier demarrage sera simplement a froid.

## Sur la compression

La compression NTFS **LZX** est transparente - rien a decompresser a la restauration. Mais le gain est faible : **4,06 Go -> 3,26 Go, soit 1,2 pour 1** seulement. Les donnees de `userdata` sont deja denses.

Ne pas chercher mieux avec une archive 7z : on gagnerait peut-etre 1 Go, au prix d'une etape de decompression au moment ou l'on est presse. Compter **~3,3 Go par point de restauration** et faire le menage dans les anciens.

## Repartition du volume

| Fichier | Taille |
|---|---|
| `userdata-qemu.img.qcow2` | 2 430 Mo |
| `sdcard.img` | 512 Mo |
| `cache.img.qcow2` + `cache.img` | 137 Mo |
| `snapshots\\` | ~6 Go - **exclu** |

## Restaurer

1. arreter l'emulateur et verifier qu'aucun processus ne subsiste
2. **renommer** l'AVD abime plutot que le supprimer (`Pixel_Tablet.avd.casse-AAMMJJ`)
3. `robocopy` de la sauvegarde vers `C:\Users\julie\.android\avd\Pixel_Tablet.avd`, plus le `.ini`
4. redemarrer avec `-no-snapshot-load`
5. ecran noir eventuel = veille, voir la section 5

## Ce que la sauvegarde ne contient PAS

Si le PC lui-meme est reinstalle, il faut d'abord remettre en place, dans cet ordre :

1. **SVM dans le BIOS** - avec la coupure secteur (section 1)
2. **le pilote AEHD** - sans lui l'emulateur ne demarre pas (section 3)
3. **le SDK sur `D:\Android\Sdk`** - jamais sous `%LOCALAPPDATA%` (section 6)

## Emplacement

```
D:\Android\Backups\Pixel_Tablet_260826\
    Pixel_Tablet.avd\
    Pixel_Tablet.ini
    RESTAURATION.md      <- procedure complete, sur place
```

## Piege annexe

Une redirection `> D:\dossier\fichier.log` dans un `cmd /c` echoue **silencieusement** si le dossier n'existe pas - et l'emulateur n'est alors jamais lance. Symptome : aucun processus, journal de 0 octet. Verifier l'existence du dossier de log avant de conclure a une panne de l'emulateur.

# 9. Piège n°8 — l'horloge de la tablette dérive et casse les applications

**Symptôme trompeur** : une application (ici *Le Monde*) semble privée d'Internet alors que la tablette navigue normalement. Le pare-feu Portmaster affiche au même moment une notification **Blocked Bypass Attempt by Netsimd** qui **n'est pas la cause** et détourne tout le diagnostic. Son conseil — « désactiver Secure DNS dans Netsimd » — est de surcroît inapplicable : `netsimd.exe` est le démon réseau de l'émulateur, il n'a aucun réglage de DNS sécurisé.

## Le vrai défaut

L'AVD reprend un **instantané** (*Quick boot*) : au réveil, l'horloge invitée repart de l'heure figée au moment de la sauvegarde et **ne se recale pas** sur celle du PC. Écart mesuré le 2026-08-31 : **4 jours et 18 heures de retard**.

Les serveurs rejettent alors toute requête signée. La preuve tient en une ligne d'`adb logcat` :

```
[LOGGER] error sending logs to kinesis - Signature expired:
20260826T234130Z is now earlier than 20260831T182829Z
```

AWS SigV4 tolère **5 minutes** d'écart, pas 5 jours. Tout ce qui repose sur une signature ou une expiration de jeton tombe : connexion, abonnement, contenus.

**⚠ `auto_time = 1` ne protège pas.** Le réglage « heure automatique » était bien actif et n'a rien rattrapé — il ne couvre pas la reprise d'instantané. Le vérifier ne sert à rien.

## Correctif

*Device Manager* → arrêter la tablette → menu `⋮` → **Cold Boot**.

**⚠ L'option n'apparaît pas tant que la tablette tourne** : le menu propose `Stop` à la place. C'est ce qui fait qu'on ne la trouve pas. Le libellé a par ailleurs perdu son « Now » dans les versions récentes.

Durablement, pour que la dérive ne revienne pas : *Edit* → *Show Advanced Settings* → **Boot option** → **Cold boot**. Équivalent dans `%USERPROFILE%\.android\avd\Pixel_Tablet.avd\config.ini` :

```
fastboot.forceColdBoot = yes
fastboot.forceFastBoot = no
```

**⚠ Android Studio n'écrit `config.ini` qu'à sa fermeture.** Après un changement dans l'interface, relire le fichier avant de conclure que le réglage est pris.

**⚠ `adb shell date -s` ne marche pas** : l'image `google_apis_playstore` n'est pas rootable. Le démarrage à froid est la seule voie.

**⚠ Ce chemin n'est PAS redirigé par le conteneur MSIX.** `C:\Users\julie\.android\` n'est ni `%LOCALAPPDATA%` ni `%APPDATA%` — vérifié le 2026-08-31, aucun jumeau sous `…\Packages\Claude_pzs8sxrjxfjjc\LocalCache\`. Une écriture y est donc réelle, contrairement au piège n°6.

## Vérification

Comparer les **époques**, pas l'affichage : la tablette est en **GMT**, le PC en heure de Paris.

```
adb shell date +%s ; date +%s
```

Attendu : quelques secondes d'écart au plus. Après recalage le 2026-08-31 — écart **1 seconde**, `Signature expired` disparu, application fonctionnelle.

## Méthode de diagnostic, dans cet ordre

**1. Écarter le pare-feu d'abord.** Sa notification est bruyante et fausse la piste. Mesurer la connectivité réelle depuis l'invité :

```
adb shell ping -c 2 8.8.8.8
adb shell curl -s -o /dev/null -w '%{http_code}' http://connectivitycheck.gstatic.com/generate_204
```

`HTTP 204` est la réponse qu'Android attend pour se déclarer connecté. Si elle arrive, Portmaster est hors de cause.

**2. Comparer les horloges.** Contrôle le moins cher et le plus rentable — il aurait fait gagner toute la séance.

**3. Lire le journal de l'application**, pas seulement celui du pare-feu :

```
adb logcat -d --pid $(adb shell pidof com.lemonde.androidapp)
```

C'est là, et nulle part ailleurs, que se trouvait `Signature expired`.

**⚠ `monkey` affiche `not connected` dans ses statistiques réseau** même quand tout va bien : c'est sa comptabilité interne, pas l'état de `ConnectivityManager`. Se fier à `dumpsys connectivity`, qui doit montrer `IS_VALIDATED`.

**⚠ Un logcat peut être périmé sans le dire** : le tampon affichait encore des lignes datées du 26/08 alors qu'on était le 31/08 — conséquence directe de la dérive. Vider (`adb logcat -c`) et relancer l'application avant de conclure.

**⚠ Le TLS n'était PAS cassé** malgré 5 jours d'écart : `curl` depuis l'invité rendait 200/301/404. Une horloge en retard ne casse que les certificats émis après elle. Ne pas s'arrêter à ce test pour disculper l'horloge.

## Ce que Portmaster bloquait réellement

Un seul blocage légitime à lever : **`cmp.lemonde.fr`**, la plateforme de consentement du Monde, classée traceur par la liste **TRAC**. Bloquée, l'application reste sur son écran de consentement — ce qui ressemble à une panne de réseau. Règle posée dans *Outgoing Rules* → **Allow**.

**⚠ Deux profils `netsimd.exe` coexistent** dans Portmaster, séquelle du piège n°6 : l'ancien sous `…\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Android\Sdk\` (mort depuis le 26/08) et le vrai sur `D:\Android\Sdk\emulator\`. Portmaster identifie les applications **par chemin de binaire** : une règle posée sur le mauvais profil ne fait rien, sans le moindre message.

**⚠ Ne pas taper le `+`** dans le champ de la règle — le menu *Allow* le pose lui-même, et `+ + cmp.lemonde.fr` échoue sur la regex de validation. Même piège que les *Incoming Rules* (`CLAUDE.md`, section « Portmaster »). À noter : *Outgoing Rules* est de niveau `user`, donc **visible en mode Simple**, contrairement aux *Incoming Rules*.

Le reste est **voulu** : `ws.batch.com`, `tracking.purchasely.io`, `logs13.xiti.com`, `firebase-settings.crashlytics.com` sont des traceurs. `ws.batch.com` reboucle indéfiniment — **4 224 requêtes en une journée**, toutes les 2 à 6 secondes — c'est bruyant dans le journal et sans effet sur l'application. Ne pas l'autoriser pour faire taire le journal.

**Portmaster laisse passer NTP** (`time.google.com` accepté) : il n'est pour rien dans la dérive d'horloge.

# 9. Piège n°8 — « auto » choisit le rendu LOGICIEL (lavapipe)

*2026-09-02.* Retours d'usage : tablette peu réactive, vidéo saccadée, son défaillant, « bord blanc inutile », écran trop petit. **Tout venait d'une seule cause.**

## Le diagnostic décisif : comparer les DEUX fichiers

`config.ini` porte ce qu'on a demandé. **`hardware-qemu.ini` porte ce que l'émulateur a réellement retenu au dernier lancement.** C'est ce second fichier qu'il faut lire.

```
config.ini         hw.gpu.mode = auto
hardware-qemu.ini  hw.gpu.mode = lavapipe     <-- rasteriseur Vulkan LOGICIEL
```

**`lavapipe`, c'est le processeur qui dessine tout.** Le GPU ne fait rien. À 2560x1600, cela représente 4,1 millions de pixels par image à la charge du CPU — d'où la lenteur, les saccades vidéo, et le son qui décroche (l'audio est sous-alimenté quand le CPU sature).

Chaîne d'échecs visible dans le journal de l'émulateur :

```
Failed to load [...\qemu\windows-x86_64\lib64\vulkan\vulkan-1.dll]
[Vulkan Loader] Registry lookup failed to get layer manifest files
Critical: Failed to load opengl32sw
Warning: Software OpenGL failed. Falling back to system OpenGL.
```

Le chemin Vulkan échoue, et `auto` se rabat silencieusement sur le logiciel. **Aucun message d'erreur visible dans l'interface.**

## Correctif

```ini
hw.gpu.mode = host
```

Vérification après relance — c'est le seul test qui compte :

```powershell
Get-Content 'C:\Users\julie\.android\avd\Pixel_Tablet.avd\hardware-qemu.ini' | Select-String 'gpu.mode'
```

Doit répondre `host`. Si `host` donne des artefacts, essayer **`angle_indirect`** (OpenGL traduit en Direct3D 11) : un peu plus lent, nettement plus robuste sur pilote ancien.

> **Suite (2026-09-03).** Le pilote a été mis à jour en Adrenalin 26.8.1 (voir page **295**). **Vulkan n'est toujours pas enregistré** pour autant : `HKLM\SOFTWARE\Khronos\Vulkan\Drivers` reste absente, l'installation `Driver Only` n'ayant pas recréé l'ICD supprimée par le `Factory Reset`. **Conserver `hw.gpu.mode = host` — repasser en `auto` ferait retomber en `lavapipe`.**

**Cause racine : le pilote AMD de janvier 2022** (voir page 249), qui expose mal Vulkan. `host` contourne le problème, il ne le corrige pas. Résultat après correction : **vidéo fluide et tablette nettement plus réactive**, confirmé par l'utilisateur.

## Le faux « cadre blanc » et l'écran trop petit : même cause

Le bord clair n'était **pas** le skin de la tablette — `hardware-qemu.ini` ne contenait aucune ligne `skin` ni `showDeviceFrame`, l'émulateur ne l'appliquait déjà plus.

C'était du **remplissage de fenêtre** : l'AVD faisait **2560x1600 pour un bureau logique de 2560x1440**. Impossible à afficher en entier, donc image réduite pour tenir, et le fond clair de l'émulateur comble le reste.

> **Règle : la définition de l'AVD doit tenir dans le bureau**, sinon l'image est réduite en permanence et entourée de remplissage.

Correctif appliqué — **1920x1200 en densité 240** :

| | Avant | Après |
|---|---|---|
| Définition | 2560x1600 | 1920x1200 |
| Densité | 320 | 240 |
| **Largeur en dp** | **800** | **800** (inchangée) |
| Pixels à calculer | 4,1 Mpx | 2,3 Mpx (**-44 %**) |

Les 800 dp sont conservés : **les mises en page tablette sont identiques**. Mais l'image tient dans l'écran sans réduction, la fenêtre peut être agrandie à la main, et le GPU travaille moins. Résultat confirmé : bord blanc disparu, écran nettement plus grand.

Retirer aussi `skin.name` et `skin.path` de `config.ini` (`showDeviceFrame = no` seul les rend inopérants, mais autant être net).

## Le son

Mesurer avant de conclure :

```powershell
& $adb shell cmd media_session volume --stream 3 --get
```

Le volume invité était déjà à **13/15** — il a été passé à 15.

> **Résolu, et la cause n'était pas l'audio.** Les ratés de son étaient un **symptôme de la saturation processeur** : quand le CPU dessinait 4,1 Mpx par image en `lavapipe`, le flux audio n'était plus alimenté à temps et décrochait. Une fois le rendu basculé sur `host` et la définition ramenée à 1920x1200, le son est redevenu correct sans aucun réglage audio supplémentaire. **Ne pas partir sur le mélangeur de volume Windows ni sur le périphérique de sortie tant que le rendu graphique n'est pas vérifié** — c'est une fausse piste coûteuse.

Note : la commande `media` n'existe pas sur cette image, il faut `cmd media_session`.

## Horloge : démarrage à froid obligatoire

La tablette affichait **lundi 31 août** alors que le PC était au **mercredi 2 septembre**. Cause déjà documentée sur ce poste : en *Quick boot*, l'horloge repart de l'heure figée dans l'instantané et **ne se recale jamais**.

```ini
fastboot.forceColdBoot = yes
fastboot.forceFastBoot = no
```

Après correction : `Wed Sep  2 21:18 GMT` côté tablette pour `23:18` côté PC — **le même instant**, l'écart n'étant que le fuseau. Le démarrage passe de ~20 s à 2-3 min : compromis accepté, une horloge fausse ayant déjà fait rejeter des requêtes signées et accuser Portmaster à tort.

**Le fuseau se règle à la main** dans la tablette (*Paramètres → Système → Date et heure*) : `setprop persist.sys.timezone` est **refusé** sur une image Google Play, qui est une build de production.

## Deux conséquences du démarrage à froid

1. **La tablette arrive verrouillée.** `mCurrentFocus=NotificationShade` désigne alors **l'écran de verrouillage**, pas le volet de notifications. Déverrouiller par un glissement : `adb shell input swipe 960 1000 960 200 200`.
2. **`dumpsys battery set ac 1` ne persiste pas** — c'est une valeur d'exécution. À chaque lancement la tablette repart sur batterie, donc `stay_on_while_plugged_in` ne s'applique pas. Seul `screen_off_timeout` (30 min) protège alors de la veille.

# 10. Dimensionner la mémoire — mesurer, ne pas deviner

*2026-09-02.* `qemu-system-x86_64` consommait **7 Go** sur les 16 de la machine. L'AVD avait été réglé à 6 Go « pour être tranquille ».

## La bonne mesure : `MemAvailable`, pas `MemFree`

```powershell
& 'D:\Android\Sdk\platform-tools\adb.exe' shell cat /proc/meminfo
```

Relevé à 6 Go :

```
MemTotal:        6 071 Mo
MemFree:         1 038 Mo
MemAvailable:    3 834 Mo     <-- 63 % reellement disponible
Cached:          3 429 Mo
SwapTotal / SwapFree : 4 554 / 4 111 Mo   -> 442 Mo utilises, aucune pression
```

**`MemFree` est trompeur** : Linux remplit toujours la mémoire inoccupée de cache disque, donc `MemFree` reste bas quoi qu'il arrive. C'est **`MemAvailable`** qui dit ce que le système peut réellement rendre — ici 63 %, plus 3,4 Go de cache purement opportuniste. Android n'utilisait qu'environ **2,2 Go de mémoire de travail**.

Second indice : la partition d'échange de l'invité n'était sollicitée qu'à **442 Mo sur 4 554**. Aucune contrainte mémoire.

## Résultat après passage à 4 Go

```ini
hw.ramSize = 4096
```

| | 6 Go | 4 Go |
|---|---|---|
| Guest `MemTotal` | 6 071 Mo | 4 013 Mo |
| Guest `MemAvailable` | 3 834 Mo (**63 %**) | 2 596 Mo (**65 %**) |
| `qemu` working set | **6 964 Mo** | **3 479 Mo** |
| Hôte libre | 3,1 Go | **6,9 Go** |

La mémoire de `qemu` est **divisée par deux** et Android conserve exactement la même marge relative. **3,8 Go rendus à l'hôte sans contrepartie mesurable.**

## Repères

- **4096 Mo** : le bon réglage pour cet usage (presse, lecture, quelques applications). Retenu.
- **3072 Mo** : encore faisable au vu des 2,2 Go de mémoire de travail constatés, mais ne laisse que ~800 Mo de cache — l'invité éviction­nerait plus souvent et s'appuierait sur son zram. À n'envisager que si l'hôte est vraiment à l'étroit.
- **6144 Mo** : surdimensionné. Ne rien attendre de plus qu'à 4 Go.

**Ne pas toucher à `vm.heapSize`** en même temps : c'est un **plafond par application**, pas une réservation. Le laisser à 512 Mo, c'est ce qui évite qu'une application de presse chargeant beaucoup d'images se fasse tuer sans message (voir section 4).

## Méthode réutilisable

1. laisser tourner la tablette en usage normal quelques minutes
2. lire `MemAvailable` et l'état du swap invité
3. si `MemAvailable` dépasse ~50 % et que le swap est quasi inutilisé, il y a de la marge à reprendre
4. réduire par paliers de 1 Go, **émulateur arrêté**, et remesurer
5. penser à recopier `config.ini` dans le point de restauration après chaque changement

# 11. Apres un deplacement du SDK : « Could not automatically detect an ADB binary »

*2026-09-06.* Boite de dialogue au demarrage de l'emulateur, apres la sortie du SDK vers `D:\\Android\\Sdk` (section 6).

L'emulateur ne cherche pas `adb` seulement a cote de lui : il consulte d'abord **`ANDROID_HOME`, `ANDROID_SDK_ROOT` et le `PATH`**, qui pointaient implicitement sur l'ancien emplacement disparu.

```
adb present       D:\Android\Sdk\platform-tools\adb.exe   OK
ANDROID_HOME      non defini
ANDROID_SDK_ROOT  non defini
platform-tools    absent du PATH
```

**Ce n'est pas anodin** : les fonctions de l'emulateur qui reposent sur adb tombent — **installation d'un APK par glisser-deposer sur la fenetre**, bouton de capture d'ecran des *Extended Controls*, envoi de fichiers. Les scripts qui appellent `adb` par un chemin absolu, eux, ne sont pas concernes.

**Correctif** — a taper par l'utilisateur dans sa propre console, **non elevee** :

```powershell
[Environment]::SetEnvironmentVariable('ANDROID_HOME','D:\Android\Sdk','User')
[Environment]::SetEnvironmentVariable('ANDROID_SDK_ROOT','D:\Android\Sdk','User')
[Environment]::SetEnvironmentVariable('PATH',
  [Environment]::GetEnvironmentVariable('PATH','User') + ';D:\Android\Sdk\platform-tools', 'User')
```

Fermer puis rouvrir l'emulateur : les variables ne sont lues qu'au demarrage du processus. Benefice annexe, `adb` devient utilisable sans chemin dans n'importe quelle console.

Repli si l'on ne veut rien toucher au systeme : **`...`** (Extended Controls) -> **Settings** -> onglet **General** -> decocher *Use detected ADB location* et indiquer le chemin. Reglage propre a l'emulateur, sans effet ailleurs.

## Precision sur la redirection MSIX : le registre se lit, mais ne s'ecrit pas

Constate a cette occasion : les valeurs ecrites par l'utilisateur dans `HKCU\\Environment` sont **immediatement visibles depuis une session Claude Code**, contrairement aux fichiers sous `%LOCALAPPDATA%` et `%APPDATA%` (section 6).

C'est le comportement classique de MSIX pour le registre : **lecture directe, ecriture redirigee**.

> **Consequence pratique** : une variable d'environnement utilisateur **peut etre verifiee** depuis Claude Code — ce qui n'est pas le cas d'un fichier de configuration. En revanche, presumer qu'une **ecriture** depuis Claude serait visible a l'exterieur reste faux. La regle « c'est l'utilisateur qui ecrit » ne change pas ; seule la verification devient possible.

# Aide-mémoire

## Chemins

```
Android Studio   C:\Program Files\Android\Android Studio
SDK              D:\Android\Sdk   (sorti du conteneur MSIX, voir section 6)
adb              ...\Sdk\platform-tools\adb.exe
emulator         ...\Sdk\emulator\emulator.exe
AVD              C:\Users\julie\.android\avd\Pixel_Tablet.avd
Raccourci        C:\Users\julie\Desktop\Tablette Android.lnk
```

## Commandes

```powershell
# Démarrer (le raccourci du bureau fait la même chose)
& '...\Sdk\emulator\emulator.exe' -avd Pixel_Tablet

# Démarrage propre, si un boot se passe mal
& '...\Sdk\emulator\emulator.exe' -avd Pixel_Tablet -no-snapshot-load

# Lister les AVD / arrêter proprement
& '...\Sdk\emulator\emulator.exe' -list-avds
& '...\adb.exe' -s emulator-5554 emu kill

# Installer un APK (ou glisser-déposer le fichier sur la fenêtre)
& '...\adb.exe' install monapp.apk
& '...\adb.exe' install-multiple base.apk split_config.arm64_v8a.apk split_config.xxhdpi.apk
```

Les dépôts type APKMirror servent souvent des `.xapk` / `.apkm` : ce sont des archives ZIP de plusieurs APK. `adb install` échoue dessus, il faut les décompresser et utiliser `install-multiple`.

**Premier démarrage : 2 à 3 minutes, sans aucune fenêtre visible pendant une bonne partie du temps.** Ne pas conclure trop vite que le raccourci ne marche pas — vérifier le processus :

```powershell
Get-Process emulator,qemu-system-x86_64 -ErrorAction SilentlyContinue
```

Les démarrages suivants réutilisent l'instantané, environ 20 secondes.

# Limites connues

- **Applications bancaires et de paiement** : Play Integrity échoue systématiquement sur émulateur
- **Vidéo protégée** (Netflix, Disney+, MyCanal) : pas de Widevine L1
- **Jeux avec anti-triche** : détection d'émulateur
- **Matériel absent** : NFC, appareil photo réel, SIM et téléphonie, empreinte digitale

Presse, lecture, productivité et utilitaires : sans problème.

# Voies écartées

| Option | Raison |
|---|---|
| **Émulateur sur le VPS juxjux** | La virtualisation imbriquée y est pourtant active (`/dev/kvm`, `kvm_intel.nested=Y`) — mais 2,7 Gio de RAM disponibles seulement, swap déjà à moitié plein, aucun GPU, et usage interactif à travers le réseau. Redroid exigerait en plus un changement de noyau : le noyau `cloud` n'a pas `CONFIG_ANDROID_BINDER_IPC` |
| **BlueStacks / LDPlayer / MEmu / Nox** | Mêmes prérequis de virtualisation, plus publicité et télémétrie |
| **Genymotion** | Dépend de VirtualBox, déjà impliqué dans le dossier écrans bleus (page 249) |
| **Waydroid sur l'Ubuntu 25.10** | Reste une **bonne solution de repli** : conteneur LXC, **aucun besoin de VT-x/AMD-V**. Aurait été retenu si SVM était resté inaccessible |
| **scrcpy + tablette existante** | Écarté ici, mais pertinent : recopie l'écran d'une Lenovo Tab K11 ou d'une SM-T720 sur le PC, sans virtualisation ni émulateur |

# Points restés ouverts

- **Le pilote AMD de janvier 2022 n'est toujours pas réinstallé** (action en attente de la page 249). Les erreurs `UpdateLayeredWindowIndirect` du journal de l'émulateur en sont un symptôme de plus, même si elles n'ont pas empêché le fonctionnement.
- **Résolu.** Le *Virtual Device Manager* n'apparaissait pas dans *More Actions* : Android Studio tournait alors dans le conteneur MSIX, sur un SDK dont l'émulateur n'était pas correctement enregistré. Une fois Studio relancé **par l'utilisateur** et repointé sur `D:\Android\Sdk`, l'entrée est présente et l'AVD `Pixel_Tablet` y figure. Même cause racine que le reste — ce n'était pas une bizarrerie d'interface.
- **Le réglage *Cold boot* n'est pas encore persisté** dans `config.ini` — toujours `fastboot.forceFastBoot = yes` au 2026-08-31. Le démarrage à froid du jour a recalé l'horloge, mais la dérive reviendra à la prochaine reprise d'instantané après quelques jours d'arrêt. L'instantané `snapshots/default_boot` pèse par ailleurs **6,1 Go** sur le SSD système ; le supprimer force aussi un démarrage à froid et rend la place, sans toucher aux données de la tablette (`userdata-qemu.img`).

# Voir aussi

- Page **249** — stabilité du PC `julie`, écrans bleus, pilote AMD
- `Jux-scripts/PC-Health/bios_svm_a320m.md` — fiche BIOS pas à pas
- `CLAUDE.md`, section « Poste Windows `julie` » — piège MSIX, outillage du poste

# 260903 - Mise à jour du pilote AMD

Procédure préparée le 2026-09-02, à exécuter le 2026-09-03 sur le poste `julie`.

Objectif : remplacer le pilote graphique AMD **du 18 janvier 2022** par la version actuelle. Deux motifs indépendants, chacun suffisant à lui seul.

# Pourquoi

**1. C'est la cause établie des écrans bleus `0x50`.** L'analyse du vidage mémoire du 31/07/2026 désigne `amdfendr.sys` (AMD Crash Defender) v21.30.0.9 : le pilote appelle `RtlCompressBuffer` avec une taille supérieure à l'allocation réelle, LZNT1 lit au-delà et tombe sur une page non mappée. `MODULE_NAME: amdfendr`, confirmé par deux rapports WER. Analyse complète : **page 249**.

**2. C'est aussi ce qui dégradait l'émulateur Android.** Le support Vulkan de ce pilote est défaillant : le chargement de l'ICD échouait, et l'émulateur se rabattait silencieusement sur `lavapipe`, un rasteriseur **purement logiciel**. Détail : **page 282, section 9**.

# État avant intervention

À relever pour pouvoir comparer après.

| Élément | Valeur au 2026-09-02 |
|---|---|
| Carte | AMD Radeon RX 6500 XT (Navi 24, `0x743F`), 4 Go |
| Pilote | `30.0.14023.3004` |
| Date du pilote | **18/01/2022** |
| `amdfendr.sys` | **21.30.0.9**, fichier du 07/02/2022 |
| `amdfendrmgr.sys` | 21.30.0.9, fichier du 07/02/2022 |
| OS | Windows 10 19045, UEFI |
| Point de restauration | **`11` — `260903-maj pilotes carte grapphique`**, 03/09/2026 03:09 |

# Précautions propres à cette machine

**⚠ L'utilisateur lance l'installeur lui-même.** Un processus démarré par Claude Code hérite de son conteneur MSIX et installe au mauvais endroit, de façon indétectable depuis la session. Voir page 282, section 6.

**⚠ Pas par temps d'orage, ni en période de coupures.** Ce poste compte **146 arrêts brutaux** au compteur SMART du SSD et a subi des coupures secteur avérées (Enedis le 24/08). Un flash de pilote graphique interrompu par une coupure est l'un des rares moments où l'on casse réellement quelque chose.

**⚠ Une seule opération à risque à la fois.** Ne pas enchaîner avec une mise à jour du BIOS, même si l'occasion se présente. Le BIOS 1.40 de 2020 reste volontairement en place.

**⚠ winget est inutile ici.** Il ne propose que `AMD.AMDSoftwareCloudEdition`, destiné aux serveurs de jeu en nuage — **à ne pas installer**. Le téléchargement vient du site AMD.

# Procédure

## 1. Poser le filet

Dans une console PowerShell **en administrateur** (la protection système était déjà active sur ce poste — trois points existaient déjà des 26, 27 et 28/08) :

> **⚠ Angle mort à connaître.** `Get-ComputerRestorePoint` **exige l'élévation** : depuis une session Claude Code, non élevée, il renvoie une liste vide, ce qui fait conclure à tort que la protection système est désactivée. Erreur commise le 2026-09-02. **La vérification revient à l'utilisateur**, dans sa propre console élevée — même famille d'angle mort que la lecture de `%APPDATA%` (page 282, section 6).

> Autre piège : Windows **refuse de créer un second point dans les 24 h** suivant le précédent. `Checkpoint-Computer` peut donc échouer en silence.

```powershell
Enable-ComputerRestore -Drive 'C:\'
Checkpoint-Computer -Description 'Avant pilote AMD' -RestorePointType MODIFY_SETTINGS
```

Vérifier qu'il est bien créé :

```powershell
Get-ComputerRestorePoint | Select-Object SequenceNumber,Description,CreationTime
```

## 2. Télécharger

`amd.com/fr/support` → **Graphics** → **Radeon RX 6000 Series** → **Radeon RX 6500 XT** → **Windows 10 - 64-Bit**

Prendre l'édition **Recommended (WHQL)**, pas l'Optional : plus prudente sur une machine dont la stabilité est en cours d'investigation.

## 3. Installer

Deux choix à ne pas manquer dans l'installeur :

- **Cocher `Factory Reset`** — supprime proprement les restes du pilote de 2022. C'est ce qui évite d'avoir à passer par DDU en mode sans échec.
- **Choisir `Driver Only`** (ou *Minimal*) si l'option est proposée — la suite Adrenalin complète (enregistrement vidéo, AMD Link, surcouche de jeu) n'a aucun usage ici et ajoute des services résidents sur une machine déjà fragile.

L'écran clignote et devient noir plusieurs secondes pendant l'opération : c'est normal.

## 4. Redémarrer et vérifier

```powershell
Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,DriverDate | Format-List
(Get-Item 'C:\Windows\System32\drivers\amdfendr.sys').VersionInfo.FileVersion
```

Attendu : une date récente, et `amdfendr.sys` **sorti de la 21.30.0.9**.

## 5. Contrôles complémentaires

**Côté émulateur Android** — vérifier que l'accélération répond toujours :

```powershell
& 'D:\Android\Sdk\emulator\emulator.exe' -accel-check
```

Puis, après un lancement de la tablette, que le rendu n'est pas retombé en logiciel :

```powershell
Get-Content 'C:\Users\julie\.android\avd\Pixel_Tablet.avd\hardware-qemu.ini' | Select-String 'gpu.mode'
```

**Laisser `hw.gpu.mode = host`.** Même si Vulkan est réparé, un réglage explicite qui fonctionne vaut mieux qu'un `auto` susceptible de retomber en `lavapipe` sans le moindre message.

**Côté stabilité** — relancer le relevé après deux à trois semaines :

```powershell
Jux-scripts\PC-Health\collect_bsod.ps1
```

Le script signale la version d'`amdfendr.sys` à chaque passage ; il doit cesser de la marquer comme problématique.

# Retour arrière

Si l'affichage se dégrade ou si de nouveaux plantages apparaissent :

1. **Restauration système** sur le point créé à l'étape 1
2. À défaut : *Gestionnaire de périphériques* → carte graphique → *Propriétés* → onglet *Pilote* → **Restaurer le pilote précédent**
3. En dernier recours : **DDU en mode sans échec**, puis réinstallation propre

# Ce qu'il ne faut PAS en attendre

La page 249 distingue **deux populations d'arrêts anormaux**, et cette mise à jour n'en traite qu'une.

| Population | Traitée ? |
|---|---|
| **15 écrans bleus** (3× `0x50` attribués à `amdfendr`, 10× `0x9F`, 1× `0x3B`, 1× `0xA0`) | **Oui**, c'est l'objet de l'intervention |
| **30 coupures sèches** (`BugcheckCode = 0`, aucune trace) | **Non** — hypothèse électrique externe, un onduleur trancherait |

Les 146 arrêts brutaux du compteur SSD, dont une centaine antérieurs à la réinstallation d'octobre 2025, appartiennent à la seconde catégorie. **Ne pas conclure à un échec de la mise à jour si des coupures sèches persistent.**

# Après l'intervention

Mettre à jour :

- **page 249** — journal de stabilité, version du pilote, retrait de l'action en attente
- **page 282, section 9** — indiquer si Vulkan est réparé et si `auto` redevient sûr


# Résultats — intervention du 2026-09-03

Version installée : **AMD Software: Adrenalin Edition 26.8.1 (WHQL Recommended)**, paquet de 942 Mo téléchargé depuis amd.com, avec **`Factory Reset` coché** et installation **`Driver Only`**.

Point de restauration préalable : `11 — 260903-maj pilotes carte grapphique`, 03/09/2026 03:09. Non utilisé.

## Avant / après

| | Avant | Après |
|---|---|---|
| Pilote affiché | `30.0.14023.3004` | **`32.0.21045.5002`** |
| Date du pilote | 18/01/2022 | **17/08/2026** |
| `amdfendr.sys` **actif** | 21.30.0.9 (07/02/2022) | **25.10.0.7 (25/02/2026)** |
| `amdpsp.sys` | 5.24.0.0 | 5.46.0.0 (19/06/2026) |

Quatre ans et sept mois rattrapés. **La version d'`amdfendr.sys` identifiée comme cause des écrans bleus `0x50` est remplacée** — c'était l'objet de l'intervention.

## ⚠ Piège de vérification : lire le service, pas le fichier

Le premier contrôle a fait croire à un échec :

```
C:\Windows\System32\drivers\amdfendr.sys    21.30.0.9    07/02/2022
```

**Ce fichier est un résidu de l'installation de 2022 que Windows n'utilise pas.** Le pilote réellement chargé est désigné par le service :

```
HKLM\SYSTEM\CurrentControlSet\Services\amdfendr
  ImagePath = \SystemRoot\System32\DriverStore\FileRepository\
              amdfendr.inf_amd64_bea53a1d416fbcfa\amdfendr.sys   -> v25.10.0.7, 25/02/2026
```

Les deux versions cohabitent dans le DriverStore (`...9c52cee6bd9e4fb5` pour l'ancienne, `...bea53a1d416fbcfa` pour la nouvelle) ; seule la seconde est enregistrée.

> **Règle : après une mise à jour de pilote, vérifier `ImagePath` du service, jamais le fichier dans `System32\drivers`.** Ce dernier peut rester périmé indéfiniment sans que cela signifie quoi que ce soit.

Commande de contrôle :

```powershell
(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\amdfendr').ImagePath
```

État du service : `Start = 3` (démarrage manuel), actuellement arrêté.

## ⚠ Vulkan n'est TOUJOURS pas enregistré

C'est le point décevant de l'intervention.

```
HKLM\SOFTWARE\Khronos\Vulkan\Drivers             absente
HKLM\SOFTWARE\WOW6432Node\Khronos\Vulkan\Drivers absente
C:\Windows\System32\amdvlk64.dll                 absent
```

Les bibliothèques existent pourtant dans le DriverStore (`amdvlk64.dll`, `amdxc64.dll` dans deux paquets), mais **aucune ICD n'est déclarée** : Vulkan reste inutilisable. Le `Factory Reset` a vraisemblablement supprimé la clé sans que l'installation `Driver Only` la recrée.

Seules entrées présentes sous `Khronos\Vulkan\ImplicitLayers` : les deux couches de Steam.

**Conséquence pour l'émulateur Android : garder `hw.gpu.mode = host`, ne pas repasser en `auto`** — il retomberait en `lavapipe` (page 282, section 9). Le réglage explicite reste nécessaire.

Si Vulkan devient un besoin (jeux, applications tierces), il faudra relancer l'installeur **sans** `Driver Only`, en acceptant la suite Adrenalin complète.

## Émulateur — non régressé

```
emulator -accel-check     AEHD (version 2.2) is installed and usable.   code 0
hardware-qemu.ini         hw.gpu.mode = host
Definition                1920x1200
MemTotal invite           4 013 Mo
Focus                     NexusLauncherActivity
```

## Ce qui reste à surveiller

La page **249** distingue deux populations d'arrêts anormaux. Cette mise à jour n'en traite qu'une.

- **15 écrans bleus** — traités. Relevé de contrôle à relancer dans deux à trois semaines : `Jux-scripts\PC-Health\collect_bsod.ps1`
- **30 coupures sèches** (`BugcheckCode = 0`) — **non traitées**, hypothèse électrique externe. Leur persistance ne signifierait pas un échec de l'intervention ; elle isolerait au contraire définitivement la piste de l'alimentation.