Écran bleu (BSOD) sous Windows 11 : le guide de dépannage helpdesk 2026

Mis à jour : 4 septembre 2026

Un écran bleu (BSOD, désormais officiellement Black Screen of Death depuis la mise à jour Windows 11 24H2 de juillet 2024) sous Windows 11 est presque toujours causé par un pilote noyau, un module matériel défectueux ou une corruption mémoire, et non par une application. Pour dépanner efficacement, on ne redémarre pas trois fois en espérant que ça passe. On récupère le fichier MEMORY.DMP ou le minidump dans C:\Windows\Minidump, on l'ouvre avec WinDbg, on lit le bug check code, puis on remonte au pilote fautif. Ce guide décrit le workflow que j'utilise quand un ticket P2 tombe le lundi matin.

• Depuis Windows 11 24H2, l'écran est noir mais le mécanisme, les codes et les dumps sont identiques à ceux du BSOD classique.
• Le fichier de vidage utile pour un helpdesk est le Small Memory Dump (256 Ko) dans C:\Windows\Minidump\*.dmp, généré à chaque crash.
• WinDbg Preview (gratuit, Microsoft Store) analyse un minidump en 30 secondes avec la commande !analyze -v. Pas besoin de licence ni de compétences kernel-mode profondes.
• 80 % des BSOD que je vois en tier 1 viennent de trois causes : pilote graphique, pilote réseau (Wi-Fi/VPN client) ou barrette RAM défectueuse. Testez dans cet ordre.
• Driver Verifier isole un pilote suspect en forçant un crash contrôlé. À utiliser sur un poste de test, jamais sur celui d'un cadre en réunion.
• Les bug checks matériels (WHEA_UNCORRECTABLE_ERROR, MEMORY_MANAGEMENT récurrent) doivent basculer le ticket vers le remplacement matériel. N'y passez pas huit heures logicielles.

BSOD, black screen : ce qui a changé en 24H2

Depuis la mise à jour Windows 11 24H2 (déployée en canal général à partir de novembre 2024), Microsoft a remplacé le bleu historique par un écran noir intitulé « Votre appareil a rencontré un problème et doit redémarrer ». Le smiley triste et le QR code ont disparu. Le code d'arrêt (stop code) reste affiché en bas de l'écran, sous une nouvelle mention « What failed: » qui pointe le module suspect quand le noyau a pu l'identifier. C'est cosmétique, le mécanisme technique n'a pas bougé.

Concrètement pour un helpdesk : le vocabulaire des utilisateurs a explosé (« écran noir de la mort », « écran de crash », « le petit écran avec Redémarrage… »), les captures qu'ils envoient sont plus difficiles à lire (le contraste noir/blanc est violent en photo), et certains techniciens juniors pensent à tort à un problème d'affichage. Formez votre tier 1 à reconnaître les deux cas : la présence du texte « stop code » ou « What failed: » identifie sans ambiguïté un bug check noyau, indépendamment de la couleur du fond.

Le fichier de vidage, lui, est produit exactement comme avant. Windows 11 génère par défaut un Automatic Memory Dump écrit dans C:\Windows\MEMORY.DMP plus un Small Memory Dump horodaté dans C:\Windows\Minidump\. Le minidump fait 256 Ko à 1 Mo, il tient en pièce jointe d'un ticket, et il contient tout ce dont WinDbg a besoin pour identifier le pilote fautif dans 90 % des cas.

Collecter les preuves avant de toucher au poste

La première erreur du tier 1 débutant, c'est de lancer sfc /scannow et de redémarrer. Ça détruit potentiellement les indices. Avant toute action, collectez ces cinq éléments dans le ticket, même si l'utilisateur vous met la pression :

1. Le stop code affiché à l'écran (photo lisible, ou dictée par téléphone). Exemples : DPC_WATCHDOG_VIOLATION, SYSTEM_SERVICE_EXCEPTION, KMODE_EXCEPTION_NOT_HANDLED.
2. Le module fautif quand la ligne « What failed: » est présente (ex. nvlddmkm.sys, netwtw10.sys).
3. Le contexte d'occurrence : au démarrage, en veille, sous charge GPU, à la connexion VPN, à l'impression, aléatoire ?
4. Les modifications récentes : dernière mise à jour cumulative, pilote installé, mise à niveau de firmware, changement de station d'accueil.
5. Le ou les minidumps depuis C:\Windows\Minidump\, zippés et attachés au ticket.

Vérifiez aussi que Windows est configuré pour écrire ces dumps. Sur un poste géré par Intune, la stratégie par défaut est correcte, mais je vois régulièrement des images OEM (Dell, HP, Lenovo Vantage) qui désactivent l'écriture pour libérer de l'espace disque. La configuration se lit dans HKLM\SYSTEM\CurrentControlSet\Control\CrashControl, valeur CrashDumpEnabled : elle doit valoir 7 (Automatic) ou 3 (Kernel). Une valeur à 0 signifie qu'aucun dump ne sera généré, et il faut la corriger avant d'espérer un diagnostic sérieux.

# PowerShell (élévation requise), vérifier et corriger la configuration de dump
$key = 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'
Get-ItemProperty $key |
    Select-Object CrashDumpEnabled, MinidumpDir, DumpFile, AutoReboot

# Forcer Automatic Memory Dump + conserver l'ancien minidump lors du prochain crash
Set-ItemProperty $key -Name CrashDumpEnabled -Value 7
Set-ItemProperty $key -Name MinidumpDir      -Value '%SystemRoot%\Minidump'
Set-ItemProperty $key -Name DumpFile         -Value '%SystemRoot%\MEMORY.DMP'
Set-ItemProperty $key -Name AutoReboot       -Value 1   # 0 si vous voulez lire le code à l'écran

Récupérez ensuite la liste des minidumps existants et copiez-la sur votre partage helpdesk. Sur un poste distant en télétravail, un simple script PowerShell zip + upload OneDrive fait le travail :

# Collecte automatisée des minidumps (à exécuter en tant qu'admin sur le poste utilisateur)
$dest = "$env:USERPROFILE\OneDrive - Contoso\HelpdeskUploads"
New-Item -ItemType Directory -Force -Path $dest | Out-Null

$zip = Join-Path $dest "$env:COMPUTERNAME-minidumps-$(Get-Date -Format 'yyyyMMdd-HHmm').zip"
Compress-Archive -Path 'C:\Windows\Minidump\*.dmp' -DestinationPath $zip -CompressionLevel Optimal
Write-Host "Uploaded: $zip"

Analyser un minidump avec WinDbg en cinq minutes

Bon, une fois le minidump récupéré, ouvrez-le sur votre poste helpdesk avec WinDbg (installez la version moderne, ex-« WinDbg Preview », depuis le Microsoft Store, c'est gratuit et l'outil recommandé par Microsoft pour l'analyse post-mortem, cf. la documentation Windows Debugger de Microsoft Learn). Configurez une seule fois le chemin de symboles :

File → Settings → Debugging settings → Symbol path :

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

Ce chemin dit à WinDbg de télécharger à la demande les symboles Microsoft depuis le serveur public et de les cacher localement. La première analyse peut prendre 2-3 minutes de téléchargement ; les suivantes sont instantanées.

Ouvrez le minidump (File → Open dump file). Dans la fenêtre Command, tapez la commande la plus rentable de tout WinDbg :

!analyze -v

Cette commande demande à WinDbg d'exécuter une analyse verbeuse. En 20 à 40 secondes vous obtenez un rapport structuré. Les six lignes utiles sont :

• BUGCHECK_CODE : le code hexadécimal (ex. 0x0000007E).
• BUGCHECK_STR : le libellé lisible (ex. SYSTEM_THREAD_EXCEPTION_NOT_HANDLED).
• MODULE_NAME et IMAGE_NAME : le module noyau incriminé (ex. igdkmd64.sys = pilote Intel Graphics).
• FAILURE_BUCKET_ID : la signature du crash, utile pour dédupliquer plusieurs incidents.
• STACK_TEXT : la pile d'appels au moment du crash, à lire de bas en haut.
• PROCESS_NAME : le processus utilisateur actif (souvent System pour un crash noyau, mais parfois chrome.exe ou outlook.exe).

Le nom du fichier .sys se traduit en pilote installé via un simple recoupement. Si vous n'êtes pas sûr, faites lm vm nomdupilote (lister le module) pour voir la version, la date et l'éditeur signés dans le binaire. Pour la table complète des codes d'arrêt, la Bug Check Code Reference de Microsoft Learn est la référence officielle et à jour.

Bug checks courants et leur traduction terrain

Honnêtement, sur les six dernières années à Klarna et IKEA, j'ai vu revenir toujours les mêmes codes. Voici la traduction directe entre bug check et action helpdesk, sans passer par le pré-diagnostic générique du support Microsoft.

Bug check	Cause typique	Première action	Bascule L2/matériel si…
DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)	Pilote noyau qui accède à une adresse invalide, souvent réseau, USB ou stockage.	Identifier le .sys, rollback du pilote via Device Manager.	Le crash persiste après réinstallation propre du pilote.
SYSTEM_SERVICE_EXCEPTION (0x3B)	Souvent pilote graphique ou anti-virus tiers.	Mettre à jour le pilote GPU depuis le site du fabricant, désactiver temporairement l'AV tiers.	Crash reproductible sans AV et avec pilote Microsoft générique.
MEMORY_MANAGEMENT (0x1A)	Corruption RAM, VRAM ou table de pages.	Lancer Windows Memory Diagnostic + MemTest86 sur une nuit.	Erreurs détectées dans MemTest → remplacement barrette.
DPC_WATCHDOG_VIOLATION (0x133)	Un pilote monopolise le CPU trop longtemps, souvent SSD NVMe ou pilote firmware.	Mettre à jour firmware SSD et pilote NVMe.	Persiste après firmware à jour → remplacement SSD.
KMODE_EXCEPTION_NOT_HANDLED (0x1E)	Pilote tiers non conforme (VPN, chiffrement, imprimante).	Désinstaller le dernier logiciel installé, vérifier compatibilité 11 24H2.	Sans logiciel tiers récent : suspecter le matériel.
WHEA_UNCORRECTABLE_ERROR (0x124)	Erreur matérielle non récupérable rapportée par le CPU (Windows Hardware Error Architecture).	Vérifier température, ventilateurs, alimentation, mises à jour BIOS/UEFI.	Récurrent hors surchauffe → CPU, carte mère ou alimentation.
CRITICAL_PROCESS_DIED (0xEF)	Un processus critique (souvent csrss.exe, wininit.exe) est tué.	Lancer sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth.	SFC+DISM propres et crash persistant → réimage.

Cette table couvre environ 85 % des tickets BSOD que j'ai traités sur les 18 derniers mois. Les 15 % restants sont des cas très spécifiques (Hyper-V, virtualisation imbriquée, Secure Kernel Mode) qui méritent leur propre run book, et qu'il ne faut pas laisser un tier 1 débutant creuser plus de 30 minutes avant escalade.

Isoler un pilote fautif avec Driver Verifier

Quand !analyze -v pointe un module Microsoft générique (ntoskrnl.exe, ntfs.sys, tcpip.sys), le vrai coupable est presque toujours un pilote tiers qui a corrompu la mémoire avant que le noyau ne s'en aperçoive. Pour l'isoler, on utilise Driver Verifier, un outil intégré à Windows qui vérifie chaque appel de pilote et force un BSOD contrôlé au premier écart. C'est brutal mais imparable.

Sur un poste de test (jamais sur celui d'un utilisateur en production), lancez verifier depuis un cmd élévé. Choisissez « Créer des paramètres personnalisés (pour codes) », cochez tous les tests standards sauf « Simulation de manque de ressources » (qui produit trop de faux positifs), puis « Sélectionner un pilote dans une liste » et cochez uniquement les pilotes non signés Microsoft. Redémarrez.

# Alternative en ligne de commande, activer Driver Verifier sur tous les pilotes tiers
verifier /standard /all
shutdown /r /t 0

# En cas de boot loop, désactiver en mode sans échec
verifier /reset

Laissez tourner le poste 24 à 48 heures avec l'usage normal reproductible. Au premier crash, le nouveau minidump identifiera précisément le pilote fautif. Désactivez ensuite Verifier avec verifier /reset. C'est la méthode canonique décrite dans la documentation Driver Verifier de Microsoft, et elle m'a fait gagner des dizaines d'heures d'errance sur des pilotes de VPN client mal signés (souvenir douloureux d'un vendredi soir chez un client, il y a deux ans).

Quand basculer sur un diagnostic matériel

Un ticket BSOD peut aspirer trois techniciens pendant deux jours si personne ne dit stop. Voici mes règles d'escalade matérielle, calibrées pour un helpdesk d'entreprise avec accès à un stock de spares :

• MemTest86 remonte la moindre erreur après un passage complet (comptez 45 min à 6 h selon la RAM installée) → remplacement barrette, pas de discussion. Les erreurs RAM ne se « soignent » pas logiciellement.
• WHEA_UNCORRECTABLE_ERROR revient sans surchauffe après mise à jour BIOS/UEFI complète → escalade vers L2 pour arbitrage remplacement carte mère ou CPU.
• SMART du disque signale des secteurs réalloués ou des erreurs non corrigées (Get-PhysicalDisk | Get-StorageReliabilityCounter) → remplacement immédiat, plus sauvegarde préventive dans l'heure.
• Le poste crash uniquement sur station d'accueil (WD19, HP Thunderbolt Dock, etc.) → tester avec un autre dock avant de blâmer le poste ; ces docks sont eux-mêmes une source de DPC_WATCHDOG_VIOLATION connue.
• Plusieurs bug checks matériels différents en quelques jours sur le même poste (MEMORY_MANAGEMENT, puis WHEA, puis 0x124) → symptôme classique d'alimentation défaillante, à ne pas confondre avec un problème logiciel.

Pour la RAM, MemTest86 (le vrai, de PassMark) reste la référence en 2026 : bootable depuis clé USB, indépendant de Windows, et détecte des défauts que le diagnostic mémoire Windows manque. Pour le SSD, le chkdsk /f /r classique reste utile mais il ne remplace pas la lecture SMART, qui identifie un disque mourant avant qu'il ne fasse tomber le système. Sur un parc où le stockage est particulièrement chargé, je jette aussi un œil aux journaux via le guide de dépannage Windows Update bloqué, car un dump interrompu par un update coincé fausse parfois le diagnostic initial. Autre piste liée : quand un poste BSODe puis refuse la reprise en RDP, jetez un œil au guide RDP ne se connecte pas sous Windows 11, qui recouvre les problèmes de session hérités post-crash.

Checklist tier 1 : dix minutes chrono

Voici la checklist plastifiée que je colle sur les postes de mes T1. Objectif : dix minutes pour résoudre 40 % des BSOD sans escalade, et surtout ne rien casser sur les 60 % restants.

1. 0-2 min : Collecter le stop code, la fréquence et le contexte d'occurrence. Ne redémarrer que si l'utilisateur en a besoin pour continuer à travailler.
2. 2-4 min : Copier C:\Windows\Minidump\*.dmp vers le partage helpdesk. Consigner la référence du ticket dans le nom du zip.
3. 4-6 min : Ouvrir Reliability Monitor (perfmon /rel). L'historique des BSOD et des installations récentes tient sur un écran. Cherchez une corrélation « installation X → premier crash le lendemain ».
4. 6-8 min : Consulter l'observateur d'événements, journal Système, filtre sur les événements critiques (BugCheck ID 1001). Notez le code et l'horodatage pour recouper.
5. 8-10 min : Lancer WinDbg sur le dump avec !analyze -v. Reporter BUGCHECK_STR, MODULE_NAME et FAILURE_BUCKET_ID dans le ticket.
6. Décision : bug check listé dans le tableau de la section précédente → appliquer l'action de première ligne. Sinon → escalade L2 avec le rapport !analyze -v complet en pièce jointe.

Le point-clé, c'est de ne jamais refermer un ticket BSOD sur « crash disparu après redémarrage ». Les bug checks sont probabilistes. Ils peuvent ne pas se reproduire pendant trois semaines puis revenir un lundi matin. Sans identification du pilote ou du composant fautif, on ne peut pas parler de résolution, juste de latence. Marquez ces tickets comme « surveillé 30 jours » et laissez un script planifié vérifier chaque nuit l'apparition d'un nouveau minidump.

Questions fréquentes

Pourquoi mon PC affiche un écran bleu (ou noir) sous Windows 11 ?

Un écran bleu ou noir sous Windows 11 est déclenché par le noyau (kernel) quand une erreur fatale l'empêche de continuer sans risque de corruption des données. La cause est presque toujours un pilote tiers (graphique, réseau, VPN, chiffrement) ou un défaut matériel (RAM, SSD, alimentation). Le stop code affiché à l'écran, et le minidump généré dans C:\Windows\Minidump\, permettent d'identifier précisément la cause.

Où sont stockés les fichiers de vidage minidump sur Windows 11 ?

Par défaut dans C:\Windows\Minidump\ (petits vidages de 256 Ko à 1 Mo, un fichier .dmp par crash) et C:\Windows\MEMORY.DMP pour le vidage automatique complet (jusqu'à la taille de la RAM). Ces emplacements sont configurables dans le registre sous HKLM\SYSTEM\CurrentControlSet\Control\CrashControl.

Quel outil utiliser pour analyser un fichier dump Windows 11 ?

WinDbg (anciennement WinDbg Preview), disponible gratuitement sur le Microsoft Store, est l'outil recommandé par Microsoft. Configurez le chemin de symboles vers srv*C:\Symbols*https://msdl.microsoft.com/download/symbols, ouvrez le minidump et tapez !analyze -v. Le rapport identifie le bug check et le module fautif en moins d'une minute.

Comment corriger l'erreur DRIVER_IRQL_NOT_LESS_OR_EQUAL ?

Ouvrez le minidump avec WinDbg pour identifier le fichier .sys incriminé, puis mettez à jour ou rollback le pilote correspondant depuis le Gestionnaire de périphériques. Dans 70 % des cas c'est un pilote réseau (Wi-Fi Intel, VPN client), USB ou stockage. Si le crash persiste avec un pilote propre, activez Driver Verifier pour isoler le vrai coupable.

Comment activer Driver Verifier sur Windows 11 sans risquer un boot loop ?

N'activez Driver Verifier que sur un poste de test avec accès physique, mot de passe admin local disponible et un plan de récupération (média Windows PE prêt). Lancez verifier en cmd élévé, cochez tous les tests standards sauf « Simulation de manque de ressources », sélectionnez uniquement les pilotes non-Microsoft, puis redémarrez. En cas de boot loop, démarrez en mode sans échec et exécutez verifier /reset.

Un BSOD peut-il être causé par un problème matériel plutôt que logiciel ?

Oui, environ 20 à 25 % des BSOD que je vois en helpdesk sont d'origine matérielle : barrette RAM défectueuse (MEMORY_MANAGEMENT récurrent), SSD mourant (DPC_WATCHDOG_VIOLATION, secteurs SMART réalloués), alimentation instable (WHEA_UNCORRECTABLE_ERROR sans surchauffe), ou station d'accueil défaillante. MemTest86 pour la RAM et la lecture SMART pour le stockage sont vos deux outils de diagnostic prioritaires.