il y a 1 an

BSOD : comprendre les Stop Codes et analyser les crash dumps

L’écran bleu de la mort, ou BSOD pour Blue Screen of Death, fait partie du folklore Windows depuis suffisamment longtemps pour avoir traumatisé plusieurs générations d’utilisateurs, de techniciens et de présentations PowerPoint.

Mais derrière son apparence dramatique se trouve un mécanisme parfaitement rationnel : Windows a détecté une situation suffisamment grave dans le noyau pour considérer que continuer l’exécution serait plus dangereux que tout arrêter.

Sur les versions récentes de Windows 11, l’écran de Stop error peut d’ailleurs apparaître sur fond noir plutôt que bleu. Le nom BSOD survit néanmoins, parce que renommer plusieurs décennies de traumatisme collectif aurait probablement demandé trop de réunions.

Un BSOD n’est pas le problème lui-même. C’est le moment où Windows constate qu’un problème a rendu la poursuite de l’exécution impossible ou dangereuse.

Qu’est-ce qu’un BSOD exactement ?

Dans la terminologie Microsoft, on parle notamment de :

Bug Check
Stop Error
Stop Code
Kernel Error

Lorsqu’une condition critique est détectée en mode noyau, Windows déclenche un arrêt contrôlé du système, collecte si possible des informations de diagnostic, écrit éventuellement un dump mémoire puis redémarre.

Un bug check peut être provoqué par :

un pilote noyau défectueux ;
une corruption mémoire ;
un composant matériel instable ;
un problème de stockage ;
un firmware ou BIOS problématique ;
un logiciel utilisant des composants noyau ;
une corruption du système ;
plus rarement, un logiciel malveillant opérant à bas niveau.

Le BSOD protège surtout l’intégrité logique du système. Continuer à exécuter un noyau dont la mémoire a été corrompue pourrait écrire des données incorrectes sur disque, aggraver une corruption ou provoquer des résultats totalement imprévisibles.

Le Stop Code : un indice, pas une condamnation

L’écran affiche généralement un nom symbolique comme :

IRQL_NOT_LESS_OR_EQUAL

PAGE_FAULT_IN_NONPAGED_AREA

MEMORY_MANAGEMENT

CRITICAL_PROCESS_DIED

Chaque nom correspond à un code numérique de bug check et plusieurs paramètres techniques.

Le piège consiste à lire :

MEMORY_MANAGEMENT

puis à conclure immédiatement :

« La RAM est morte. »

Ce n’est pas ainsi que fonctionne le diagnostic. Une erreur de gestion mémoire peut être la conséquence d’une barrette défectueuse, mais également d’un pilote écrivant au mauvais endroit, d’un overclocking instable ou d’une corruption survenue plusieurs millisecondes avant le crash.

Quelques Stop Codes courants

Stop Code	Signification générale	Pistes fréquentes
`IRQL_NOT_LESS_OR_EQUAL`	Accès mémoire invalide à un niveau IRQL élevé	Pilote noyau, pointeur incorrect, corruption mémoire
`PAGE_FAULT_IN_NONPAGED_AREA`	Référence invalide à de la mémoire système attendue disponible	Pilote, RAM, stockage, corruption mémoire
`BAD_POOL_HEADER`	Corruption des structures du pool mémoire noyau	Pilote, corruption mémoire
`KMODE_EXCEPTION_NOT_HANDLED`	Exception en mode noyau non prise en charge	Pilote, service noyau, firmware, matériel
`CRITICAL_PROCESS_DIED`	Un processus ou thread critique de Windows s’est terminé	Corruption système, pilote, stockage, logiciel bas niveau
`MEMORY_MANAGEMENT`	Erreur grave du gestionnaire mémoire	RAM, pilote, instabilité CPU/RAM, corruption mémoire
`WHEA_UNCORRECTABLE_ERROR`	Erreur matérielle signalée via l’architecture WHEA	CPU, RAM, PCIe, alimentation, overclocking, carte mère
`DPC_WATCHDOG_VIOLATION`	Une opération noyau a dépassé certaines limites temporelles	Pilote, stockage, firmware, périphérique

IRQL_NOT_LESS_OR_EQUAL n’est pas simplement « accès mémoire illégal »

Le code :

IRQL_NOT_LESS_OR_EQUAL
0x0000000A

est plus précis que cela.

Il indique typiquement que Windows ou un pilote noyau a tenté d’accéder à une adresse mémoire invalide ou paginable alors que le processeur se trouvait à un niveau d’interruption où cette opération n’était pas permise.

Les coupables typiques sont donc des :

pilotes incorrects ;
pointeurs invalides ;
use-after-free ;
corruptions mémoire ;
problèmes de code noyau.

PAGE_FAULT_IN_NONPAGED_AREA

Le code :

PAGE_FAULT_IN_NONPAGED_AREA
0x00000050

indique qu’une adresse mémoire système invalide a été référencée.

Les causes peuvent inclure :

un pilote défectueux ;
de la RAM instable ;
une corruption mémoire ;
un problème NTFS ;
un composant matériel défaillant.

Encore une fois :

PAGE_FAULT
≠
RAM automatiquement morte

BAD_POOL_HEADER

Le :

BAD_POOL_HEADER
0x00000019

signale une corruption d’une structure du pool mémoire utilisé par le noyau.

Un pilote ayant écrit :

trop loin
au mauvais endroit
après avoir libéré la mémoire

peut par exemple corrompre une structure qui ne sera détectée que plus tard.

C’est précisément ce qui rend certains BSOD difficiles : le composant qui découvre la catastrophe n’est pas nécessairement celui qui l’a provoquée.

CRITICAL_PROCESS_DIED

Le :

CRITICAL_PROCESS_DIED
0x000000EF

signifie qu’un processus ou thread considéré comme critique pour Windows s’est terminé ou a été suffisamment corrompu pour compromettre l’intégrité du système.

Des composants comme :

csrss.exe
wininit.exe
services.exe
winlogon.exe

font partie des éléments dont Windows dépend pour continuer à fonctionner normalement.

Voir :

CRITICAL_PROCESS_DIED

ne vous dit cependant pas pourquoi ce processus est mort. Le dump devient alors particulièrement important.

Les causes les plus fréquentes

Pilotes

Les pilotes fonctionnent souvent avec des privilèges élevés et certains exécutent du code directement en mode noyau. Une erreur dans un pilote graphique, réseau, stockage, USB, antivirus ou autre composant bas niveau peut donc compromettre tout le système.

Les problèmes apparaissent souvent après :

installation d’un nouveau périphérique ;
mise à jour d’un pilote ;
mise à niveau majeure de Windows ;
installation d’un logiciel ajoutant un pilote noyau.

« Le BSOD a commencé juste après cette installation » constitue une information diagnostique beaucoup plus utile que « j’ai mis tous mes drivers à jour ensuite et maintenant tout est différent ».

RAM et contrôleur mémoire

Une barrette réellement défectueuse peut évidemment provoquer des crashes. Mais la stabilité de la mémoire dépend aussi :

du contrôleur mémoire du CPU ;
de la carte mère ;
du BIOS/UEFI ;
des timings ;
de la tension ;
des profils XMP ou EXPO ;
du nombre et de la combinaison des barrettes.

Un kit parfaitement fonctionnel à ses paramètres JEDEC peut ainsi devenir instable avec un profil mémoire agressif.

Overclocking et undervolting

Lorsqu’un PC instable est overclocké, undervolté ou utilise des réglages automatiques agressifs, la première étape sérieuse consiste souvent à revenir temporairement aux réglages d’origine :

CPU stock
GPU stock
RAM stock
BIOS par défaut raisonnable

Si les BSOD disparaissent, le système vient de fournir un indice assez peu subtil.

Stockage

Un SSD, HDD, contrôleur de stockage, câble ou système de fichiers défaillant peut provoquer :

corruptions ;
erreurs d’entrées/sorties ;
fichiers système illisibles ;
plantages de pilotes ;
crashes pendant le chargement.

Température et alimentation

Une instabilité matérielle peut également venir :

d’une surchauffe CPU ;
d’une surchauffe GPU ;
d’un VRM en difficulté ;
d’une alimentation inadéquate ;
d’un mauvais contact électrique.

Attention toutefois : une coupure électrique brutale provoque souvent un simple redémarrage ou arrêt sans avoir laissé à Windows le temps de générer un dump.

Que faire juste après un BSOD ?

Avant de réparer quoi que ce soit, commencez par collecter des informations.

Notez :

le Stop Code ;
le nom éventuel d’un fichier .sys affiché ;
l’heure exacte ;
l’activité en cours ;
les modifications matérielles ou logicielles récentes ;
la fréquence du problème.

Un crash unique après six mois de fonctionnement stable ne se traite pas de la même façon que :

3 BSOD par jour
toujours pendant un jeu
toujours avec le même Stop Code

Le redémarrage automatique peut cacher le message

Windows peut redémarrer rapidement après le bug check, surtout sur les versions récentes où la collecte est optimisée.

Le Stop Code reste cependant récupérable via :

le dump mémoire ;
les événements système ;
les outils de diagnostic Windows.

Photographier l’écran reste utile si vous avez le temps, mais le dump contient nettement plus d’informations qu’un QR code capturé en panique avec un téléphone.

Les crash dumps

Lorsque Windows peut les créer, les fichiers de dump enregistrent une partie de l’état du système au moment du crash.

Les petits dumps sont généralement stockés dans :

C:\Windows\Minidump\

avec des noms ressemblant à :

082326-12345-01.dmp

D’autres modes de dump utilisent typiquement :

C:\Windows\MEMORY.DMP

Les principaux types de dumps

Type	Contenu général	Usage
Small memory dump	Informations essentielles, pile et modules	Premier diagnostic rapide
Kernel memory dump	Mémoire utilisée par le noyau	Analyse plus approfondie des crashes noyau
Automatic memory dump	Gestion automatique basée sur le dump noyau	Choix courant sur Windows
Active memory dump	Sélection de pages actives pertinentes	Diagnostic avancé
Complete memory dump	Très grande partie ou totalité de la mémoire physique selon configuration	Cas avancés nécessitant beaucoup d’informations

Un minidump est pratique, mais il peut manquer l’information nécessaire lorsque la corruption est complexe.

Si plusieurs petits dumps restent ambigus, un dump noyau peut devenir beaucoup plus utile.

Configurer les dumps

Les options se trouvent notamment via :

sysdm.cpl
↓
Avancé
↓
Démarrage et récupération
↓
Paramètres

Dans :

Écriture des informations de débogage

on peut choisir le type de dump souhaité.

Pour que Windows réussisse à produire le dump, il faut également :

assez d’espace disque ;
une configuration compatible du fichier d’échange ;
un système capable d’écrire suffisamment longtemps avant le redémarrage.

Le dump peut contenir des informations sensibles

Un fichier mémoire peut contenir des fragments de :

données applicatives ;
noms de fichiers ;
communications ;
informations système ;
éventuellement secrets présents en mémoire.

Évitez donc de publier un :

MEMORY.DMP

complet sur un forum public comme s’il s’agissait d’une capture d’écran anodine.

Analyser un dump avec WinDbg

WinDbg est le débogueur officiel de Microsoft.

Il peut notamment être installé avec :

winget install Microsoft.WinDbg

Une fois le dump ouvert, la commande de départ classique est :

!analyze -v

Elle affiche une analyse détaillée comprenant notamment :

le bug check ;
ses paramètres ;
la pile d’appels ;
les modules impliqués ;
divers indices sur l’origine du crash.

Quelques commandes WinDbg utiles

!analyze -v
.bugcheck
kv
lm

La commande :

.bugcheck

affiche le code et ses paramètres.

kv affiche une pile détaillée, tandis que :

lm

permet d’examiner les modules chargés.

Ne condamnez pas le premier fichier .sys affiché

Un dump peut montrer :

ntoskrnl.exe

dans la pile ou dans certains résumés automatiques.

Cela ne signifie généralement pas :

« Le noyau Windows est défectueux, réinstallons immédiatement l’univers. »

ntoskrnl.exe est justement le noyau de Windows : il participe à pratiquement tous les crashes noyau.

De même, un pilote apparaissant en haut de la pile peut être :

le responsable ;
la victime d’une corruption précédente ;
simplement le code qui s’exécutait lorsque Windows a détecté l’erreur.

Comparer plusieurs dumps

Si cinq BSOD successifs montrent :

même bug check
+
même pilote tiers
+
>même fonction
+
même scénario

la piste devient intéressante.

Si les crashes produisent :

0xA
0x1A
0x50
0x139
0x3B

avec des modules différents à chaque fois, on peut davantage soupçonner une corruption mémoire générale ou une instabilité matérielle.

Ce n’est pas une règle absolue, mais la répétition des motifs compte énormément.

BlueScreenView et outils simplifiés

Des outils tiers comme BlueScreenView peuvent fournir une première vue rapide des minidumps :

date du crash ;
Stop Code ;
pilotes présents ;
informations basiques.

Ils sont pratiques pour un premier tri.

Mais une ligne :

Caused By Driver

ne doit pas être considérée comme une expertise judiciaire irréfutable.

Pour les cas complexes, WinDbg et l’interprétation de la pile, des paramètres et du contexte restent nettement plus utiles.

Examiner les journaux Windows

L’Observateur d’événements peut fournir du contexte autour du crash :

eventvwr.msc

Consultez notamment :

Journaux Windows
→
Système

et recherchez les événements autour de l’heure exacte du BSOD.

Vous pouvez y trouver :

le bug check enregistré ;
des erreurs de pilotes ;
des problèmes de stockage ;
des erreurs WHEA ;
des services ayant échoué ;
des informations sur un redémarrage inattendu.

Kernel-Power n’est pas nécessairement la cause

Après un crash brutal, on rencontre souvent un événement indiquant que le système a redémarré sans s’arrêter correctement.

Cet événement constate essentiellement :

Windows n'a pas connu
un arrêt normal auparavant

Il ne prouve pas automatiquement :

alimentation défectueuse

Un BSOD, une coupure de courant ou un appui forcé sur le bouton Power peuvent produire un constat similaire.

Méthode de diagnostic : commencer par ce qui a changé

Si le problème est apparu après :

nouveau GPU
nouveau pilote
mise à jour BIOS
nouvelle RAM
mise à jour Windows
installation antivirus

commencez par cette modification.

Le diagnostic informatique bénéficie énormément d’une technique extrêmement sophistiquée appelée :

se souvenir de ce qu’on a modifié juste avant que tout casse.

Pilotes : mettre à jour, mais intelligemment

La recommandation :

« Mettez tous vos pilotes à jour. »

est trop générale.

Privilégiez les composants réellement suspects :

chipset ;
GPU ;
stockage ;
réseau ;
USB / Thunderbolt ;
audio bas niveau ;
logiciel de sécurité ;
pilotes de virtualisation.

Utilisez idéalement :

Windows Update ;
le constructeur du PC ;
le fabricant de la carte mère ;
le fabricant du périphérique.

Évitez les utilitaires obscurs promettant :

12 847 drivers
mis à jour automatiquement
en un clic

Ils constituent parfois une méthode étonnamment efficace pour transformer un problème de pilote en collection complète de problèmes de pilotes.

Si le problème a commencé après une mise à jour de pilote

Une version plus récente n’est pas obligatoirement plus stable sur votre configuration.

Essayez selon le contexte :

rollback du pilote ;
désinstallation propre ;
réinstallation d’une version validée ;
version recommandée par le fabricant du PC.

Mode sans échec

Le mode sans échec démarre Windows avec un ensemble réduit de pilotes et de services.

Si la machine est stable en mode sans échec mais plante systématiquement en démarrage normal, cela oriente notamment vers :

un pilote tiers ;
un service ;
un logiciel chargé au démarrage.

Ce n’est pas une preuve définitive, mais c’est un excellent test de séparation.

Tester la mémoire

Windows intègre :

mdsched.exe

qui lance le Diagnostic de mémoire Windows.

Une erreur détectée est évidemment significative.

En revanche :

aucune erreur détectée
≠
RAM mathématiquement parfaite

Les problèmes intermittents peuvent dépendre :

de la température ;
de la charge ;
des timings ;
d’un profil XMP/EXPO ;
d’une combinaison spécifique de modules.

Tester avec les paramètres mémoire par défaut

Si un système utilise :

XMP
EXPO
overclocking mémoire
timings manuels

revenez temporairement aux paramètres standard du BIOS.

Si les crashes disparaissent, la configuration mémoire est fortement suspecte, même si les barrettes elles-mêmes ne sont pas physiquement endommagées.

Tester les barrettes séparément

Lorsque le problème persiste, une méthode classique consiste à :

tester une barrette
↓
tester l'autre
↓
tester différents slots
↓
comparer

Cette méthode peut aider à distinguer :

barrette défectueuse ;
slot problématique ;
contrôleur mémoire ;
problème de configuration.

Vérifier le système de fichiers

Pour un contrôle NTFS en ligne, on peut commencer par :

chkdsk C: /scan

Pour réparer certaines erreurs logiques :

chkdsk C: /f

Sur le volume système, Windows peut demander que la réparation soit effectuée au prochain démarrage.

À quoi sert /r ?

La commande :

chkdsk C: /r

inclut les fonctions de :

/f

et ajoute une recherche de secteurs défectueux avec tentative de récupération des informations lisibles.

Elle est donc plus lourde et peut être très longue sur un gros volume.

Ce n’est pas la commande obligatoire à lancer chaque fois qu’un pilote graphique plante.

CHKDSK ne remplace pas le diagnostic matériel du disque

Si le stockage présente :

erreurs répétées ;
timeouts ;
SMART inquiétant ;
bruits mécaniques anormaux ;
déconnexions ;
corruptions récidivantes ;

sauvegardez les données importantes et utilisez aussi les outils de diagnostic du fabricant.

Faire réparer éternellement le système de fichiers d’un disque physiquement mourant revient à repeindre les murs pendant que la maison s’affaisse.

Réparer les fichiers système Windows

Lorsque l’on soupçonne une corruption de composants Windows, Microsoft recommande d’abord :

DISM.exe /Online /Cleanup-Image /RestoreHealth

Puis :

sfc /scannow

DISM répare notamment l’image utilisée comme source par Windows, puis SFC vérifie les fichiers système protégés.

SFC n’est pas un remède universel au BSOD

Si le dump montre clairement qu’un pilote tiers écrit n’importe où en mémoire, :

sfc /scannow

ne transformera pas ce pilote en logiciel bien écrit.

De même, SFC ne réparera pas :

une barrette RAM morte ;
un CPU instable ;
un GPU défectueux ;
une alimentation insuffisante.

Utilisez l’outil correspondant à l’hypothèse diagnostique.

BIOS et firmware

Un BIOS/UEFI peut influencer :

microcode CPU ;
gestion mémoire ;
compatibilité RAM ;
PCI Express ;
gestion énergétique ;
firmware de plateforme.

Une mise à jour peut donc corriger certains problèmes de stabilité.

Mais ne flashez pas un BIOS au milieu d’une enquête uniquement parce que :

« C’était la seule chose que je n’avais pas encore essayée. »

Vérifiez les notes de version et les recommandations du constructeur.

Driver Verifier : faire sortir un mauvais pilote de sa cachette

Windows possède un outil avancé :

verifier.exe

Driver Verifier surveille les pilotes noyau et peut volontairement imposer des conditions plus strictes afin de révéler des comportements incorrects.

Cela peut transformer un crash aléatoire en crash reproductible avec un dump beaucoup plus explicite.

Mais Driver Verifier est volontairement agressif

Il peut :

ralentir le système ;
provoquer davantage de BSOD ;
rendre une machine difficile à démarrer si mal configuré.

Driver Verifier doit être utilisé pour diagnostiquer un problème précis, idéalement sur une machine dont on peut récupérer l’accès. Ce n’est pas un outil d’entretien préventif.

Évitez « verifier /all » sans réfléchir

Il est généralement plus judicieux de cibler un petit ensemble de pilotes suspects que de tester aveuglément tout ce qui existe.

Pour afficher la configuration :

verifier /querysettings

Pour réinitialiser Driver Verifier :

verifier /reset

puis redémarrer.

Si Driver Verifier empêche Windows de démarrer

Le mode sans échec ou Windows Recovery Environment permet généralement de reprendre le contrôle et de désactiver la configuration.

C’est précisément pourquoi il vaut mieux savoir comment exécuter :

verifier /reset

avant d’exécuter :

verifier

La connaissance de la sortie de secours améliore considérablement l’expérience des outils conçus pour provoquer volontairement des crashes.

Et les malwares ?

Un malware suffisamment privilégié peut provoquer de l’instabilité, notamment s’il installe :

un pilote noyau ;
un rootkit ;
un filtre réseau ;
un composant de sécurité détourné.

Mais face à un BSOD, il ne faut pas automatiquement transformer :

0x00000050

en :

« J’ai été piraté. »

Pilotes, matériel et instabilité restent des pistes beaucoup plus courantes.

Une analyse antivirus reste néanmoins pertinente si le système présente d’autres signes suspects.

Ne réinitialisez pas Windows trop tôt

La réinstallation ou :

Réinitialiser ce PC

peut résoudre une corruption logicielle importante.

Mais elle ne réparera pas :

une RAM défectueuse ;
un SSD en panne ;
une carte graphique instable ;
un BIOS mal configuré ;
une alimentation défaillante.

Si Windows fraîchement installé recommence à planter dès que la machine est chargée, la réinstallation vient surtout de vous fournir un indice matériel particulièrement coûteux en temps.

Une méthode de diagnostic rationnelle

Pour éviter le dépannage au hasard, utilisez une progression simple.

Noter le Stop Code et le contexte.
Récupérer les dumps.
Comparer plusieurs crashes si le problème se répète.
Identifier les modifications récentes.
Examiner les pilotes et journaux concernés.
Revenir temporairement aux fréquences et tensions d’origine.
Tester RAM, stockage et températures selon les indices.
Réparer les fichiers système si une corruption Windows est plausible.
Utiliser Driver Verifier uniquement si l’hypothèse pilote reste forte et que la machine est récupérable.
Réinstaller Windows seulement lorsque les investigations le justifient.

Exemple : crash apparu après un nouveau pilote GPU

Installation du pilote
        ↓
BSOD en jeu
        ↓
dump montrant le pilote graphique
        ↓
rollback du pilote
        ↓
stabilité retrouvée

Le lien causal devient raisonnablement convaincant.

Exemple : Stop Codes aléatoires après activation XMP

XMP activé
↓
MEMORY_MANAGEMENT
↓
IRQL_NOT_LESS_OR_EQUAL
↓
PAGE_FAULT_IN_NONPAGED_AREA
↓
XMP désactivé
↓
plus aucun crash

Une instabilité mémoire devient beaucoup plus plausible qu’un noyau Windows ayant décidé de développer simultanément trois personnalités.

Exemple : aucun dump et extinction instantanée

Si la machine :

s'éteint brutalement
↓
écran noir
↓
redémarre
↓
aucun dump

il faut envisager plus sérieusement :

alimentation ;
protection thermique ;
carte mère ;
perte électrique ;
blocage matériel sévère.

Un véritable bug check laisse normalement davantage de traces lorsque Windows dispose du temps et des ressources nécessaires pour écrire le dump.

Prévenir les BSOD

On ne peut pas garantir qu’un système ne plantera jamais, mais quelques pratiques réduisent fortement les risques :

installer des pilotes provenant de sources fiables ;
maintenir Windows à jour ;
mettre à jour firmware et BIOS lorsque cela est pertinent ;
éviter les utilitaires de drivers douteux ;
tester sérieusement les overclockings et undervoltings ;
surveiller les températures ;
utiliser une alimentation correctement dimensionnée ;
surveiller l’état du stockage ;
conserver suffisamment d’espace libre ;
maintenir les crash dumps activés ;
conserver des sauvegardes indépendantes.

La sauvegarde reste plus importante que le BSOD

Un BSOD peut être réparé.

Un fichier important dont la seule copie se trouvait sur un SSD défaillant demande parfois des compétences beaucoup plus coûteuses.

Le dump sert à comprendre pourquoi Windows est tombé. La sauvegarde sert à faire en sorte que vous vous en moquiez raisonnablement.

Checklist rapide

Symptôme	Première piste
Un seul BSOD isolé	Noter le code et surveiller la récurrence
Toujours le même pilote dans plusieurs dumps	Pilote ou périphérique correspondant
Codes mémoire aléatoires	RAM, overclocking, pilote corrupteur
Crash uniquement en charge	Température, GPU, CPU, RAM, alimentation
Crash après nouveau pilote	Rollback / réinstallation ciblée
Crash après ajout de RAM	Configuration mémoire, modules, slots, BIOS
Erreurs disque et fichiers corrompus	Stockage, CHKDSK, diagnostic constructeur
Extinction sans dump	Alimentation, température, matériel
Crash seulement en démarrage normal	Pilote ou service tiers ; tester le mode sans échec

Commandes utiles

Vérifier et réparer l’image Windows

DISM.exe /Online /Cleanup-Image /RestoreHealth

Vérifier les fichiers système

sfc /scannow

Contrôler NTFS en ligne

chkdsk C: /scan

Réparer les erreurs du système de fichiers

chkdsk C: /f

Diagnostic mémoire Windows

mdsched.exe

Observateur d’événements

eventvwr.msc

Propriétés système et configuration des dumps

sysdm.cpl

Désactiver Driver Verifier

verifier /reset

Première analyse dans WinDbg

!analyze -v

Les points essentiels à retenir

Un BSOD est un bug check du noyau Windows provoqué lorsque le système estime qu’il ne peut plus continuer de manière sûre.
Sur Windows 11 24H2 et versions ultérieures, l’écran de Stop error peut être noir malgré le nom historique BSOD.
Le Stop Code décrit le type de problème détecté, pas nécessairement sa cause racine.
MEMORY_MANAGEMENT ne signifie pas automatiquement que la RAM est défectueuse.
Un pilote indiqué dans un dump est un indice à confirmer, pas nécessairement le coupable définitif.
Un seul dump peut être ambigu ; plusieurs crashes comparables permettent souvent de dégager un motif.
Les petits dumps se trouvent généralement dans C:\Windows\Minidump\.
Les dumps plus importants utilisent généralement C:\Windows\MEMORY.DMP.
WinDbg et !analyze -v constituent une base solide pour l’analyse.
BlueScreenView est pratique pour un premier aperçu mais ne remplace pas une analyse détaillée.
Overclocking, undervolting, XMP et EXPO doivent être désactivés temporairement lors d’une recherche d’instabilité.
chkdsk /f répare les erreurs logiques ; /r ajoute une analyse des secteurs et n’est pas nécessaire pour chaque BSOD.
Pour réparer Windows, utilisez généralement DISM avant SFC.
Driver Verifier peut volontairement provoquer des crashes et doit être utilisé avec prudence.
Une extinction instantanée sans dump peut orienter davantage vers un problème matériel ou électrique qu’un bug check classique.
Réinstaller Windows ne répare pas un composant matériel défectueux.

Conclusion : le BSOD est un témoin, pas un verdict

Un écran bleu — ou désormais parfois noir — n’est pas Windows qui abandonne par caprice. C’est Windows qui annonce :

« Mon état interne n’est plus suffisamment cohérent pour continuer sans risque. »

Le diagnostic sérieux consiste ensuite à reconstruire la chronologie :

Stop Code
↓
paramètres
↓
dump
↓
pile d'appels
↓
pilotes
↓
contexte
↓
tests ciblés
↓
cause probable

Évitez donc les réflexes du type :

BSOD
↓
mettre tous les pilotes à jour
↓
chkdsk /r
↓
sfc
↓
réinstaller Windows
↓
changer de PC

Un bon diagnostic réduit progressivement les hypothèses au lieu de modifier dix choses simultanément.

Car derrière chaque BSOD se cache effectivement un problème qui attend d’être compris.

Parfois c’est la RAM.

Parfois c’est le stockage.

Parfois c’est un pilote graphique.

Et parfois, après trois heures dans WinDbg, la conclusion technique la plus précise reste :

« Quelqu’un a écrit dans une zone mémoire où il n’avait absolument rien à faire. »

Ce qui, pour le noyau Windows, constitue une raison parfaitement valable de quitter la pièce.

Post Views: 10