Bug Check 0x139 : KERNEL_SECURITY_CHECK_FAILURE
L’erreur KERNEL_SECURITY_CHECK_FAILURE a une valeur de 0x00000139. Cette erreur indique que le noyau a détecté la corruption d’une structure de données critique.
Important
Cet article s’adresse aux programmeurs. Si vous êtes un client et que vous avez reçu ce code d’erreur d’écran bleu en utilisant votre ordinateur, consultez Résoudre les erreurs d’écran bleu.
Erreur 0x139 Paramètres KERNEL_SECURITY_CHECK_FAILURE
| Paramètre | Description |
|---|---|
| 1 | Le type de corruption. Pour plus d’informations, consultez le tableau suivant. |
| 2 | Adresse de la trame de piégeage pour l’exception qui a causé l’erreur. |
| 3 | Adresse de l’enregistrement d’exception pour l’exception qui a causé l’erreur. |
| 4 | Reserved |
Le tableau suivant décrit les valeurs possibles pour le Paramètre 1.
| Paramètre 1 | Description |
|---|---|
| 0 | Un tampon basé sur la pile a été débordé (violation /GS héritée). |
| 1 | Le code d’instrumentation VTGuard a détecté une tentative d’utilisation d’une table de fonctions virtuelles illégale. Typiquement, un objet C++ a été corrompu, puis un appel de méthode virtuelle a été tenté en utilisant le pointeur this de l’objet corrompu. |
| 2 | Le code d’instrumentation des cookies de pile a détecté un débordement de tampon basé sur la pile (violation /GS). |
| 3 | Un LIST_ENTRY a été corrompu (par exemple, une double suppression). Pour plus d’informations, veuillez consulter la section Cause suivante. |
| 4 | Reserved |
| 5 | Un paramètre invalide a été passé à une fonction qui considère les paramètres invalides comme fatals. |
| 6 | Le cookie de sécurité de la pile n’a pas été correctement initialisé par le chargeur. Cela peut être causé par la création d’un pilote pour fonctionner uniquement sur Windows 8 et la tentative de chargement de l’image du pilote sur une version antérieure de Windows. Pour éviter ce problème, vous devez créer le pilote pour qu’il fonctionne sur une version antérieure de Windows. |
| 7 | Une sortie fatale du programme a été demandée. |
| 8 | Une vérification des limites de tableau insérée par le compilateur a détecté une opération d’indexation de tableau illégale. |
| 9 | Un appel à RtlQueryRegistryValues a été effectué en spécifiant RTL_QUERY_REGISTRY_DIRECT sans RTL_QUERY_REGISTRY_TYPECHECK, et la valeur cible n’était pas dans une ruche système de confiance. |
| 10 | La vérification de la protection des appels indirects a détecté un transfert de contrôle non valide. |
| 11 | La vérification de la protection d’écriture a détecté une écriture mémoire non valide. |
| 12 | Tentative de basculement vers un contexte fibre non valide. |
| 13 | Une tentative a été faite pour assigner un contexte de Registre non valide. |
| 14 | Le nombre de références d’un objet n’est pas valide. |
| 18 | Tentative de basculement vers un contexte mp_buf non valide. |
| 19 | Une modification non sécurisée a été apportée aux données en lecture seule. |
| 20 | Échec d’un auto-test de chiffrement. |
| 21 | Une chaîne d’exception non valide a été détectée. |
| 22 | Une erreur de bibliothèque de chiffrement s’est produite. |
| 23 | Un appel non valide a été effectué à partir de DllMain. |
| 24 | Une adresse de base d’image non valide a été détectée. |
| 25 | Une défaillance irrécupérable s’est produite lors de la protection d’une importation de charge différée. |
| 26 | Un appel a été effectué sur une extension non sécurisée. |
| 27 | Un service déconseillé a été appelé. |
| 28 | Un accès à un tampon hors limites a été détecté. |
| 29 | Une entrée de RTL_BALANCED_NODE RBTree a été endommagée. |
| 37 | Une entrée de commutateur jumptable hors de portée a été appelée. |
| 38 | Une longjmp a été tentée vers une cible non valide. |
| 39 | Une cible d’appel supprimée par l’exportation n’a pas pu devenir une cible d’appel valide. |
Cause
En utilisant le tableau de paramètres 1 et un fichier de vidage, il est possible de réduire la cause de nombreuses erreurs de ce type.
La corruption de LIST_ENTRY peut être difficile à localiser, et cette erreur indique qu’une incohérence a été introduite dans une liste doublement chaînée (détectée lorsqu’un élément individuel d’une entrée de liste est ajouté ou supprimé de la liste). Malheureusement, l’incohérence n’est pas nécessairement détectée au moment où la corruption s’est produite, donc un travail de détective peut être nécessaire pour identifier la cause racine.
Les causes courantes de corruption de l’entrée de liste incluent :
- Un pilote a corrompu un objet de synchronisation du noyau, tel qu’un KEVENT (par exemple, double initialisation d’un KEVENT alors qu’un thread attendait toujours sur ce même KEVENT, ou permettre à un KEVENT basé sur la pile de sortir de l’étendue tandis qu’un autre thread utilisait ce KEVENT). Ce type d’erreur se produit généralement dans le code nt!Ke* ou nt!Ki*. Cela peut se produire lorsqu’un thread termine d’attendre un objet de synchronisation ou lorsque le code tente de mettre un objet de synchronisation dans l’état signalé. Habituellement, l’objet de synchronisation signalé est celui qui a été corrompu. Parfois, le Driver Verifier avec pool spécial peut aider à localiser le coupable (si l’objet de synchronisation corrompu se trouve dans un bloc de pool qui a déjà été libéré).
- Un pilote a corrompu un KTIMER périodique. Ce type d’erreur se produit généralement dans le code nt!Ke* ou nt!Ki* et implique de signaler un minuteur, ou d’insérer ou de supprimer un minuteur d’une table de minuteurs. Le minuteur manipulé peut être celui qui est corrompu, mais il pourrait être nécessaire d’inspecter la table des minuteurs avec !timer (ou en parcourant manuellement les liens de la liste des minuteurs) pour identifier quel minuteur a été corrompu. Parfois, le Driver Verifier avec pool spécial peut aider à localiser le coupable (si le KTIMER corrompu se trouve dans un bloc de pool qui a déjà été libéré).
- Un pilote a mal géré une liste chaînée de type LIST_ENTRY interne. Un exemple typique serait d’appeler RemoveEntryList deux fois sur la même entrée de liste sans réinsérer l’entrée de liste entre les deux appels RemoveEntryList. D’autres variations sont possibles, comme l’insertion double d’une entrée dans la même liste.
- Un pilote a libéré une structure de données contenant un LIST_ENTRY sans retirer la structure de données de sa liste correspondante, entraînant la détection de la corruption plus tard lorsque la liste est examinée après que l’ancien bloc de pool a été réutilisé.
- Un pilote a utilisé une liste de type LIST_ENTRY de manière concurrente sans synchronisation adéquate, entraînant une mise à jour partielle de la liste.
Dans la plupart des cas, vous pouvez identifier la structure de données corrompue en parcourant la liste chaînée dans les deux sens (les commandes dl et dlb sont utiles à cet effet) et en comparant les résultats. Là où la liste est incohérente entre une traversée avant et arrière est généralement l’emplacement de la corruption. Étant donné qu’une opération de mise à jour de la liste chaînée peut modifier les liens de liste d’un élément voisin, vous devriez examiner de près les voisins d’une entrée de liste corrompue, car ils pourraient être les coupables sous-jacents.
Parce que de nombreux composants système utilisent en interne des listes LIST_ENTRY, divers types de mauvaise gestion des ressources par un pilote utilisant des API système pourraient causer une corruption de la liste chaînée dans une liste chaînée gérée par le système.
Résolution
Déterminer la cause de ce problème nécessite généralement l’utilisation du débogueur pour recueillir des informations supplémentaires. Plusieurs fichiers de vidage doivent être examinés pour voir si ce code d’arrêt présente des caractéristiques similaires, telles que le code en cours d’exécution lorsque le code d’arrêt apparaît.
Pour plus d’informations, veuillez consulter la section Analyse des vidages sur incident en utilisant les débogueurs Windows (WinDbg), Utilisation de l’extension !analyze et !analyze.
Utilisez le journal des événements pour voir s’il y a des événements de niveau supérieur qui se produisent avant ce code d’arrêt.
Ces conseils généraux de dépannage peuvent être utiles.
Si vous avez récemment ajouté du matériel au système, essayez de le supprimer ou de le remplacer. Sinon, contactez le fabricant pour savoir si des correctifs sont disponibles.
Si de nouveaux pilotes de périphériques ou services système ont été ajoutés récemment, essayez de les supprimer ou de les mettre à jour. Essayez de déterminer ce qui a changé dans le système pour que le nouveau code de vérification des bogues apparaisse.
Vérifiez le journal système dans l’Observateur d’événements pour d’autres messages d’erreur qui pourraient aider à identifier le périphérique ou le pilote à l’origine de l’erreur. Pour plus d’informations, veuillez consulter la section Ouvrir l’Observateur d’événements. Recherchez dans le journal système des erreurs critiques qui se sont produites dans la même fenêtre temporelle que l’écran bleu.
Regardez dans le Gestionnaire de périphériques pour voir si des appareils sont marqués d’un point d’exclamation (!). Passez en revue le journal des événements affiché dans les propriétés du pilote pour tout pilote défaillant. Essayez de mettre à jour le pilote associé.
Exécutez un programme de détection de virus. Les virus peuvent infecter tous les types de disques durs formatés pour Windows, et la corruption résultante des disques peut générer des codes de vérification des bogues du système. Assurez-vous que le programme de détection de virus vérifie le Master Boot Record pour les infections.
Pour davantage d’informations concernant le dépannage, veuillez consulter la section Analyser les données d’écran bleu de vérification des bogues.
Voir aussi
Analyse des dumps de crash à l’aide des débogueurs Windows (WinDbg)