Bug Check 0x139 : KERNEL_SECURITY_CHECK_FAILURE

La KERNEL_SECURITY_CHECK_FAILURE vérification de bogue a une valeur de 0x00000139. Cette vérification de bogue indique que le noyau a détecté la corruption d’une structure de données critique.

Important

Cet article est destiné aux programmeurs. Si vous êtes un client qui a reçu un code d’erreur d’écran bleu lors de l’utilisation de votre ordinateur, consultez Résoudre les erreurs d’écran bleu.

Vérification des bogues 0x139 KERNEL_SECURITY_CHECK_FAILURE paramètres

Paramètre	Descriptif
1	Le type de corruption. Pour plus d’informations, consultez le tableau suivant.
2	Adresse de la trame d’interruption de l’exception à l’origine de la vérification du bogue
3	Adresse de l’enregistrement d’exception pour l’exception à l’origine de la vérification du bogue
4	Réservé

Le tableau suivant décrit les valeurs possibles pour le paramètre 1.

Paramètre 1	Descriptif
0	Une mémoire tampon basée sur la pile a été dépassée (violation /GS héritée).
1	Le code d’instrumentation VTGuard a détecté une tentative d’utilisation d’une table de fonctions virtuelle illégale. En règle générale, un objet C++ a été corrompu, puis un appel de méthode virtuelle a été tenté à l’aide du pointeur this de l’objet corrompu.
2	Le code d’instrumentation des cookies de pile a détecté un dépassement de la mémoire tampon basée sur la pile (violation /GS).
3	Un LIST_ENTRY a été corrompu (par exemple, une double suppression). Pour plus d’informations, consultez la section Cause suivante.
4	Réservé
5	Un paramètre non valide a été transmis à une fonction qui considère que les paramètres non valides sont fatals.
6	Le cookie de sécurité du cookie de pile n’a pas été correctement initialisé par le chargeur. Cela peut être dû à la création d’un pilote qui s’exécute 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 générer le pilote pour qu’il s’exécute 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 ne se trouvait pas dans une ruche système approuvée.
10	La vérification indirecte du gardien d’appel a détecté un transfert de contrôle non valide.
11	La vérification de la garde d’écriture a détecté une écriture de mémoire non valide.
12	Une tentative a été faite pour passer à un contexte de fibre non valide.
13	Une tentative d’attribution d’un contexte de registre non valide a été effectuée.
14	Le nombre de références d’un objet n’est pas valide.
18	Une tentative a été faite pour passer à un contexte jmp_buf invalide.
19	Une modification non sécurisée a été apportée aux données en lecture seule.
20	Un autotest cryptographique a échoué.
Vingt-et-un	Une chaîne d’exceptions non valide a été détectée.
22	Une erreur de bibliothèque cryptographique s’est produite.
23	Un appel non valide a été effectué à partir de DllMain.
Vingt-quatre	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é passé à un poste non sécurisé.
27	Un service obsolète a été appelé.
28	Un accès à la mémoire tampon hors limites a été détecté.
29	Une RTL_BALANCED_NODE entrée RBTree a été corrompue.
37	Une entrée de table de saut de commutateur hors de portée a été invoquée.
38	Une tentative de longjmp a été effectuée sur une cible non valide.
39	Il n’a pas été possible de transformer une cible d’appel supprimée à l’exportation en une cible d’appel valide.

La cause

À l’aide de la table de paramètres 1 et d’un fichier dump, il est possible d’affiner la cause de nombreuses vérifications de bogues de ce type.

LIST_ENTRY corruption peut être difficile à traquer et cette vérification de bogue indique qu’une incohérence a été introduite dans une liste à double maillée (détectée lorsqu’un élément d’entrée de liste individuel 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, de sorte qu’un travail de détective peut être nécessaire pour identifier la cause profonde.

Les causes courantes de corruption des entrées de liste sont les suivantes :

• Un pilote a corrompu un objet de synchronisation du noyau, tel qu’un KEVENT (par exemple, en initialisant deux fois un KEVENT alors qu’un thread attendait toujours ce même KEVENT, ou en permettant à un KEVENT basé sur une pile de sortir du champ d’application alors qu’un autre thread utilisait ce KEVENT). Ce type de vérification de bogue se produit généralement dans nt ! Ke* ou nt ! Code 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é. En général, l’objet de synchronisation signalé est celui qui a été endommagé. Parfois, le vérificateur de pilotes avec un pool spécial peut aider à traquer 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 de vérification de bogue se produit généralement dans nt ! Ke* ou nt ! Ki* et implique la signalisation d’une minuterie, ou l’insertion ou la suppression d’une minuterie d’une table de minuterie. La minuterie manipulée peut être celle qui est corrompue, mais il peut être nécessaire d’inspecter la table de minuterie avec !timer (ou de parcourir manuellement les liens de la liste des minuteries) pour identifier la minuterie qui a été corrompue. Parfois, un vérificateur de pilote avec un pool spécial peut aider à traquer 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 interne de type LIST_ENTRY. 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 variantes 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 qui contient un LIST_ENTRY sans supprimer la structure de données de sa liste correspondante, ce qui entraîne la détection ultérieure d’une corruption lors de l’examen de la liste après la réutilisation de l’ancien bloc de pool.
• Un pilote a utilisé une liste de style LIST_ENTRY de manière simultanée sans synchronisation appropriée, ce qui a entraîné une mise à jour déchirée de la liste.

Dans la plupart des cas, vous pouvez identifier la structure de données corrompue en parcourant la liste chaînée en avant et en arrière (les commandes dl et dlb sont utiles à cet effet) et en comparant les résultats. Là où la liste est incohérente entre une marche avant et une marche arrière, c’est généralement l’emplacement de la corruption. Étant donné qu’une opération de mise à jour de liste liée peut modifier les liens de liste d’un élément voisin, vous devez examiner de près les voisins d’une entrée de liste corrompue, car ils peuvent être le coupable sous-jacent.

Étant donné 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 peuvent entraîner une corruption de liste chaînée dans une liste chaînée gérée par le système.

Résolution

La détermination de la cause de ces problèmes 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, consultez Analyse du vidage sur incident à l’aide des 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 de dépannage généraux 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 qui a provoqué l’affichage du nouveau code de vérification des bogues.

• Consultez le journal système dans l’Observateur d’événements pour obtenir des messages d’erreur supplémentaires qui peuvent aider à identifier le périphérique ou le pilote à l’origine de l’erreur. 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 périphériques sont marqués d’un point d’exclamation ( !). Examinez le journal des événements affiché dans les propriétés du pilote pour tout pilote défectueux. 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 mis en forme pour Windows, et la corruption de disque résultante peut générer des codes de vérification des bogues système. Assurez-vous que le programme de détection de virus vérifie que le Master Boot Record ne contient pas d’infections.

• Pour plus d’informations générales de dépannage, consultez Analyser les données d’écran bleu de vérification des bogues.

Voir aussi

Analyse du vidage sur incident à l’aide des débogueurs Windows (WinDbg)

Analyse d’un fichier de vidage Kernel-Mode avec WinDbg