Comment corriger KERNEL_SECURITY_CHECK_FAILURE dans Windows 11

Ce qui rate le contrôle de sécurité

Le noyau tient des sommes de contrôle et des invariants sur ses structures critiques, un peu comme une banque qui rapproche ses livres plusieurs fois par seconde. Le code 0x139 signifie qu'un de ces rapprochements a mal tourné : un pointeur de liste ne pointe plus où il doit, ou l'en-tête d'un tampon ne correspond plus à son contenu. Windows s'arrête volontairement, car poursuivre avec un état noyau corrompu risque d'écrire n'importe quoi partout sur le disque.

Ce qui corrompt ces structures tient rarement du mystère. La mémoire qui renvoie des bits inversés en charge — souvent un profil XMP ou EXPO au-delà de ce que le contrôleur mémoire encaisse réellement — mène la liste. Les pilotes qui écrivent hors de leurs tampons viennent ensuite, ceux du GPU et des antivirus étant les récidivistes. Les fichiers système endommagés et un SSD mourant qui sert des lectures corrompues complètent le tableau.

• RAM instable — profils XMP/EXPO au-delà de ce que le contrôleur mémoire du CPU encaisse vraiment
• Un pilote bogué écrivant hors de son tampon — GPU, antivirus et virtualisation en tête des récidivistes
• Fichiers système corrompus par une mise à jour ratée ou une coupure de courant soudaine
• Un SSD mourant qui renvoie des données corrompues à la lecture, visible dans les attributs SMART
• Undervolting ou overclocking agressifs qui basculent des bits en charge

Tester la mémoire et réparer les fichiers

Commencez par la mémoire : c'est la cause la plus fréquente et la moins chère à écarter. Lancez mdsched.exe, redémarrez à la demande et laissez tourner la passe standard ; le verdict tombe dans l'Observateur d'événements sous Journaux Windows → Système, source MemoryDiagnostics-Results. La passe standard ne prend que les pannes grossières — si les plantages continuent avec un verdict propre, coupez le XMP/EXPO dans le BIOS et testez les barrettes une par une avant d'innocenter la mémoire.

Les fichiers suivent, depuis une « Invite de commandes (administrateur) » : sfc /scannow compare les fichiers protégés au magasin de composants, puis DISM /Online /Cleanup-Image /RestoreHealth répare le magasin lui-même si SFC n'a pas tout pu corriger, puis chkdsk C: /f /r balaie la surface du disque au redémarrage suivant. Une réinstallation propre du pilote graphique boucle le côté logiciel : téléchargez le dernier paquet, retirez l'ancien dans Paramètres → Applications → Applications installées, et installez le neuf après un redémarrage.

Cerner le récidiviste

Si le code d'arrêt survit à tout ça, le plantage est assez spécifique pour porter un nom. Les minidumps de C:\Windows\Minidump portent l'adresse fautive et la liste des modules chargés ; WinDbg avec !analyze -v ou un lecteur comme BlueScreenView en tire un nom de pilote, et ce nom met fin à la chasse. Les logiciels installés dans les jours précédant le premier plantage méritent le premier interrogatoire : les désinstaller sert à la fois de test et de traitement.

L'outil du dernier recours est le Vérificateur de pilotes (verifier /standard /all depuis une console admin), qui fait planter les pilotes suspects sur leurs propres bogues, bruyamment et immédiatement. Il est dangereux à dessein : attendez-vous à des écrans bleus pendant qu'il tourne, et retenez la sortie — démarrez en mode sans échec et lancez verifier /reset pour l'éteindre. Conduit ainsi, Verifier débusque un pilote planqué en un ou deux jours.

Questions et réponses

À lire ensuite

Tous les articles · FAQ