260803-suivi des logs de dysfonctionnement du PC - écrans bleus de la mort
Suivi des dysfonctionnements du PC eliob — écrans bleus
Machine : PC Windows eliob (pcelio)
Analyse initiale : 2026-08-03 — Claude Code
Fenêtre observée : 29/10/2025 → 03/08/2026 (Windows réinstallé le 28/10/2025, le journal ne remonte pas plus loin)
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 |
| Mémoire | 1 seule barrette 16 Go TEAMGROUP UD4-2666 (DIMM 0, canal B) — cadencée à 2400 MHz (sous sa fréquence nominale de 2666) |
| Disque système | SSD SATA Patriot Burst 240 Go (C: — 71 Go libres) |
| Disque secondaire | HDD SATA Toshiba HDWD110 1 To (D:) |
| Périphériques USB | ASMT 2115 1 To (E:), Seagate Backup+ Hub 8 To (F:), SanDisk 3.2Gen1 64 Go |
| OS | Windows 10 Famille 22H2 — build 19045, installé le 28/10/2025 |
| Boîtier / assemblage | Megaport, modèle 130430 |
Remarque sur l'âge : Julien évalue le PC à 9 ans d'usage intensif. Le Ryzen 2600X date de 2018 et la carte A320M-A PRO de 2019-2020 — le cœur de la machine a donc plutôt 6-7 ans. Le boîtier, l'alimentation et les ventilateurs peuvent être plus anciens s'ils ont été repris d'une configuration précédente. L'alimentation n'a pas pu être identifiée par logiciel — c'est une information à relever physiquement (marque, modèle, wattage, année), elle est déterminante pour la suite du diagnostic.
2. Méthode
Sources interrogées sur le poste, sans installation d'outil tiers :
- Journal
System— événementsKernel-Power 41(arrêt inattendu),BugCheck 1001(code d'erreur BSOD),WHEA-Logger(erreurs matérielles remontées par le firmware),volmgr,Ntfs,disk - Propriétés internes des événements 41 (
BugcheckCode,BugcheckParameter1,PowerButtonTimestamp) — ce sont elles qui permettent de distinguer un vrai BSOD d'une coupure sèche - Corrélation temporelle événement par événement (dernier événement journalisé avant chaque redémarrage, présence ou non d'un arrêt propre
1074/13juste avant) - Inventaire matériel WMI/CIM, état SMART exposé par Windows, configuration d'alimentation et de vidage mémoire, dates et versions des pilotes tiers
Point de méthode important : les événements 41 et 1001 sont horodatés au redémarrage suivant, pas à l'instant du crash. Comme le redémarrage automatique est activé (AutoReboot=1), les deux coïncident à la minute près pour les BSOD — mais il ne faut jamais lire ces horodatages comme « l'heure de la panne » sans cette vérification.
3. Chiffres clés
| Indicateur | Valeur |
|---|---|
Arrêts anormaux (Kernel-Power 41) |
45 en 9 mois |
| dont écrans bleus réels (avec code bugcheck) | 15 (33 %) |
dont coupures sèches sans BSOD (BugcheckCode = 0) |
30 (67 %) |
Erreurs matérielles WHEA-Logger |
0 |
| Erreurs disque / NTFS critiques (90 j) | 2 Ntfs 50, 3 volmgr 161 (échec d'écriture du dump) |
| Bouton d'alimentation maintenu (arrêt forcé manuel) | 1 seul cas — 20/05/2026 20:35 |
Arrêt propre demandé (1074/13) juste avant le crash |
0 cas sur 45 |
Fréquence : environ 1 arrêt anormal tous les 6 jours en moyenne, avec des grappes (2 crashes le même jour à 5 reprises).
4. Deux populations de pannes bien distinctes
Population A — 30 coupures sèches, sans écran bleu (67 %)
BugcheckCode = 0, PowerButtonTimestamp = 0 : le système s'est arrêté sans produire de vérification d'erreur, sans que le bouton d'alimentation ait été maintenu, et sans qu'un arrêt ait été demandé. Le dernier événement journalisé précède le redémarrage de moins d'une minute dans la quasi-totalité des cas.
C'est le profil d'une coupure d'alimentation, d'un reset matériel ou d'un gel total du noyau — Windows n'a pas eu le temps d'écrire quoi que ce soit.
Ces 30 événements sont répartis sur toute la période (octobre 2025 → juillet 2026), sans lien avec les vagues de BSOD. C'est la population la plus préoccupante pour une hypothèse matérielle, et c'est aussi celle sur laquelle les logs sont, par construction, muets.
Population B — 15 écrans bleus avec code d'erreur (33 %)
| Code | Nb | Nom | Signification |
|---|---|---|---|
0x0000009F |
10 | DRIVER_POWER_STATE_FAILURE | Un pilote bloque une requête de changement d'état d'alimentation (mise en veille, reprise, arrêt). Paramètre 1 = 0x3 dans les 10 cas : un objet de périphérique bloque une IRP trop longtemps. |
0x00000050 |
3 | PAGE_FAULT_IN_NONPAGED_AREA | Accès à une adresse mémoire invalide. Paramètre 4 = 0x2 : la faute survient sur une tentative d'exécution de code, pas une lecture/écriture de données. |
0x0000003B |
1 | SYSTEM_SERVICE_EXCEPTION | Exception 0xC0000005 (violation d'accès) en mode noyau. |
0x000000A0 |
1 | INTERNAL_POWER_ERROR | Erreur interne du gestionnaire d'alimentation. |
12 des 15 BSOD (80 %) sont des erreurs liées à une transition d'alimentation (0x9F + 0xA0). Aucun n'est précédé d'une demande d'arrêt propre → il s'agit de transitions veille S3 / reprise / démarrage rapide, pas d'un arrêt lancé depuis le menu Démarrer.
5. Chronologie — trois régimes successifs
| Période | Régime dominant |
|---|---|
| 29/10/2025 → 23/12/2025 | Uniquement des coupures sèches (2 événements) |
| 25/12/2025 → 29/03/2026 | Vague de 10 × 0x9F — DRIVER_POWER_STATE_FAILURE, souvent 2 le même jour, entremêlée de coupures sèches |
| 16/04/2026 → 19/05/2026 | 1 × 0xA0, 1 × 0x3B — puis les BSOD cessent |
| 19/05/2026 → 28/07/2026 | Retour aux seules coupures sèches (7 événements) |
| 31/07/2026 → 03/08/2026 | Nouvelle vague : 3 × 0x50 en 4 jours |
Les BSOD ne sont donc pas un phénomène continu : ce sont des vagues qui apparaissent et disparaissent, ce qui est le comportement typique d'une cause logicielle (installation ou mise à jour d'un pilote). Les coupures sèches, elles, sont présentes en continu du premier au dernier jour — comportement typique d'une cause matérielle.
6. Suspect principal de la vague en cours : le pilote réseau VirtualBox
VBoxNetLwf — VirtualBox NDIS6 Bridged Networking Driver, version 7.2.14.174565
Le journal System contient 20 erreurs VBoxNetLwf (ID 12) : « Le pilote a détecté une erreur de pilote interne sur \Device\VBoxNetLwf ».
Toutes sont comprises entre le 24/07/2026 06:55 et le 03/08/2026 07:43 — soit exactement depuis l'installation d'Oracle VirtualBox 7.2.14 le 24/07/2026 (fichiers pilotes datés du 17/07/2026). Aucune avant.
Le rythme est de deux erreurs par jour — une le matin, une le soir :
| Date | Matin | Soir |
|---|---|---|
| 24/07 | 06:55 | 18:02 |
| 27/07 | 08:02 | 18:22 |
| 29/07 | 06:27 | 17:36 |
| 30/07 | 07:25 | 19:10 |
| 02/08 | 06:36 | 21:54 |
C'est-à-dire à chaque allumage et à chaque extinction — exactement le symptôme décrit par Julien.
Corrélation avec les 3 écrans bleus 0x50 :
Erreur VBoxNetLwf |
Écran bleu correspondant | Écart |
|---|---|---|
| 31/07/2026 06:27:21 | BugCheck 0x50 à 06:27:34 |
13 s |
| 31/07/2026 08:54:01 | BugCheck 0x50 à 08:54:14 |
13 s |
| 03/08/2026 07:43:26 | BugCheck 0x50 à 07:43:37 |
11 s |
Et le 28/07/2026 07:52:02, une erreur VBoxNetLwf coïncide à la seconde près avec une coupure sèche sans BSOD.
Élément technique qui renforce fortement l'hypothèse : les trois 0x50 partagent le même déplacement 0x3ae dans l'adresse d'instruction fautive (…3c5903ae, …1db903ae, …091903ae), pour des adresses de base différentes. Autrement dit : la même ligne de code d'un même pilote plante à chaque fois, à une adresse de chargement différente selon le démarrage. C'est la signature d'un défaut logiciel reproductible, et non d'une cellule mémoire défectueuse — une RAM défaillante produirait des adresses dispersées et aléatoires.
VBoxNetLwf est un filtre NDIS léger : il s'insère dans la pile réseau et est sollicité à chaque transition d'alimentation. C'est un candidat cohérent à la fois pour les 0x50 récents et, dans son principe, pour la famille 0x9F.
Correction d'une attribution antérieure
Le fichier CLAUDE.md attribue les écrans bleus 0x50 du 31/07/2026 aux pilotes RustDesk (écran virtuel usbmmidd_v2 et imprimante virtuelle), désactivés le jour même par renommage en .disabled.
Cette explication ne tient plus : un quatrième 0x50 s'est produit le 03/08/2026 à 07:43, avec la même signature 0x3ae, alors que usbmmidd_v2 était désactivé depuis trois jours. La désactivation des pilotes RustDesk n'a donc pas résolu le problème. Les deux logiciels ayant été installés dans la même fenêtre (VirtualBox le 24/07, RustDesk le 31/07), la coïncidence de dates avait masqué le vrai suspect. À noter toutefois que le dossier C:\Program Files\RustDesk\drivers est toujours présent et n'a pas été désactivé.
7. Ce que les logs ne permettent PAS d'accuser
Il faut être clair sur ce point : à ce stade, aucune donnée ne désigne un composant électronique défectueux.
| Vérification | Résultat | Interprétation |
|---|---|---|
WHEA-Logger (erreurs machine remontées par le firmware : CPU, mémoire, bus PCIe, cache) |
0 événement sur 9 mois | Aucune erreur matérielle corrigible ou fatale détectée par le processeur. C'est un signal négatif fort contre une défaillance CPU ou mémoire franche. |
| État de santé des 5 disques | Tous Healthy / OK |
Aucune alerte |
| Prédiction de panne SMART (WMI) | Aucune remontée | Voir la limite ci-dessous |
| Erreurs disque / NTFS | 2 Ntfs 50 + 3 volmgr 161 en 90 jours |
Les volmgr 161 sont des conséquences des crashes (échec d'écriture du fichier de vidage), pas des causes |
Nuance importante sur WHEA : l'absence d'erreur WHEA ne disculpe pas le matériel pour la Population A. Une coupure d'alimentation brutale ou un gel total ne laisse par définition aucune trace, puisque le système n'a plus le temps d'écrire. WHEA ne couvre pas non plus les défaillances d'alimentation, de VRM ou de connectique.
Limite sur SMART : Windows n'expose aucun compteur SMART pour ces disques via l'API standard (Get-StorageReliabilityCounter ne renvoie rien, y compris la température, les heures de fonctionnement et les secteurs réalloués). Le contrôleur SATA du chipset A320 ne relaie pas ces données. L'état réel du SSD Patriot Burst — notamment son taux d'usure et ses secteurs réalloués — est donc à ce jour inconnu. C'est une lacune à combler en priorité : ce SSD est le disque système, c'est un modèle d'entrée de gamme, et une usure avancée expliquerait des gels au démarrage.
8. Facteurs aggravants identifiés dans la configuration
Démarrage rapide activé (HiberbootEnabled = 1)
Le démarrage rapide (Fast Startup) est actif. Avec ce réglage, « Arrêter » n'éteint pas réellement Windows : le noyau et les pilotes sont mis en hibernation dans un fichier, puis rechargés tels quels au démarrage suivant.
Conséquences directes sur ce cas :
- C'est la première cause connue des écrans bleus
0x9F— qui représentent 10 des 15 BSOD relevés ici. - Cela explique qu'aucun crash ne soit précédé d'un arrêt propre dans les logs : les transitions concernées sont des hibernations/reprises, pas de vrais arrêts.
- Un état de pilote corrompu (celui de
VBoxNetLwf, par exemple) est réinjecté à chaque démarrage au lieu d'être réinitialisé — ce qui transforme un bug ponctuel en panne récurrente.
Mémoire : une seule barrette, sous-cadencée
Un seul module de 16 Go occupant DIMM 0 (canal B) — donc pas de double canal, et la barrette tourne à 2400 MHz au lieu de 2666. Ce n'est pas une cause de panne en soi, mais c'est une configuration à connaître. Point positif pour le diagnostic : avec une seule barrette, un test mémoire est simple à interpréter et il n'y a pas de problème d'appairage possible.
BIOS de 2020
Version 1.40 datée du 08/12/2020, jamais mise à jour depuis. MSI a publié des révisions ultérieures pour l'A320M-A PRO, comportant des correctifs AGESA sur la gestion de l'alimentation et la compatibilité mémoire — directement pertinents pour des erreurs 0x9F et 0xA0.
Espace disque système
71 Go libres sur 223 Go (C:) — suffisant, mais à surveiller : le fichier MEMORY.DMP occupe à lui seul 2,4 Go.
9. Diagnostic de synthèse
Il y a très probablement deux problèmes distincts, pas un seul.
Problème 1 — logiciel, actif en ce moment, identifié avec un bon niveau de confiance.
Le pilote réseau VBoxNetLwf de VirtualBox 7.2.14 échoue à chaque transition d'alimentation depuis son installation le 24/07/2026, et a provoqué 3 écrans bleus 0x50 en 4 jours. La signature d'adresse identique (0x3ae) confirme un défaut de code reproductible. Le démarrage rapide amplifie le phénomène. C'est traitable immédiatement et sans risque.
Problème 2 — cause encore indéterminée, présent en continu depuis au moins octobre 2025.
30 coupures sèches réparties sur 9 mois, sans aucune trace exploitable. La vague de 10 × 0x9F de l'hiver 2025-2026 relève probablement aussi d'un pilote (autre que VirtualBox, installé bien plus tard), mais les coupures sèches restent inexpliquées. Les hypothèses ouvertes, par ordre de vraisemblance sur une machine de cet âge :
- Alimentation vieillissante — condensateurs fatigués, tension instable sous charge. C'est l'hypothèse n°1 pour des coupures nettes sans trace, et c'est le composant le plus âgé et le plus sollicité de la machine.
- Thermique — pâte thermique sèche après 6-7 ans, ventilateur de CPU encrassé, coupure de protection.
- SSD système — un Patriot Burst d'entrée de gamme en fin de vie peut provoquer des gels totaux au démarrage. État actuellement inconnu, faute de données SMART.
- Connectique / oxydation — barrette mémoire, connecteurs d'alimentation, câbles SATA. Neuf ans de poussière.
- Mémoire — moins probable (aucune erreur WHEA, signature
0x50non aléatoire), mais non écartée tant qu'un test complet n'a pas été passé.
10. Actions recommandées, par ordre de priorité
Priorité 1 — sans risque, à faire tout de suite
| # | Action | Objectif |
|---|---|---|
| 1 | Désactiver le filtre réseau VirtualBox : décocher « VirtualBox NDIS6 Bridged Networking Driver » dans les propriétés de la carte réseau. Si VirtualBox n'est pas utilisé au quotidien, le désinstaller purement et simplement. | Traite le suspect n°1 de la vague en cours |
| 2 | Désactiver le démarrage rapide : Panneau de configuration → Options d'alimentation → « Choisir l'action des boutons » → décocher « Activer le démarrage rapide ». | Supprime la cause n°1 des 0x9F et évite de réinjecter un état de pilote corrompu à chaque démarrage |
| 3 | Activer les mini-vidages mémoire en complément du vidage noyau (MinidumpsCount → 50). |
Aujourd'hui seul MEMORY.DMP est écrit et il est écrasé à chaque crash : l'historique des dumps est perdu. Sans mini-vidages, chaque nouveau crash détruit la preuve du précédent. |
| 4 | Désactiver aussi le dossier C:\Program Files\RustDesk\drivers, resté actif. |
Écarter définitivement la piste RustDesk |
Priorité 2 — nécessite une installation ou un redémarrage
| # | Action | Objectif |
|---|---|---|
| 5 | Installer smartmontools (winget install smartmontools) et relever le SMART complet du SSD Patriot Burst et du HDD Toshiba : heures de fonctionnement, usure, secteurs réalloués, erreurs CRC. |
Comble la principale lacune du diagnostic. Windows n'expose rien ; c'est la seule façon de savoir si le SSD système est en fin de vie. |
| 6 | Installer WinDbg (winget install Microsoft.WinDbg) et analyser C:\Windows\MEMORY.DMP (2,4 Go, crash du 03/08 07:43) avec !analyze -v. |
Passe de « suspect fortement corrélé » à « coupable nommé » : le dump contient le nom exact du module fautif. C'est l'étape qui authentifie formellement la cause. |
| 7 | 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. |
| 8 | 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
| # | Action | Objectif |
|---|---|---|
| 9 | Relever les références de l'alimentation (marque, modèle, wattage, année). | Information manquante et déterminante |
| 10 | Dépoussiérer : ventilateur et radiateur CPU, ventilateurs de boîtier, filtres, bloc d'alimentation. | Cause thermique |
| 11 | 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 |
| 12 | Refaire la pâte thermique du processeur si elle n'a pas été changée depuis l'assemblage. | Cause thermique |
| 13 | 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 |
| 14 | 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 |
11. Limites de cette analyse
À mentionner pour que les conclusions soient lues à leur juste valeur :
- L'historique ne remonte qu'au 29/10/2025 (réinstallation de Windows la veille). Les 9 années d'usage antérieures sont invisibles. On ne sait pas si le problème est ancien ou récent.
- Le vidage mémoire du 03/08 n'a pas été analysé : WinDbg n'est pas installé sur la machine.
VBoxNetLwfreste donc un suspect corrélé, pas un coupable prouvé. - Le dossier
C:\Windows\Minidumpet les rapports WER sont inaccessibles sans élévation de privilèges. Deux rapportsKernel_50du 31/07 n'ont pas pu être lus. - Aucune donnée SMART réelle n'a pu être obtenue (voir §7).
- Aucune donnée de température ni de tension n'est disponible sans capteur logiciel dédié.
- La corrélation
VBoxNetLwf↔0x50est temporellement très forte, mais l'erreurVBoxNetLwfse produit à chaque transition (20 fois) alors que seuls 3 crashes en ont résulté. Le pilote est donc un facteur nécessaire mais pas suffisant : il faut probablement un déclencheur supplémentaire (charge, séquence, état) pour que l'erreur dégénère en écran bleu.
12. Journal des relevés
À compléter à chaque passage. Un relevé toutes les 1 à 2 semaines devrait suffire à mesurer l'effet des actions engagées.
| Date du relevé | Arrêts anormaux depuis le dernier relevé | dont BSOD | Codes rencontrés | Erreurs VBoxNetLwf |
WHEA | Actions faites depuis | Observations |
|---|---|---|---|---|---|---|---|
| 2026-08-03 | 45 (cumul 9 mois) | 15 | 10×9F, 3×50, 1×3B, 1×A0 |
20 | 0 | — (état initial) | Analyse initiale. Deux populations distinctes identifiées. |
13. Indicateur de succès
Le suivi doit permettre de trancher entre les deux problèmes :
- Si les BSOD cessent après les actions de priorité 1 mais que les coupures sèches continuent → le problème logiciel est réglé, le problème matériel est confirmé et isolé. On passe à la priorité 3.
- Si tout cesse → la cause était entièrement logicielle. L'hypothèse du composant défectueux tombe.
- Si les BSOD persistent → il faut le dump analysé sous WinDbg (action 6) pour nommer le module fautif.
Page tenue à jour par Claude Code. Analyse initiale du 2026-08-03.