Écran bleu KERNEL_SECURITY_CHECK_FAILURE : les solutions

Un écran bleu KERNEL_SECURITY_CHECK_FAILURE signifie que le noyau de Windows a trouvé une structure de données critique abîmée et a coupé le système plutôt que de continuer. Dans la grande majorité des cas, la cause réelle est un pilote défectueux, une mémoire vive instable ou un système de fichiers corrompu sur le disque.

Points clés

• Code d’arrêt officiel : 0x00000139, documenté par Microsoft comme la détection d’une altération d’une structure de données critique du noyau.
• Le premier paramètre du code d’erreur indique le type de corruption : dépassement de mémoire tampon sur la pile, liste chaînée LIST_ENTRY endommagée, paramètre invalide passé à une fonction, dépassement de bornes de tableau.
• Trois familles de causes couvrent presque tous les cas réels : pilote, mémoire, fichiers système ou disque.
• Les solutions se traitent de la plus légère à la plus lourde. La réinstallation de Windows arrive en dernier, jamais en premier.

Ce que dit vraiment le code 0x139

La documentation Microsoft est explicite : la vérification de bogue KERNEL_SECURITY_CHECK_FAILURE a la valeur 0x00000139 et indique que le noyau a détecté l’altération d’une structure de données critique. Ce n’est donc pas un message de sécurité au sens antivirus. Le mot « security check » désigne les contrôles d’intégrité que le compilateur et le noyau insèrent dans le code Windows pour arrêter net un composant qui écrit là où il ne devrait pas.

Le premier des quatre paramètres affichés dans un vidage mémoire précise la nature du problème. La valeur 0 correspond au dépassement d’une mémoire tampon basée sur la pile, la valeur 2 à une violation détectée par les cookies de pile, la valeur 3 à une structure LIST_ENTRY endommagée, par exemple une double suppression, la valeur 5 à un paramètre invalide transmis à une fonction qui considère cela comme fatal, la valeur 8 à une opération d’indexation de tableau illégale. Les valeurs 10 et 11 viennent des protections Control Flow Guard : transfert de contrôle non valide, écriture mémoire non valide.

Conséquence pratique pour un poste de travail : le code désigne le moment où Windows s’est protégé, pas le coupable. Le coupable est presque toujours un composant tiers chargé dans le noyau, autrement dit un pilote.

Les causes classées par fréquence

• Pilote incompatible ou corrompu. Carte graphique, contrôleur de stockage, chipset, périphérique USB, VPN, antivirus avec composant noyau. Un écran bleu apparu juste après une mise à jour de pilote pointe cette piste.
• Mémoire vive instable. Barrette défaillante, profil XMP ou EXPO trop agressif, mélange de modules de fréquences différentes.
• Fichiers système corrompus. Coupure de courant pendant une mise à jour, arrêt brutal, image Windows abîmée.
• Disque en fin de vie. Secteurs illisibles ou micrologiciel SSD ancien qui renvoie des données incohérentes au noyau.
• Overclocking du processeur ou de la mémoire, y compris les profils automatiques des cartes mères.
• Logiciel bas niveau mal désinstallé, dont les restes de pilote continuent de se charger au démarrage.

Lire l’écran bleu et le journal des événements

Le BSOD affiche un texte court, un code d’arrêt et parfois le nom du fichier fautif, du type nvlddmkm.sys ou storahci.sys. Ce nom vaut de l’or : il désigne directement le pilote à traiter. Prenez l’écran en photo avant le redémarrage automatique de l’ordinateur, parce que la ligne disparaît ensuite.

Une fois Windows revenu, l’Observateur d’événements permet d’analyser l’historique des erreurs. Ouvrez eventvwr.msc, section Journaux Windows puis Système, et filtrez sur les niveaux Erreur et Critique autour de l’heure du plantage. Les entrées de source BugCheck et Kernel-Power confirment l’arrêt et l’horodatent. Les outils intégrés à Windows suffisent ici : aucun logiciel de réparation tiers n’apporte d’information que ces journaux ne contiennent pas.

Solution 1 : redémarrer proprement et noter le contexte

Avant toute manipulation, un redémarrage complet de l’ordinateur permet de savoir si le problème est ponctuel ou systématique. Profitez de ce moment pour sauvegarder les documents importants sur un disque externe, avant d’engager la moindre réparation. Notez ce que faisait la machine au moment de l’écran bleu : jeu, copie de fichiers, connexion d’un périphérique, mise en veille. Cette information vaut plus que n’importe quel utilitaire, parce qu’elle isole déjà la famille de causes.

Si le poste ne démarre plus assez longtemps pour travailler, passez par le mode sans échec, qui charge un jeu minimal de pilotes.

Solution 2 : annuler le dernier changement de pilote

Ouvrez le Gestionnaire de périphériques, sélectionnez le composant suspect, onglet Pilote, bouton Version précédente. Si le bouton est grisé, désinstallez le pilote en cochant la suppression du logiciel, puis récupérez la version stable sur le site du fabricant du composant, pas sur un agrégateur de pilotes.

Pour une carte graphique, la désinstallation propre suivie d’une installation de la branche antérieure règle une bonne partie des écrans bleus de ce type. Le même raisonnement s’applique aux contrôleurs de stockage : un pilote NVMe fourni par le fabricant du SSD est parfois plus fiable que le pilote générique, parfois moins, et l’inversion se teste.

Solution 3 : vérifier l’intégrité des fichiers système

Ouvrez un terminal en administrateur, puis lancez les trois outils de réparation intégrés à Windows, dans cet ordre :

• sfc /scannow analyse les fichiers système protégés et remplace ceux qui sont abîmés par une copie mise en cache.
• DISM /Online /Cleanup-Image /RestoreHealth répare l’image Windows elle-même quand le magasin de composants est atteint, ce que sfc ne sait pas faire seul.
• chkdsk C: /f /r localise les secteurs défectueux et récupère l’information lisible. Le passage exige un redémarrage et peut durer plusieurs heures sur un disque mécanique.

Une remarque de méthode pour les scripts de diagnostic : l’outil en ligne de commande WMIC a été retiré de Windows 11 en versions 24H2 et 25H2. Les commandes équivalentes se font désormais avec les cmdlets CIM de PowerShell.

Solution 4 : tester la mémoire vive

Lancez mdsched.exe pour programmer le diagnostic de mémoire Windows au prochain démarrage. Un test propre ne garantit rien, un test qui échoue donne une réponse définitive. Comptez plusieurs passages pour analyser correctement des problèmes de mémoire intermittents. Sur une machine à plusieurs barrettes, la méthode la plus fiable reste de démarrer avec une seule barrette à la fois et de faire tourner le poste quelques heures.

Si la carte mère applique un profil XMP ou EXPO, désactivez-le dans le firmware UEFI et revenez à la fréquence de base JEDEC. Un profil mémoire instable produit exactement ce genre de corruption aléatoire de structures noyau.

Solution 5 : identifier le pilote fautif avec le vérificateur de pilotes

Le vérificateur de pilotes de Microsoft, lancé par verifier.exe, soumet les pilotes sélectionnés à des contrôles stricts et provoque volontairement un arrêt sur le composant en faute. L’outil est fait pour cela, mais il rend le poste instable tant qu’il est actif.

Deux précautions avant de l’activer : créez un point de restauration, et sachez comment le désactiver depuis le mode sans échec avec verifier /reset. Ne le lancez jamais sur une machine de production sans sauvegarde à jour.

Solution 6 : revenir en arrière avec la restauration du système

Si un point de restauration antérieur à la panne existe, la restauration du système remet les fichiers système, le Registre et les programmes installés dans leur état précédent sans toucher aux documents personnels. Tapez « Créer un point de restauration » dans la recherche pour vérifier si la protection du système est active sur le disque C, puis ouvrez rstrui.exe.

Cette étape n’aide pas quand la cause est matérielle. Elle règle en revanche très vite les cas nés d’une installation logicielle ou d’une mise à jour de pilote.

Solution 7 : réparer ou réinitialiser Windows

En dernier recours, la réinstallation de la version en place conserve les fichiers et les applications tout en remplaçant les composants système. La réinitialisation, plus radicale, remet les applications et les paramètres à zéro avec une option de conservation des fichiers personnels. Le détail des choix se trouve dans notre guide sur la réinitialisation d’un PC Windows 11.

Avertissement : ces opérations sont destructives à des degrés variables. Copiez vos données sur un support externe avant de commencer, y compris si l’assistant promet de les garder.

Quand ça ne vient pas de là

Un BSOD qui revient après une réinstallation complète n’est plus un problème logiciel. Le problème est alors matériel. Regardez du côté de l’alimentation, de la température du processeur, d’un SSD dont le micrologiciel n’a jamais été mis à jour, ou d’une carte mère dont le firmware date de plusieurs années. Un code d’arrêt qui change à chaque plantage est le signal typique d’un défaut matériel plutôt que d’un pilote unique : dans ce cas, comparez les codes obtenus avec le guide des écrans bleus Windows.

Les codes voisins méritent aussi un coup d’œil, parce qu’ils partagent la même origine : KMODE_EXCEPTION_NOT_HANDLED et SYSTEM_SERVICE_EXCEPTION désignent tous les deux un pilote qui a franchi une limite, et BAD_SYSTEM_CONFIG_INFO pointe une ruche de Registre abîmée.

Questions fréquentes

KERNEL_SECURITY_CHECK_FAILURE est-il lié à un virus ?

Rarement. Un poste infecté produit plutôt des ralentissements et des erreurs applicatives. Le terme « security check » désigne un contrôle d’intégrité interne du noyau, pas une détection de logiciel malveillant. Un antivirus tiers doté d’un pilote noyau peut en revanche provoquer ce code, ce qui se teste en le désinstallant temporairement.

Perd-on ses fichiers pendant les réparations ?

Les commandes de vérification et la restauration du système ne touchent pas aux documents personnels. La réinitialisation et la réinstallation peuvent en supprimer selon l’option choisie. Sauvegarder ses données avant l’opération n’est donc pas facultatif, image disque comprise si le poste sert au travail.

Faut-il analyser le fichier de vidage mémoire ?

C’est utile quand les solutions courantes ne donnent rien. Le fichier de vidage contient le nom du pilote, ou driver, en cause dans la plupart des cas, mais sa lecture demande un débogueur, donc un niveau d’exigence technique élevé.

Le code apparaît seulement en jeu, est-ce la carte graphique ?

C’est la première hypothèse, sans être la seule. Une charge élevée sollicite aussi l’alimentation et la mémoire, donc le test mémoire et le retour à des fréquences par défaut restent pertinents.

Peut-on ignorer un écran bleu isolé ?

Un plantage unique après une mise à jour peut rester sans suite. Deux occurrences ou plus en une semaine signifient qu’une cause persiste et qu’un diagnostic ordonné évite la panne franche.

_{Photo d’en-tête : écran bleu de Windows 11 photographié par PantheraLeo1359531, Wikimedia Commons, CC BY 4.0. Le code d’arrêt visible sur la photo n’est pas celui traité dans cet article.
Sources : Microsoft Learn, Bug Check 0x139 KERNEL_SECURITY_CHECK_FAILURE ; Microsoft Support, résoudre les erreurs d’écran bleu ; Microsoft Learn, vérificateur de pilotes ; Microsoft Learn, commande sfc ; Microsoft Learn, réparer une image Windows ; Microsoft Learn, commande chkdsk.}