0x139 de vérification des bogues : KERNEL_SECURITY_CHECK_FAILURE

Article
06/20/2023

La valeur du bogue KERNEL_SECURITY_CHECK_FAILURE case activée est 0x00000139. Ce bogue case activée indique que le noyau a détecté l’altération d’une structure de données critique.

Important

Cet article s’adresse 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.

Paramètres de 0x139 KERNEL_SECURITY_CHECK_FAILURE de vérification des bogues

Paramètre	Description
1	Type d’altération. Pour plus d’informations, consultez le tableau suivant.
2	Adresse du cadre d’interruption pour l’exception qui a provoqué le bogue case activée
3	Adresse de l’enregistrement d’exception pour l’exception qui a provoqué le bogue case activée
4	Réservé

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

Paramètre 1	Description
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 virtuelles illégale. En règle générale, un objet C++ a été endommagé, puis un appel de méthode virtuelle a été tenté à l’aide du pointeur de l’objet endommagé.
2	Le code d’instrumentation des cookies de pile a détecté un dépassement de mémoire tampon basée sur la pile (/violation GS).
3	Une LIST_ENTRY a été endommagée (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é passé à une fonction qui considère les paramètres non valides comme irrécupérables.
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 pour qu’il 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 de programme irrécupérable a été demandée.
8	Une limite de tableau case activée insérée par le compilateur a détecté une opération d’indexation de tableau non valide.
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 approuvée.
10	La protection des appels indirects case activée détecté un transfert de contrôle non valide.
11	La protection d’écriture case activée a détecté une écriture de mémoire non valide.
12	Une tentative de basculement vers un contexte fibre non valide a été effectuée.
13	Une tentative d’affectation d’un contexte de registre non valide a été effectuée.
14	Le nombre de références pour un objet n’est pas valide.
18	Une tentative de basculement vers un contexte de jmp_buf non valide a été effectuée.
19	Une modification non sécurisée a été apportée aux données en lecture seule.
20	Un auto-test de chiffrement a échoué.
21	Une chaîne d’exceptions 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	Un échec irrécupérable a été rencontré lors de la protection d’une importation de charge différée.
26	Un appel a été effectué pour une extension non sécurisée.
27	Un service déconseillé a été appelé.
28	Un accès à la mémoire tampon hors limites a été détecté.
29	Une entrée RBTree RTL_BALANCED_NODE a été endommagée.
37	Une entrée sautable de commutateur hors de portée a été appelée.
38	Un longjmp a été tenté vers une cible non valide.
39	Une cible d’appel supprimée d’exportation n’a pas pu être une cible d’appel valide.

Cause

À l’aide de la table du paramètre 1 et d’un fichier de vidage, il est possible de limiter la cause de nombreuses vérifications de bogues de ce type.

LIST_ENTRY corruption peut être difficile à localiser et ce bogue case activée, indique qu’une incohérence a été introduite dans une liste doublement lié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, donc un travail de détective peut être nécessaire pour identifier la cause racine.

Les causes courantes de l’altération de l’entrée de liste sont les suivantes :

Un pilote a endommagé un objet de synchronisation de noyau, tel qu’un objet KEVENT (par exemple, la double initialisation d’un objet KEVENT alors qu’un thread attendait toujours ce même KEVENT, ou l’autorisation d’un KEVENT basé sur une pile à sortir de l’étendue pendant qu’un autre thread utilisait ce KEVENT). Ce type de bogue case activée 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 placer un objet de synchronisation à l’état signalé. En règle générale, l’objet de synchronisation signalé est celui qui a été endommagé. Parfois, Driver Verifier avec un pool spécial peut aider à localiser le coupable (si l’objet de synchronisation endommagé se trouve dans un bloc de pool qui a déjà été libéré).
Un pilote a endommagé un KTIMER périodique. Ce type de bogue case activée se produit généralement dans nt ! Ke* ou nt ! Ki* code et implique la signalisation d’un minuteur ou l’insertion ou la suppression d’un minuteur d’une table de minuteur. Le minuteur manipulé peut être endommagé, mais il peut être nécessaire d’inspecter la table du minuteur avec !timer (ou de parcourir manuellement les liens de liste du minuteur) pour identifier le minuteur qui a été endommagé. Parfois, Driver Verifier avec un pool spécial peut aider à localiser le coupable (si le KTIMER endommagé se trouve dans un bloc de pool qui a déjà été libéré).
Un pilote a mal géré une liste liée interne de style LIST_ENTRY. Un exemple classique 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, telles que la double insertion 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 d’une corruption ultérieurement lorsque la liste est examinée 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 entraîne une mise à jour déchirée de la liste.

Dans la plupart des cas, vous pouvez identifier la structure de données endommagée en parcourant la liste liée vers l’avant et vers l’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 est généralement l’emplacement de l’altération. É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 attentivement les voisins d’une entrée de liste endommagée, car ils peuvent être le coupable sous-jacent.

Étant donné que de nombreux composants système utilisent LIST_ENTRY listes en interne, différents types de gestion incorrecte des ressources par un pilote à l’aide d’API système peuvent provoquer une altération des listes liées dans une liste liée gérée par le système.

Résolution

La détermination de 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 qui s’exécute 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 existe des événements de niveau supérieur qui se produisent jusqu’à 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 qui a provoqué l’apparition du nouveau bogue case activée code.
Vérifiez l’observateur d'événements du journal système pour obtenir des messages d’erreur supplémentaires susceptibles d’aider à identifier le périphérique ou le pilote à l’origine de l’erreur. Pour plus d’informations, consultez Ouvrir 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.
Recherchez dans Gestionnaire de périphériques pour voir si des appareils sont marqués avec le 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 mis en forme pour Windows, et l’altération du disque qui en résulte peut générer un bogue système case activée codes. Assurez-vous que le programme de détection de virus vérifie la présence d’infections dans l’enregistrement de démarrage principal.
Pour plus d’informations générales sur la résolution des problèmes, consultez Données écran bleu.

Voir aussi

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

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