Fehlerprüfung 0x139: KERNEL_SECURITY_CHECK_FAILURE

Artikel
10/26/2023

Die KERNEL_SECURITY_CHECK_FAILURE-Fehlerüberprüfung weist den Wert 0x00000139 auf. Diese Fehlerprüfung gibt an, dass der Kernel die Beschädigung einer kritischen Datenstruktur erkannt hat.

Wichtig

Dieser Artikel richtet sich an Programmierer. Wenn Sie ein Kunde sind, der während der Verwendung Ihres Computers einen Bluescreen-Fehlercode erhalten hat, finden Sie weitere Informationen unter Behandeln von Bluescreenfehlern.

Fehlerüberprüfung 0x139 KERNEL_SECURITY_CHECK_FAILURE Parameter

Parameter	BESCHREIBUNG
1	Die Art der Beschädigung. Ausführlichere Informationen finden Sie in der unten stehenden Tabelle.
2	Adresse des Trapframes für die Ausnahme, die die Fehlerprüfung verursacht hat
3	Adresse des Ausnahmedatensatzes für die Ausnahme, die die Fehlerprüfung verursacht hat
4	Reserviert

In der folgenden Tabelle werden mögliche Werte für Parameter 1 beschrieben.

Parameter 1	BESCHREIBUNG
0	Ein stapelbasierter Puffer wurde überlaufen (Legacyverletzung von /GS).
1	Der VTGuard-Instrumentierungscode hat einen Versuch erkannt, eine ungültige virtuelle Funktionstabelle zu verwenden. In der Regel wurde ein C++-Objekt beschädigt, und dann wurde versucht, mithilfe des Zeigers des beschädigten Objekts einen aufruf der virtuellen Methode zu verwenden.
2	Der Stapelcookiesinstrumentierungscode hat einen stapelbasierten Pufferüberlauf (/GS-Verletzung) erkannt.
3	Ein LIST_ENTRY wurde beschädigt (z. B. ein doppeltes Entfernen). Weitere Informationen finden Sie im folgenden Abschnitt Ursache.
4	Reserviert
5	Ein ungültiger Parameter wurde an eine Funktion übergeben, die ungültige Parameter als fatal betrachtet.
6	Das Sicherheitscookies des Stapelcookies wurde vom Ladeprogramm nicht ordnungsgemäß initialisiert. Dies kann darauf zurückzuführen sein, dass ein Treiber erstellt wird, der nur auf Windows 8 ausgeführt wird, und der Versuch, das Treiberimage unter einer früheren Version von Windows zu laden. Um dieses Problem zu vermeiden, müssen Sie den Treiber so erstellen, dass er unter einer früheren Version von Windows ausgeführt wird.
7	Ein schwerwiegender Programmausgang wurde angefordert.
8	Bei einer vom Compiler eingefügten Arraybegrenzungsprüfung wurde ein unzulässiger Arrayindizierungsvorgang erkannt.
9	Ein Aufruf von RtlQueryRegistryValues wurde durchgeführt, indem RTL_QUERY_REGISTRY_DIRECT ohne RTL_QUERY_REGISTRY_TYPECHECK angegeben wurde, und der Zielwert befand sich nicht in einer vertrauenswürdigen Systemstruktur.
10	Bei der Überprüfung des indirekten Call Guards wurde eine ungültige Steuerungsübertragung erkannt.
11	Bei der Schreibschutzprüfung wurde ein ungültiger Speicherschreibvorgang erkannt.
12	Es wurde versucht, zu einem ungültigen Fiberkontext zu wechseln.
13	Es wurde versucht, einen ungültigen Registerkontext zuzuweisen.
14	Die Verweisanzahl für ein Objekt ist ungültig.
18	Es wurde versucht, zu einem ungültigen jmp_buf Kontext zu wechseln.
19	Es wurde eine unsichere Änderung an schreibgeschützten Daten vorgenommen.
20	Ein kryptografischer Selbsttest ist fehlgeschlagen.
21	Eine ungültige Ausnahmekette wurde erkannt.
22	Ein Kryptografiebibliotheksfehler ist aufgetreten.
23	In DllMain wurde ein ungültiger Aufruf durchgeführt.
24	Eine ungültige Imagebasisadresse wurde erkannt.
25	Beim Schutz eines verzögerten Ladevorgangs ist ein nicht behebbarer Fehler aufgetreten.
26	Es wurde eine unsichere Erweiterung aufgerufen.
27	Ein veralteter Dienst wurde aufgerufen.
28	Ein Pufferzugriff außerhalb der Grenzen wurde erkannt.
29	Ein RTL_BALANCED_NODE RBTree-Eintrag wurde beschädigt.
37	Ein Sprungbretteintrag außerhalb des Bereichs wurde aufgerufen.
38	Ein longjmp wurde versucht, ein ungültiges Ziel zu erreichen.
39	Ein exportunterdrücktes Aufrufziel konnte nicht zu einem gültigen Aufrufziel gemacht werden.

Ursache

Mithilfe der Tabelle des Parameters 1 und einer Speicherabbilddatei kann die Ursache für viele Fehlerüberprüfungen dieses Typs eingegrenzt werden.

LIST_ENTRY Beschädigung kann schwierig auffindbar sein, und diese Fehlerprüfung gibt an, dass eine Inkonsistenz in eine doppelt verknüpfte Liste eingeführt wurde (erkannt, wenn ein einzelnes Listeneintragselement zur Liste hinzugefügt oder daraus entfernt wird). Leider wird die Inkonsistenz nicht unbedingt zu dem Zeitpunkt erkannt, zu dem die Beschädigung aufgetreten ist, sodass einige Detektivarbeit erforderlich sein kann, um die Ursache zu identifizieren.

Häufige Ursachen für Die Beschädigung von Listeneinträgen sind:

Ein Treiber hat ein Kernelsynchronisierungsobjekt beschädigt, z. B. ein KEVENT (z. B. eine doppelte Initialisierung eines KEVENTs, während ein Thread noch auf dasselbe KEVENT wartete, oder zulassen, dass ein stapelbasiertes KEVENT aus dem Gültigkeitsbereich wechselt, während ein anderer Thread dieses KEVENT verwendet). Diese Art der Fehlerprüfung tritt in der Regel in nt! auf. Ke* oder nt! Ki*-Code. Dies kann vorkommen, wenn ein Thread nicht mehr auf ein Synchronisierungsobjekt wartet oder code versucht, ein Synchronisierungsobjekt in den signalierten Zustand zu versetzen. Normalerweise ist das Synchronisierungsobjekt, das signalisiert wird, das beschädigt wurde. Manchmal kann driver verifier mit einem speziellen Pool helfen, den Täter zu finden (wenn sich das beschädigte Synchronisierungsobjekt in einem poolblock befindet, der bereits freigegeben wurde).
Ein Treiber hat einen regelmäßigen KTIMER beschädigt. Diese Art der Fehlerprüfung tritt in der Regel in nt! auf. Ke* oder nt! Ki*-Code und umfasst das Signalisieren eines Timers oder das Einfügen oder Entfernen eines Timers aus einer Zeitgebertabelle. Der timer, der bearbeitet wird, kann beschädigt sein, aber es kann erforderlich sein, die Zeitgebertabelle mit !timer zu überprüfen (oder manuell die Timerlistenlinks zu durchlaufen), um zu ermitteln, welcher Timer beschädigt wurde. Manchmal kann driver verifier mit einem speziellen Pool helfen, den Täter aufzuspüren (wenn sich die beschädigte KTIMER in einem poolblock befindet, der bereits freigegeben wurde).
Ein Treiber hat eine interne LIST_ENTRY verknüpfte Liste falsch verwaltet. Ein typisches Beispiel wäre das Zweimale Aufrufen von RemoveEntryList für denselben Listeneintrag, ohne den Listeneintrag zwischen den beiden RemoveEntryList-Aufrufen wiederhergestellt zu haben. Andere Varianten sind möglich, z. B. das doppelte Einfügen eines Eintrags in die gleiche Liste.
Ein Treiber hat eine Datenstruktur freigegeben, die eine LIST_ENTRY enthält, ohne die Datenstruktur aus der entsprechenden Liste zu entfernen, sodass eine Beschädigung später erkannt wird, wenn die Liste nach der Wiederverwendung des alten Poolblocks überprüft wird.
Ein Treiber hat eine liste im LIST_ENTRY-Format gleichzeitig ohne ordnungsgemäße Synchronisierung verwendet, was zu einer gerissenen Aktualisierung der Liste führte.

In den meisten Fällen können Sie die beschädigte Datenstruktur identifizieren, indem Sie die verknüpfte Liste vorwärts und rückwärts durchlaufen (die Befehle dl und dlb sind für diesen Zweck nützlich) und die Ergebnisse vergleichen. Wenn die Liste zwischen vorwärts und rückwärts inkonsistent ist, ist in der Regel der Ort der Beschädigung. Da ein Vorgang zum Aktualisieren einer verknüpften Liste die Listenlinks eines benachbarten Elements ändern kann, sollten Sie die Nachbarn eines beschädigten Listeneintrags genau betrachten, da sie möglicherweise der zugrunde liegende Schuldige sind.

Da viele Systemkomponenten intern LIST_ENTRY Listen verwenden, können verschiedene Arten von Ressourcenfehlern durch einen Treiber, der System-APIs verwendet, zu einer Beschädigung der verknüpften Liste in einer vom System verwalteten verknüpften Liste führen.

Lösung

Die Ermittlung der Ursache dieser Probleme erfordert in der Regel die Verwendung des Debuggers, um zusätzliche Informationen zu sammeln. Mehrere Speicherabbilddateien sollten untersucht werden, um festzustellen, ob dieser Stoppcode ähnliche Merkmale aufweist, z. B. der Code, der ausgeführt wird, wenn der Stoppcode angezeigt wird.

Weitere Informationen finden Sie unter Absturzabbildanalyse mit den Windows-Debuggern (WinDbg),Verwenden der Erweiterung !analyze und !analyze.

Verwenden Sie das Ereignisprotokoll, um festzustellen, ob Ereignisse höherer Ebene auftreten, die zu diesem Stoppcode führen.

Diese allgemeinen Tipps zur Problembehandlung können hilfreich sein.

Wenn Sie dem System kürzlich Hardware hinzugefügt haben, versuchen Sie, diese zu entfernen oder zu ersetzen. Oder erkundigen Sie sich beim Hersteller, ob Patches verfügbar sind.
Wenn kürzlich neue Gerätetreiber oder Systemdienste hinzugefügt wurden, versuchen Sie, diese zu entfernen oder zu aktualisieren. Versuchen Sie zu ermitteln, was sich im System geändert hat, wodurch der neue Fehlerprüfungscode angezeigt wurde.
Überprüfen Sie die system log in Ereignisanzeige auf zusätzliche Fehlermeldungen, die dazu beitragen können, das Gerät oder den Treiber zu ermitteln, das den Fehler verursacht. Weitere Informationen finden Sie unter Open Ereignisanzeige. Suchen Sie im Systemprotokoll nach kritischen Fehlern, die in demselben Zeitfenster wie der Bluescreen aufgetreten sind.
Sehen Sie sich in Geräte-Manager an, ob Geräte mit dem Ausrufezeichen (!) gekennzeichnet sind. Überprüfen Sie das ereignisprotokoll, das in den Treibereigenschaften für jeden fehlerhaften Treiber angezeigt wird. Versuchen Sie, den entsprechenden Treiber zu aktualisieren.
Führen Sie ein Virenerkennungsprogramm aus. Viren können alle Arten von Festplatten, die für Windows formatiert sind, infizieren, und die daraus resultierende Datenträgerbeschädigung kann zu Systemfehlerüberprüfungscodes führen. Stellen Sie sicher, dass das Virenerkennungsprogramm den Master boot Record auf Infektionen überprüft.
Weitere allgemeine Informationen zur Problembehandlung finden Sie unter Bluescreen-Daten.

Siehe auch

Absturzabbildanalyse mithilfe der Windows-Debugger (WinDbg)

Analysieren einer Kernel-Mode-Speicherabbilddatei mit WinDbg

Share via