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.

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

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 :

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

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 :

Ce que la réinstallation établit en revanche sans ambiguïté :

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 :

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

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 :

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 :

(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 :

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) :

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 :

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.

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 :

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.

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 :

# 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

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 *

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

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

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 :

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

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

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

& '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

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

$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

Réveil et retour à l'accueil :

& $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 :

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

Vérification :

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

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

Le correctif

& $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

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 :

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

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 :

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 :

& '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 :

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.

& '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

hw.gpu.mode = host

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

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 :

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

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

& '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

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

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 :

[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

# 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 :

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

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

Limites connues

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

Voir aussi

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.

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

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

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 :

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

4. Redémarrer et vérifier

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 :

& '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 :

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 :

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 :

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 :

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