Windows 11 : analyser un écran bleu via les minidumps

Pourquoi analyser un écran bleu (BSOD) avec les minidumps sous Windows 11 ?

Un écran bleu (BSOD) sous Windows 11 n'arrive jamais "par hasard" : il est déclenché par un bugcheck (un arrêt critique du noyau) généralement causé par un pilote, un composant matériel ou, plus rarement, un souci système (corruption, mise à jour, antivirus, etc.). Le problème, c'est que le message affiché à l'écran est souvent trop vague.

La bonne nouvelle : Windows 11 peut enregistrer un minidump (un petit fichier de diagnostic) au moment du crash. En l'analysant, tu peux souvent remonter à :

• un pilote précis (ex. pilote Wi‑Fi, GPU, stockage, USB) ;
• un module système impliqué (ex. ntoskrnl.exe apparaît souvent, mais n'est pas forcément le coupable) ;
• un code d'erreur (BugCheck) qui oriente vers une cause (mémoire, accès disque, corruption, etc.).

Prérequis : vérifier que Windows 11 génère bien des minidumps

Avant d'analyser quoi que ce soit, assure-toi que Windows est configuré pour créer ces fichiers.

Étapes pour activer les minidumps

1. Ouvre le menu Démarrer et cherche Paramètres système avancés (ou passe par : Paramètres > Système > Informations système > Paramètres avancés du système).
2. Dans l'onglet Paramètres système avancés, section Démarrage et récupération, clique sur Paramètres.
3. Dans Écriture des informations de débogage, sélectionne Image mémoire partielle (minidump).
4. Vérifie le chemin : %SystemRoot%\Minidump (généralement C:\Windows\Minidump).
5. Coche Redémarrer automatiquement si tu veux que le PC redémarre tout seul après un BSOD (optionnel).

Astuce : si le dossier C:\Windows\Minidump n'existe pas, ce n'est pas forcément grave : il peut être créé au premier crash, ou la génération de dump peut être désactivée.

Où trouver les minidumps et comment les récupérer

Les minidumps se trouvent presque toujours ici :

• C:\Windows\Minidump

Chaque fichier porte un nom du type 031424-12345-01.dmp (date + identifiant). Pour les analyser proprement :

• copie les fichiers .dmp sur ton Bureau (les outils peuvent avoir besoin de droits admin) ;
• si l'accès est refusé, lance l'Explorateur ou l'outil d'analyse en administrateur.

Méthode simple : analyser un minidump avec BlueScreenView

Pour une première lecture rapide, BlueScreenView (NirSoft) est pratique : il liste les dumps et met en évidence les pilotes impliqués. Ce n'est pas aussi fiable qu'un débogage complet, mais c'est excellent pour dégrossir.

Étapes

1. Télécharge et lance BlueScreenView.
2. Il détecte automatiquement C:\Windows\Minidump. Sinon, indique le dossier manuellement.
3. Dans la liste, clique sur le dump correspondant au dernier crash (date/heure).
4. Regarde les colonnes importantes :
   • Bug Check String (nom lisible de l'erreur)
   • Bug Check Code (code hexadécimal)
   • Caused By Driver (pilote suspect)
   • Caused By Address (adresse mémoire, utile pour corréler)

Comment interpréter les résultats (sans se faire piéger)

Quelques règles simples :

• Si ntoskrnl.exe, hal.dll ou win32kfull.sys ressort comme "cause", ce n'est pas une preuve : ce sont des composants centraux qui "encaissent" le crash. Il faut chercher le pilote tiers autour (réseau, GPU, stockage...).
• Si un pilote tiers revient souvent (ex. nvlddmkm.sys pour NVIDIA, amdkmdag.sys pour AMD, rtwlane.sys / netwtw pour Wi‑Fi Intel/Realtek), c'est un indice fort.
• Si tu vois des bugchecks liés à la mémoire (ex. MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL), le pilote peut être en cause... mais la RAM aussi.

Méthode plus fiable : WinDbg (Microsoft) pour une analyse approfondie

Si tu veux une analyse plus "pro", utilise WinDbg (Windows Debugger). C'est l'outil Microsoft qui permet d'interpréter correctement la pile d'appels et d'identifier le module fautif avec plus de contexte.

Installer WinDbg (Preview) depuis le Microsoft Store

1. Ouvre le Microsoft Store.
2. Cherche WinDbg Preview.
3. Installe puis lance l'application.

Configurer les symboles (indispensable)

Sans symboles, l'analyse est souvent incomplète. Configure le serveur de symboles Microsoft :

1. Dans WinDbg : menu File > Settings (ou via la commande).
2. Définis le chemin des symboles comme ceci :

SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols

Conseil : crée le dossier C:\Symbols pour mettre en cache les symboles et accélérer les analyses suivantes.

Ouvrir un minidump et lancer l'analyse

1. Menu File > Open dump file.
2. Sélectionne un fichier .dmp (copié sur le Bureau si possible).
3. Dans la console, exécute :

!analyze -v

Ce que tu dois regarder dans le rapport WinDbg

• BUGCHECK_CODE : le type d'arrêt (ex. 0xA, 0x1E, 0x3B, 0x7E...).
• MODULE_NAME et IMAGE_NAME : le pilote/module pointé.
• Probably caused by : indication utile, à confirmer avec le contexte.
• STACK_TEXT : la pile d'appels. Si tu vois un pilote tiers revenir dans la pile juste avant le crash, c'est souvent le bon suspect.

Identifier le pilote fautif et passer à l'action

Une fois le pilote suspect identifié, l'objectif est de confirmer puis corriger.

1) Vérifier à quoi correspond le fichier .sys

• Note le nom (ex. xxxx.sys).
• Va dans C:\Windows\System32\drivers et cherche le fichier.
• Clic droit > Propriétés > onglet Détails : tu verras parfois l'éditeur (Intel, Realtek, NVIDIA...).

2) Mettre à jour (ou revenir en arrière) proprement

• GPU : réinstalle le pilote (idéalement "propre"). En cas de crash après mise à jour, teste un rollback vers une version stable.
• Wi‑Fi / Ethernet : privilégie le pilote du constructeur (Intel/Realtek/Qualcomm) ou celui du fabricant du PC (Dell/HP/Lenovo/ASUS).
• Stockage (NVMe/SATA/RAID) : prudence, un mauvais pilote peut rendre le système instable. Mets à jour via le site constructeur ou Windows Update si tu veux limiter les risques.

Conseil pratique : si le BSOD survient juste après une mise à jour, tente d'abord un retour arrière du pilote (Gestionnaire de périphériques > Propriétés du périphérique > Pilote > Restaurer le pilote).

3) Désinstaller les logiciels "à risque" (temporairement)

Certains BSOD sont causés par des couches basses :

• antivirus tiers / suites de sécurité ;
• outils d'overclocking / monitoring agressif ;
• logiciels de virtualisation ou drivers réseau spécifiques (VPN, filtrage, pare-feu tiers).

Pour tester, désinstalle temporairement (pas juste désactiver) et observe si les crashes cessent.

Comprendre quelques BugCheck courants (repères rapides)

• IRQL_NOT_LESS_OR_EQUAL : souvent pilote défectueux, parfois RAM.
• PAGE_FAULT_IN_NONPAGED_AREA : pilote, RAM, ou corruption mémoire.
• SYSTEM_SERVICE_EXCEPTION : pilote graphique ou composant système appelé via un driver.
• DPC_WATCHDOG_VIOLATION : stockage (NVMe/SATA), drivers chipset, parfois firmware/BIOS.
• WHEA_UNCORRECTABLE_ERROR : plutôt matériel (CPU, RAM, PCIe, alimentation), mais peut être déclenché par microcode/BIOS.

Si les minidumps ne suffisent pas : pistes de diagnostic complémentaires

Parfois, le minidump ne contient pas assez d'infos (crash trop tôt, corruption, etc.). Dans ce cas :

• Vérifie l'Observateur d'événements (Journaux Windows > Système) autour de l'heure du crash.
• Teste la RAM (Windows Memory Diagnostic ou, mieux, MemTest86 sur clé USB).
• Contrôle l'état disque (SMART) et exécute chkdsk si nécessaire.
• Mets à jour le BIOS/UEFI et les drivers chipset (surtout sur PC récents).

Bonnes pratiques pour éviter les BSOD à répétition

• Évite d'empiler plusieurs outils qui installent des drivers bas niveau (VPN + antivirus + "tuning" + OC).
• Privilégie des pilotes stables plutôt que "la dernière version" si ton PC est critique.
• Après une mise à jour majeure, garde un point de restauration et surveille les premiers jours.
• Si tu fais de l'overclocking, reviens aux valeurs stock pour valider la stabilité.

Conclusion

Pour Windows 11 : analyser un écran bleu via les minidumps est l'une des méthodes les plus efficaces pour arrêter de "deviner" et commencer à diagnostiquer. Avec BlueScreenView, tu obtiens rapidement un suspect. Avec WinDbg et !analyze -v, tu peux confirmer plus solidement le pilote ou le composant impliqué, puis appliquer la correction (mise à jour, rollback, désinstallation, test matériel).

Si tu veux, donne-moi le BugCheck et le nom du .sys trouvé dans ton minidump (ou une capture WinDbg/BlueScreenView) et je t'aide à interpréter le résultat et à choisir la meilleure action.