Écran bleu SYSTEM_THREAD_EXCEPTION_NOT_HANDLED : les solutions

Neuf fois sur dix, l’écran bleu SYSTEM_THREAD_EXCEPTION_NOT_HANDLED vient d’un pilote qui a levé une exception que Windows n’a pas su rattraper. Le nom du fichier fautif est souvent affiché entre parenthèses sur l’écran bleu, et c’est lui qui donne la marche à suivre.

Points clés

• Code d’arrêt 0x0000007E : un thread système a généré une exception non interceptée [Microsoft Learn].
• Les codes d’exception les plus courants sont 0xC0000005 (violation d’accès mémoire), 0x80000003 (point d’arrêt) et 0x80000002 (donnée mal alignée).
• Le nom de pilote affiché sur l’écran bleu (par exemple un fichier .sys) désigne le module à mettre à jour, à restaurer ou à désactiver.
• Quand le PC ne démarre plus, tout se règle depuis le mode sans échec ou l’environnement de récupération.
• La réinstallation de Windows arrive en dernier, jamais avant d’avoir testé la mémoire et le disque.

Ce que signifie réellement SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

Le contrôle d’erreur 0x0000007E indique qu’un thread exécuté en mode noyau a déclenché une exception et que le gestionnaire d’erreurs ne l’a pas capturée. Windows ne peut plus garantir l’intégrité du système, il arrête tout et affiche l’écran bleu.

Quatre paramètres accompagnent ce contrôle d’erreur : le code d’exception non intercepté, l’adresse où l’exception s’est produite, l’adresse de l’enregistrement de l’exception, celle de l’enregistrement du contexte. Le premier paramètre est le plus parlant. Un 0xC0000005 signale une violation d’accès à la mémoire, c’est-à-dire un pilote qui lit ou écrit à une adresse qui ne lui appartient pas. Un 0x80000003 correspond à un point d’arrêt atteint alors qu’aucun débogueur noyau n’est attaché.

Les causes fréquentes sur un poste ordinaire

• Un pilote graphique corrompu ou incompatible après une mise à jour, en particulier sur portable avec double GPU.
• Un pilote réseau ou audio ancien, resté en place après une montée de version de Windows.
• Un microprogramme (BIOS ou UEFI) qui n’a pas suivi le matériel installé.
• De la mémoire vive défaillante ou mal configurée, y compris un profil XMP trop agressif.
• Des fichiers système endommagés par un arrêt brutal ou un disque en fin de vie.
• Un conflit matériel, une incompatibilité de composant récent avec la version de Windows installée.

Le message affiche parfois un nom de fichier entre parenthèses, du type nvlddmkm.sys, atikmdag.sys ou rtwlane.sys. Ce nom vaut diagnostic : il pointe le pilote qui a planté.

Solution 1 : lire le nom du pilote et l’Observateur d’événements

Photographiez l’écran bleu avant qu’il ne disparaisse. Notez le code d’arrêt et le fichier cité. Puis, une fois Windows revenu, ouvrez l’Observateur d’événements (touche Windows + R, eventvwr.msc), section Journaux Windows puis Système, et repérez les erreurs critiques à l’heure du plantage. Microsoft recommande explicitement cette lecture du journal système pour identifier le périphérique ou le pilote à l’origine du 0x7E.

Les fichiers de vidage (crash dump) sont dans C:\Windows\Minidump. Ils ne servent à rien sans débogueur, mais leur date confirme la fréquence réelle des plantages. Le dossier Minidump reste par ailleurs le seul endroit où un dépanneur pourra chercher des informations précises sur le crash.

Solution 2 : démarrer en mode sans échec quand le PC boucle

Si l’écran bleu revient avant même l’ouverture de session, coupez l’alimentation pendant la séquence de démarrage à trois reprises : Windows bascule seul dans l’environnement de récupération. De là, Dépannage, Options avancées, Paramètres, puis Redémarrer et touche 4 ou 5. Le mode sans échec charge un jeu de pilotes minimal, donc l’écran bleu disparaît généralement le temps de travailler. La procédure complète est détaillée dans notre guide du mode sans échec sous Windows 11.

Solution 3 : mettre à jour, restaurer ou désinstaller le pilote fautif

Trois gestes, du plus doux au plus radical, dans le Gestionnaire de périphériques (clic droit sur le menu Démarrer) :

1. Mettre à jour le pilote, de préférence avec le paquet officiel du fabricant du composant ou du portable, pas avec un utilitaire de mise à jour tiers.
2. Restaurer la version précédente, via l’onglet Pilote puis le bouton de restauration, si le problème est apparu juste après une mise à jour.
3. Désinstaller le périphérique en cochant la suppression du logiciel de pilote, puis redémarrer pour laisser Windows réinstaller une version générique.

Sur un pilote graphique, une désinstallation propre en mode sans échec suivie d’une installation du paquet constructeur règle une grande partie des cas.

Solution 4 : réparer les fichiers système et l’image Windows

Ouvrez une invite de commandes en administrateur et lancez, dans cet ordre :

1. sfc /scannow pour vérifier et réparer les fichiers système protégés.
2. DISM /Online /Cleanup-Image /RestoreHealth si le premier signale des corruptions qu’il n’a pas pu réparer.
3. chkdsk C: /f /r puis un redémarrage, si le disque est suspect.

Comptez plusieurs dizaines de minutes pour le contrôle de disque sur un disque mécanique. Ne l’interrompez pas.

Solution 5 : tester la mémoire vive et revenir aux réglages d’origine

Une barrette instable produit exactement ce type d’exception aléatoire. Lancez l’outil Diagnostic de mémoire Windows (mdsched.exe), en choisissant le redémarrage immédiat. Si le test passe alors que les plantages continuent, testez les barrettes une par une, dans le premier emplacement.

Côté BIOS ou UEFI, désactivez le profil de mémoire XMP ou EXPO et toute forme d’overclocking, puis revenez aux valeurs par défaut. Microsoft cite aussi la mise en cache mémoire du BIOS comme piste sur ce contrôle d’erreur. Un microprogramme à jour, récupéré sur le site du fabricant de la carte mère ou du portable, ferme le sujet.

Solution 6 : isoler le pilote coupable avec le Vérificateur de pilotes

Quand aucun nom de fichier n’apparaît, le Vérificateur de pilotes (verifier.exe) soumet les pilotes tiers à des contrôles stricts et provoque un écran bleu nominatif dès qu’un pilote se comporte mal. Sélectionnez la création de paramètres personnalisés, puis la vérification des pilotes non signés par Microsoft uniquement.

Cet outil est puissant et déstabilise volontairement la machine : notez la commande d’arrêt verifier /reset avant de commencer, et prévoyez de la lancer depuis le mode sans échec si le poste ne démarre plus. Il n’a pas sa place sur une machine de production en pleine journée.

Solution 7 : restauration système, réinitialisation, réinstallation

Si rien n’a fonctionné, remontez dans le temps avec un point de restauration antérieur au premier plantage. À défaut, la réinitialisation de Windows en conservant les fichiers personnels réinstalle le système sans toucher aux documents, mais supprime les applications de bureau. La réinstallation complète depuis un support d’installation reste le dernier recours, après sauvegarde intégrale des données : cette étape efface tout.

Sauvegarder avant les solutions lourdes

Avant toute réinstallation ou réinitialisation, copiez vos informations importantes sur un disque externe ou un espace en ligne. Un ordinateur qui affiche ce BSOD de façon répétée peut devenir inaccessible d’un redémarrage à l’autre, et les outils de récupération de Windows ne protègent pas les fichiers d’un disque défaillant.

Un support d’installation de Windows, à télécharger depuis le site de Microsoft avec l’outil de création de média, complète la trousse : il ouvre l’environnement de récupération même quand le système ne démarre plus, et il donne accès à l’invite de commandes pour lancer les réparations.

Résumé des solutions par situation

• L’ordinateur démarre encore : lecture du message d’erreur, journal système, mise à jour du pilote cité, puis sfc et DISM sur les fichiers corrompus.
• Le PC boucle sur le BSOD : mode sans échec, désinstallation du dernier pilote installé, point de restauration.
• Le crash revient sans pilote identifié : test mémoire, réglages BIOS par défaut, Vérificateur de pilotes.
• Rien n’y fait : réinitialisation en conservant les fichiers, puis réinstallation complète après sauvegarde.

Quand ça ne vient pas du pilote

Un 0x7E qui persiste après avoir désinstallé tous les pilotes tiers pointe généralement vers le matériel. Surveillez trois signes : des plantages qui surviennent sous charge uniquement, des redémarrages accompagnés d’autres codes d’arrêt (le hub des écrans bleus Windows 10 et 11 recense les principaux), des erreurs disque dans le journal système. Un stockage défaillant produit d’ailleurs plus souvent un KERNEL_DATA_INPAGE_ERROR, tandis qu’un pilote qui accède à une mauvaise adresse mémoire déclenche souvent un IRQL_NOT_LESS_OR_EQUAL. Ces trois codes se traitent avec la même méthode, dans le même ordre.

Autre cas à part : un antivirus tiers ou un outil de chiffrement installe ses propres pilotes en mode noyau. Une désinstallation temporaire avec l’utilitaire de suppression de l’éditeur tranche la question en une redémarrage.

FAQ

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED est-il un problème matériel ?

Pas en premier lieu. Le contrôle d’erreur décrit un problème logiciel en mode noyau, presque toujours un pilote. Le matériel n’entre en jeu que si l’erreur revient avec des pilotes propres, ou si la mémoire et le disque échouent aux tests.

Que faire si le PC ne démarre plus du tout ?

Provoquez trois échecs de démarrage consécutifs pour ouvrir l’environnement de récupération, puis passez en mode sans échec avec prise en charge du réseau. Les mises à jour de pilotes, la restauration système et les commandes de réparation y sont toutes accessibles.

Le fichier affiché entre parenthèses désigne-t-il toujours le coupable ?

Il désigne le module dans lequel l’exception s’est produite, ce qui est presque toujours le bon point de départ. Un fichier générique comme ntoskrnl.exe fait exception : le noyau n’est alors que le messager, et l’analyse doit continuer côté pilotes tiers, comme sur un écran bleu ntoskrnl.exe.

Faut-il désactiver le démarrage rapide ?

C’est un test utile quand les plantages se produisent surtout à l’allumage. Le démarrage rapide restaure un état système figé, donc il perpétue un contexte de pilote déjà instable. Désactivez-le dans les options d’alimentation, observez quelques jours, réactivez-le si rien ne change.

Combien de temps garder le Vérificateur de pilotes actif ?

Le temps de reproduire au moins un plantage, rarement plus de 48 heures d’usage normal. Ensuite, verifier /reset et un redémarrage remettent la machine dans son état habituel.

Sources

_{Photo d’en-tête : écran bleu SYSTEM_THREAD_EXCEPTION_NOT_HANDLED photographié sur un PC sous Windows, avec le fichier dxgmms2.sys en cause. Photo Oleg Yunakov, CC BY-SA 4.0, via Wikimedia Commons. Le pilote affiché sur cette photo est un exemple, pas nécessairement celui de votre machine.
Microsoft Learn, Bug Check 0x7E : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED.
Microsoft Learn, Référence des codes de contrôle d’erreur.
Microsoft Learn, Driver Verifier.
Microsoft Learn, Commande sfc.
Support Microsoft, Résoudre les erreurs d’écran bleu.
Support Microsoft, Options de récupération dans Windows.}