Freigeben über

Fehlerüberprüfung 0x139: KERNEL_SECURITY_CHECK_FAILURE

Die KERNEL_SECURITY_CHECK_FAILURE Fehlerüberprüfung hat einen Wert von 0x00000139 und gibt an, dass der Kernel die Beschädigung einer kritischen Datenstruktur erkennt.

Von Bedeutung

Dieser Artikel richtet sich an Programmierer. Wenn Sie ein Kunde sind, der während der Verwendung Ihres Computers einen Bluescreen-Fehlercode empfängt, lesen Sie " Problembehandlung bei Bluescreen-Fehlern".

Bug Check 0x139 KERNEL_SECURITY_CHECK_FAILURE Parameter

Parameter BESCHREIBUNG
1 Die Art der Korruption. Weitere Informationen finden Sie in der folgenden Tabelle.
2 Adresse des Trap-Frames 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 wird überlauft (Legacy-/GS-Verletzung).
1 Der VTGuard-Instrumentierungscode hat einen Versuch erkannt, eine ungültige virtuelle Funktionstabelle zu verwenden. In der Regel ist ein C++-Objekt beschädigt, und dann versucht ein virtueller Methodenaufruf, den zeiger dieses beschädigte Objekt zu verwenden.
2 Der Code für die Instrumentierung von Stack-Cookies hat einen stapelbasierten Pufferüberlauf (/GS-Verstoß) erkannt.
3 Ein LIST_ENTRY ist beschädigt (z. B. eine doppelte Entfernung). 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 schwerwiegend betrachtet.
6 Der Ladeprogramm initialisiert das Cookie für die Stapelcookies nicht ordnungsgemäß. Diese Fehlerüberprüfung wird dadurch verursacht, dass ein Treiber nur unter Windows 8 ausgeführt wird und versucht, das Treiberimage in einer früheren Version von Windows zu laden. Um das Problem zu vermeiden, müssen Sie den Treiber für die Ausführung auf einer früheren Version von Windows erstellen.
7 Ein fatales Beenden des Programms wurde angefordert.
8 Eine vom Compiler eingefügte Array-Begrenzungsprüfung hat einen unzulässigen Arrayindizierungsvorgang erkannt.
9 Es wurde ein Aufruf von RtlQueryRegistryValues ausgeführt, der RTL_QUERY_REGISTRY_DIRECT ohne RTL_QUERY_REGISTRY_TYPECHECK angibt und der Zielwert nicht in einer vertrauenswürdigen Systemstruktur enthalten war.
10 Indirekte Call-Guard-Prüfung erkannte ungültige Steuerübertragung.
11 Die Schreibschutzprüfung hat einen ungültigen Schreibvorgang im Speicher erkannt.
12 Es wurde versucht, auf einen ungültigen Fiber-Kontext umzuschalten.
13 Es wurde versucht, einen ungültigen Registerkontext zuzuweisen.
14 Die Referenzanzahl für ein Objekt ist ungültig.
18 Es wurde versucht, in einen 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 Es wurde eine ungültige Ausnahmekette erkannt.
22 Ein Fehler in der kryptografischen Bibliothek ist aufgetreten.
23 Es wurde ein ungültiger Aufruf in DllMain ausgeführt.
24 Es wurde eine ungültige Image-Basisadresse erkannt.
25 Beim Schutz eines verzögerten Lastimports ist ein nicht behebbarer Fehler aufgetreten.
26 Es wurde eine unsichere Nebenstelle angerufen.
27 Ein veralteter Dienst wurde aufgerufen.
28 Es wurde ein Pufferzugriff außerhalb des zulässigen Bereichs festgestellt.
29 Ein RTL_BALANCED_NODE RBTree-Eintrag ist beschädigt.
37 Es wurde ein Jumptable-Eintrag für den Schalter außerhalb des Bereichs aufgerufen.
38 Es wurde versucht, ein longjmp an ein ungültiges Ziel zu senden.
39 Ein exportiertes unterdrücktes Anrufziel konnte nicht zu einem gültigen Anrufziel gemacht werden.

Ursache

Mithilfe der Tabelle "Parameter 1" und einer Speicherabbilddatei können Sie die Ursache für viele Fehlerüberprüfungen dieses Typs einschränken.

LIST_ENTRY Korruption kann schwer auffindbar sein. Diese Fehlerüberprüfung gibt an, dass eine Inkonsistenz in eine doubly 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, so dass 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. ein KEVENT-Objekt doppelt initialisieren, während ein Thread noch auf dasselbe KEVENT wartete, oder ein stapelbasiertes KEVENT außerhalb des Gültigkeitsbereichs zuzulassen, während ein anderer Thread dieses KEVENT verwendet hat). Diese Art der Fehlerprüfung tritt typischerweise in nt! Ke* oder nt! Ki*-Code. Dies kann passieren, wenn ein Thread das Warten auf ein Synchronisierungsobjekt beendet oder wenn Code versucht, ein Synchronisierungsobjekt in den signalisierten Zustand zu versetzen. In der Regel ist das signalisierte Synchronisierungsobjekt das, das beschädigt ist. Manchmal kann Driver Verifier mit speziellem Pool helfen, den Schuldigen nachzuverfolgen (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 typischerweise in nt! Ke* oder nt! Ki*-Code und beinhaltet das Signalisieren eines Timers oder das Einfügen oder Entfernen eines Timers aus einer Timer-Tabelle. Der zu bearbeitende Zeitgeber ist möglicherweise die beschädigte, aber es kann erforderlich sein, die Zeitgebertabelle mit !timer (oder manuell zu durchlaufen die Zeitgeberlistenlinks) zu überprüfen, um zu ermitteln, welcher Timer beschädigt ist. Manchmal kann Driver Verifier mit speziellem Pool helfen, den Schuldigen nachzuverfolgen (wenn sich der beschädigte KTIMER in einem Poolblock befindet, der bereits freigegeben wurde).
  • Ein Treiber hat eine interne verknüpfte Liste im LIST_ENTRY-Stil falsch verwaltet. Ein typisches Beispiel wäre das zweimalige Aufrufen von RemoveEntryList für denselben Listeneintrag, ohne den Listeneintrag zwischen den beiden RemoveEntryList-Aufrufen erneut einzufügen. Andere Variationen sind möglich, wie z.B. das doppelte Einfügen eines Eintrags in dieselbe Liste.
  • Ein Treiber hat eine Datenstruktur freigegeben, die eine LIST_ENTRY enthält, ohne die Datenstruktur aus der entsprechenden Liste zu entfernen, wodurch später Beschädigungen erkannt werden, wenn die Liste nach dem erneuten Wiederverwenden des alten Poolblocks untersucht wird.
  • Ein Treiber hat eine LIST_ENTRY-Formatvorlagenliste gleichzeitig ohne ordnungsgemäße Synchronisierung verwendet, was zu einer Tornaktualisierung in der Liste führt.

In den meisten Fällen können Sie die beschädigte Datenstruktur identifizieren, indem Sie die verknüpfte Liste sowohl vorwärts als auch rückwärts durchlaufen (die Befehle dl und dlb sind zu diesem Zweck nützlich) und die Ergebnisse vergleichen. Wo die Liste zwischen einem Vorwärts- und einem Rückwärtsgang inkonsistent ist, ist in der Regel der Ort der Beschädigung. Da ein Aktualisierungsvorgang für verknüpfte Listen die Listenverknüpfungen eines benachbarten Elements ändern kann, sollten Sie sich die Nachbarn eines beschädigten Listeneintrags genau ansehen, da sie möglicherweise der zugrunde liegende Schuldige sind.

Da viele Systemkomponenten intern LIST_ENTRY Listen verwenden, können verschiedene Arten der Ressourcenmismanagement 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.

Beschluss

Für die Ermittlung der Ursache von Problemen mit listeneingabebeschädigungen ist in der Regel die Verwendung des Debuggers erforderlich, um andere Informationen zu sammeln. Es sollten mehrere Dumpdateien untersucht werden, um festzustellen, ob der Stoppcode ähnliche Merkmale aufweist, z. B. den Code, der ausgeführt wird, wenn der Stoppcode angezeigt wird.

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

Verwenden Sie das Ereignisprotokoll, um festzustellen, ob Ereignisse auf höherer Ebene auftreten, die bis zum 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 im System geändert wurde, was dazu führte, dass der neue Fehlerüberprüfungscode angezeigt wurde.

  • Überprüfen Sie das Systemprotokoll in der Ereignisanzeige auf andere Fehlermeldungen, die dazu beitragen können, das Gerät oder den Treiber zu bestimmen, das den Fehler verursacht. Suchen Sie im Systemprotokoll nach kritischen Fehlern, die in demselben Zeitfenster wie der Bluescreen aufgetreten sind.

  • Überprüfen Sie im Geräte-Manager , ob Geräte mit dem Ausrufezeichen (!) gekennzeichnet sind. Überprüfen Sie das Ereignisprotokoll, das in den Treibereigenschaften für fehlerhafte 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 daraus resultierende Datenträgerbeschädigungen können Systemfehlerüberprüfungscodes generieren. Stellen Sie sicher, dass das Virenerkennungsprogramm den Master Boot Record auf Infektionen überprüft.

  • Allgemeine Informationen zur Problembehandlung finden Sie unter "Analysieren von Fehlerüberprüfungs-Bluescreen-Daten".

Siehe auch

Absturzabbildanalyse mit den Windows-Debuggern (WinDbg)

Analysieren einer Kernel-Mode Dump-Datei mit WinDbg

  • Last updated on