Fehlerüberprüfung 0x109: CRITICAL_STRUCTURE_CORRUPTION
Die CRITICAL_STRUCTURE_CORRUPTION Fehlerüberprüfung weist den Wert 0x00000109 auf. Dies gibt an, dass der Kernel kritischen Kernelcode oder Datenbeschädigung erkannt 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.
CRITICAL_STRUCTURE_CORRUPTION-Parameter
| Parameter | Beschreibung |
|---|---|
1 |
Reserved |
2 |
Reserved |
3 |
Reserviert |
4 |
Der Typ des beschädigten Bereichs. (Siehe die folgende Tabelle weiter unten auf dieser Seite.) |
Der Wert von Parameter 4 gibt den Typ des beschädigten Bereichs an.
| Parameter 4 | Typ der beschädigten Region, Typ der Beschädigung oder Art der ausgeführten Aktion, die die Beschädigung verursacht hat |
|---|---|
0x0 |
Eine generische Datenregion |
0x1 |
Eine Änderungsfunktionen |
0x2 |
Eine Interrupt Dispatch Table (IDT) des Prozessors |
0x3 |
Eine globale Prozessordeskriptortabelle (GDT) |
0x4 |
Eine Typ-1-Prozesslistenbeschädigung |
0x5 |
Eine Typ-2-Prozesslistenbeschädigung |
0x6 |
Eine Debugroutineänderung |
0x7 |
Eine kritische MSR-Änderung |
0x8 |
Objekttyp |
0x9 |
Ein Prozessor-IVT |
0xA |
Änderung einer Systemdienstfunktion |
0xB |
Eine generische Sitzungsdatenregion |
0xC |
Änderung einer Sitzungsfunktion oder .pdata |
0xD |
Änderung einer Importtabelle |
0xE |
Änderung einer Sitzungsimporttabelle |
0xF |
Ps Win32 Legendenänderung |
0x10 |
Änderung der Debug-Switch-Routine |
0x11 |
Änderung der IRP-Allocator |
0x12 |
Änderung der Treiberanrufweiterleitung |
0x13 |
Änderung des IRP-Verteiler-Verteilers |
0x14 |
Änderung der IRP-Dellocator |
0x15 |
Eine Prozessorsteuerungsregister (PCR) |
0x16 |
Änderung kritischer Gleitkommasteuerungsregister |
0x17 |
Lokale APIC-Änderung |
0x18 |
Kernelbenachrichtigungsbeschriftungsänderung |
0x19 |
Änderung der geladenen Modulliste |
0x1A |
Typ-3-Prozesslistenbeschädigung |
0x1B |
Typ-4-Prozesslistenbeschädigung |
0x1C |
Treiberobjektbeschädigung |
0x1D |
Änderung des Geschäftsleitungsrückrufobjekts |
0x1E |
Änderung des Modulabstands |
0x1F |
Änderung eines geschützten Prozesses |
0x20 |
Eine generische Datenregion |
0x21 |
Ein Seitenhashkonflikt |
0x22 |
Eine Konfliktübereinstimmung zwischen Sitzungsseitenhash |
0x23 |
Konfigurationsverzeichnisänderung laden |
0x24 |
Invertierte Funktionstabellenänderung |
0x25 |
Änderung der Sitzungskonfiguration |
0x26 |
Ein erweitertes Prozessorsteuerungsregister |
0x27 |
Typ 1 Poolbeschädigung |
0x28 |
Typ 2 Poolbeschädigung |
0x29 |
Typ 3 Poolbeschädigung |
0x101 |
Allgemeine Poolbeschädigung |
0x102 |
Änderung der win32k.sys |
Ursache
Für diese Fehlerüberprüfung gibt es im Allgemeinen drei verschiedene Ursachen:
Ein Treiber hat versehentlich oder absichtlich kritischen Kernelcode oder Daten geändert. Microsoft Windows Server 2003 mit Service Pack 1 (SP1) und höheren Versionen von Windows für x64-basierten Computern erlauben nicht, dass der Kernel gepatcht wird, außer über autorisierte von Microsoft stammende Hot Patches.
Ein Entwickler hat versucht, einen normalen Kernel-Haltepunkt mithilfe eines Kerneldebuggers festzulegen, der beim Starten des Systems nicht angefügt wurde. Normale Haltepunkte (bp) können nur festgelegt werden, wenn der Debugger zur Startzeit angefügt ist. Prozessor-Haltepunkte (ba) können jederzeit festgelegt werden.
Es ist eine Hardwarebeschädigung aufgetreten. Der Kernelcode oder die Daten konnten beispielsweise im Speicher gespeichert werden, der fehlgeschlagen ist.
Lösung
Die !analyze Debugerweiterung zeigt Informationen zur Fehlerüberprüfung an und kann bei der Ermittlung der Ursache hilfreich sein.
Untersuchen Sie zunächst den Stapelüberwachungsbericht mit dem Befehl k, kb, kc, kd, kp, kP, kv (Display Stack Backtrace). Sie können die Prozessornummer angeben, um die Stapel aller Prozessoren zu untersuchen.
Sie können im Code, der zu diesem Stoppcode führt, auch einen Haltepunkt setzen und versuchen, in einzelnen Schritten vorwärts in den fehlerhaften Code zu gelangen.
Weitere Informationen finden Sie in den folgenden Themen:
Absturzabbildanalyse mit den Windows-Debuggern (WinDbg)
Wenn Sie nicht mit dem Windows-Debugger für die Arbeit an diesem Problem ausgestattet sind, können Sie einige grundlegende Problembehandlungstechniken verwenden.
Überprüfen Sie das Systemprotokoll in der Ereignisanzeige auf weitere Fehlermeldungen, die Ihnen helfen könnten, das Gerät oder den Treiber zu identifizieren, das bzw. der die Fehlerüberprüfung verursacht.
Wenn in der Fehlerüberprüfungsmeldung ein Treiber angegeben ist, deaktivieren Sie den Treiber oder erkundigen Sie sich beim Hersteller nach Treiberupdates.
Führen Sie das Windows-Speicherdiagnosetool aus, um den Arbeitsspeicher zu testen. Geben Sie im Suchfeld der Systemsteuerung Speicher ein, und wählen Sie dann Speicherprobleme Ihres Computers diagnostizieren aus. Nachdem der Test ausgeführt wurde, verwenden Sie die Ereignisanzeige, um die Ergebnisse im Systemprotokoll anzuzeigen. Suchen Sie nach dem Eintrag MemoryDiagnostics-Results, um die Ergebnisse anzuzeigen.
Sie können versuchen, die vom Systemhersteller bereitgestellte Hardwarediagnose auszuführen.
Bestätigen Sie, dass die neu installierte Hardware mit der installierten Windows-Version kompatibel ist. Informationen zur benötigten Hardware finden Sie beispielsweise unter Windows 10-Spezifikationen.
Weitere allgemeine Informationen zur Fehlerbehebung finden Sie unter Analysieren von Fehlerüberprüfungs-Bluescreen-Daten.