Fehlerüberprüfung 0x139: KERNEL_SECURITY_CHECK_FAILURE
Die KERNEL_SECURITY_CHECK_FAILURE-Fehlerüberprüfung hat einen Wert von 0x00000139. Diese Fehlerüberprüfung gibt an, dass der Kernel die Beschädigung einer kritischen Datenstruktur festgestellt hat.
Wichtig
Dieser Artikel richtet sich an Programmierer*innen. Wenn Sie ein/eine Kund*in sind, der/die einen Bluescreen-Fehlercode bei der Benutzung eines Computers erhalten hat, lesen Sie bitte Fehlerbehebung bei Bluescreen-Fehlern.
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 Fehlerüberprüfung verursacht hat |
| 3 | Die Adresse des Ausnahmedatensatzes für die Ausnahme, die die Fehlerüberprüfung verursacht hat |
| 4 | Reserved |
In der folgenden Tabelle sind die möglichen Werte für Parameter 1 beschrieben.
| Parameter 1 | Beschreibung |
|---|---|
| 0 | Ein stapelbasierter Puffer wurde überlaufen (Legacy-/GS-Verletzung). |
| 1 | Der VTGuard-Instrumentierungscode hat versucht, eine unzulässige virtuelle Funktionstabelle zu verwenden. In der Regel wurde ein C++-Objekt beschädigt, und dann wurde versucht, diesen Zeiger des beschädigten Objekts des zu verwenden. |
| 2 | Der Stack-Cookie-Instrumentierungscode hat einen stapelbasierten Pufferüberlauf (/GS-Verstoß) erkannt. |
| 3 | Ein LIST_ENTRY wurde beschädigt (z. B. eine doppelte Entfernung). Weitere Informationen finden Sie im folgenden Abschnitt "Grund". |
| 4 | Reserved |
| 5 | Ein ungültiger Parameter wurde an eine Funktion übergeben, die ungültige Parameter als schwerwiegend betrachtet. |
| 6 | Der Stapelcookies-Sicherheitscookies wurde vom Ladeprogramm nicht ordnungsgemäß initialisiert. Dies kann dazu führen, dass ein Treiber nur unter Windows 8 ausgeführt wird und versucht wird, das Treiberimage in einer früheren Version von Windows zu laden. Um dieses Problem zu vermeiden, müssen Sie den Treiber für die Ausführung auf einer früheren Version von Windows erstellen. |
| 7 | Es wurde ein schwerwiegender Programmausgang angefordert. |
| 8 | Eine vom Compiler eingefügte Array-Begrenzungsprüfung hat einen unzulässigen Arrayindizierungsvorgang erkannt. |
| 9 | Ein Aufruf von RtlQueryRegistryValues wurde ausgeführt, um RTL_QUERY_REGISTRY_DIRECT ohne RTL_QUERY_REGISTRY_TYPECHECK anzugeben, und der Zielwert war nicht in einer vertrauenswürdigen Systemstruktur enthalten. |
| 10 | Die indirekte Aufrufschutzüberprüfung hat eine ungültige Steuerelementübertragung erkannt |
| 11 | Schreibschutzüberprüfung hat einen ungültigen Speicherschreibvorgang festgestellt. |
| 12 | Es wurde versucht, zu einem ungültigen Fiberkontext zu wechseln. |
| 13 | Es wurde versucht, einen ungültigen Registerkontext zuzuweisen. |
| 14 | Der Referenzzähler 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 Modifikation an schreibgeschützten Daten vorgenommen. |
| 20 | Scheitern eines kryptografischen Selbsttest. |
| 21 | Eine ungültige Ausnahmekette wurde erkannt. |
| 22 | Ein kryptografischer Bibliotheksfehler ist aufgetreten. |
| 23 | Aus DIIMain wurde ein ungültiger Aufruf getätigt. |
| 24 | Es wurde eine ungültige Imagebasisadresse erkannt. |
| 25 | Beim Schützen eines verzögerten Ladeimports ist ein nicht behebbarer Fehler aufgetreten. |
| 26 | Es wurde ein Aufruf an eine unsichere Erweiterung durchgeführt. |
| 27 | Ein veralteter Dienst wurde aufgerufen. |
| 28 | Es wurde ein nicht begrenzter Pufferzugriff erkannt. |
| 29 | Ein RTL_BALANCED_NODE RBTree-Eintrag wurde beschädigt. |
| 37 | Ein Tauschsprungtabelleneintrag außerhalb des Bereichs wurde aufgerufen. |
| 38 | Ein longjmp wurde zu einem ungültigen Ziel versucht. |
| 39 | Ein Export unterdrücktes Aufrufziel konnte nicht als gültiges Aufrufziel festgelegt werden. |
Ursache
Mithilfe der Tabelle "Parameter 1" und einer Speicherabbilddatei ist es möglich, die Ursache für viele Fehlerüberprüfungen dieses Typs einzugrenzen.
LIST_ENTRY Beschädigung kann schwierig nachzuverfolgen sein und diese Fehlerüberprüfung weist darauf hin, 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 zu dem Zeitpunkt, zu dem die Beschädigung aufgetreten ist, nicht unbedingt erkannt, so dass einige detektivische Arbeit erforderlich sein kann, um die Ursache zu identifizieren.
Häufige Ursachen für Die Beschädigung des Listeneintrags 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 von Fehlerüberprüfung tritt in der Regel 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 Objekt, das beschädigt wurde. 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 von Fehlerüberprüfung tritt in der Regel in nt! Ke* oder nt! Ki*-Code und beinhaltet das Signalisieren eines Timers oder das Einfügen oder Entfernen eines Timers aus einer Zeitgebertabelle. Der zu bearbeitende Zeitgeber ist möglicherweise die beschädigte, aber es kann erforderlich sein, die Timer-Tabelle mit !timer (oder manuell zu durchlaufen die Timer-Listenlinks) zu überprüfen, um zu ermitteln, welcher Timer beschädigt wurde. Manchmal kann Driver Verifier mit speziellem Pool dabei helfen, den Übeltäter aufzuspüren (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, dass RemoveEntryList zweimal in demselben Listeneintrag aufgerufen wird, ohne den Listeneintrag zwischen den beiden RemoveEntryList-Aufrufen erneut aufzurufen. Andere Variationen sind möglich, 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 der Wiederverwendung des alten Poolblocks untersucht wird.
- Ein Treiber hat eine liste im LIST_ENTRY-Format ohne ordnungsgemäße Synchronisierung gleichzeitig 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 für diesen Zweck nützlich) und die Ergebnisse zu vergleichen. Wenn die Liste zwischen vorwärts und rückwärts inkonsistent ist, ist dies in der Regel der Ort der Beschädigung. Da ein Vorgang zum Aktualisieren verknüpfter Listen die Listenverknüpfungen 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, verknüpfte Listenbeschädigungen in einer vom System verwalteten verknüpften Liste verursachen.
Lösung
Für die Ermittlung der Ursache dieser Probleme ist in der Regel die Verwendung des Debuggers erforderlich, um zusätzliche Informationen zu sammeln. Es sollten mehrere Speicherabbilddateien untersucht werden, um festzustellen, ob dieser 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 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 herauszufinden, welche Änderungen im System zur Anzeige des neuen Fehlerprüfcodes geführt haben.
Überprüfen Sie das Systemprotokoll in der Ereignisanzeige auf weitere Fehlermeldungen, die Ihnen helfen können, das Gerät oder den Treiber zu finden, das/der den Fehler verursacht. Weitere Informationen finden Sie unter Öffnen der Ereignisanzeige. Suchen Sie im Systemprotokoll nach kritischen Fehlern, die in demselben Zeitfenster wie der Bluescreen aufgetreten sind.
Prüfen Sie im Geräte-Manager, ob Geräte mit dem Ausrufezeichen (!) gekennzeichnet sind. Überprüfen Sie das Ereignisprotokoll, das in den Eigenschaften 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 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.
Weitere allgemeine Informationen zur Fehlerbehebung finden Sie unter Analysieren von Fehlerüberprüfungs-Bluescreen-Daten.