Wissensdatenbank →6 Min. LesezeitAktualisiert: 2026-09-21

So beheben Sie KERNEL SECURITY CHECK FAILURE in Windows 11

KERNEL_SECURITY_CHECK_FAILURE mit Stoppcode 0x00000139 wirft Windows selbst aus, wenn eine Struktur, auf die sich der Kern verlässt, eine interne Konsistenzprüfung nicht besteht — das System hat seine eigene Buchhaltung verdorben vorgefunden und weigert sich, darauf weiterzulaufen. Der Name klingt dramatisch, die Ursachen sind banal: instabiler Speicher ganz vorn, ein fehlerhafter Treiber, der Kerndaten überschreibt, als Zweiter, beschädigte Systemdateien als Dritter. Genau in dieser Reihenfolge — Speicher, Dateien, Treiber — klären Sie die überwiegende Mehrheit der Rechner.

Was die Sicherheitsprüfung misslingt

Der Kernel führt Prüfsummen und Invarianten über seine kritischen Datenstrukturen — ungefähr wie eine Bank, die ihre Bücher mehrmals pro Sekunde abgleicht. Stoppcode 0x139 heißt: Einer dieser Abgleiche ging schief — ein Listenzeiger zeigt nicht mehr dorthin, wo er muss, oder ein Puffer-Header passt nicht mehr zu seinem Inhalt. Windows hält absichtlich an, denn mit verdorbenem Kernelzustand weiterzulaufen riskiert, Müll über die ganze Platte zu schreiben.

Was diese Strukturen verdirbt, ist selten geheimnisvoll. Speicher, der unter Last Bits kippt — meist ein XMP/EXPO-Profil jenseits dessen, was der Speichercontroller wirklich aushält —, führt die Liste an. Treiber, die außerhalb ihrer Puffer schreiben, folgen als Zweite, wobei Grafik- und Antiviren-Treiber die Rückfälligen sind. Beschädigte Systemdateien und eine sterbende SSD, die beim Lesen verdorbene Daten liefert, runden die Liste ab.

  • Instabiler RAM — XMP/EXPO-Profile jenseits dessen, was der Speichercontroller der CPU wirklich aushält
  • Ein fehlerhafter Treiber, der außerhalb seines Puffers schreibt — Grafik-, Antiviren- und Virtualisierungstreiber sind Rückfällige
  • Durch ein fehlgeschlagenes Update oder einen plötzlichen Stromausfall beschädigte Systemdateien
  • Eine sterbende SSD, die beim Lesen verdorbene Daten liefert — in den SMART-Attributen sichtbar
  • Aggressives Undervolting oder Übertakten, das unter Last Bits kippt

Speicher prüfen und Dateien reparieren

Beginnen Sie mit dem Speicher: Er ist die häufigste Ursache und die billigste, die sich ausschließen lässt. Starten Sie mdsched.exe, lassen Sie nach dem Neustart den Standarddurchlauf laufen; das Urteil erscheint in der Ereignisanzeige unter Windows-Protokolle → System, Quelle MemoryDiagnostics-Results. Der Standardlauf fängt nur grobe Fehler ein — halten die Abstürze bei sauberem Ergebnis an, schalten Sie XMP/EXPO im BIOS ab und testen Sie die Riegel einzeln, bevor Sie den Speicher entlasten.

Die Dateien kommen als Nächstes, aus dem „Terminal (Administrator)“: sfc /scannow gleicht geschützte Dateien mit dem Komponentenspeicher ab, dann repariert DISM /Online /Cleanup-Image /RestoreHealth den Speicher selbst, falls SFC nicht alles fixen konnte, und chkdsk C: /f /r überstreicht beim nächsten Neustart die Plattenoberfläche. Eine saubere Neuinstallation des Grafiktreibers rundet die Softwareseite ab — neuestes Paket laden, das alte unter Einstellungen → Apps → Installierte Apps entfernen und nach dem Neustart frisch installieren.

Den Wiederholungstäter eingrenzen

Überlebt der Stoppcode all das, ist der Absturz spezifisch genug für einen Namen. Die Minidumps in C:\Windows\Minidump tragen die Fehleradresse und die Liste geladener Module; WinDbg mit !analyze -v oder ein Leseprogramm wie BlueScreenView macht daraus einen Treibernamen, und dieser Name beendet die Jagd. Software, die in den Tagen vor dem ersten Absturz installiert wurde, verdient die erste Befragung — die Deinstallation ist Test und Therapie zugleich.

Das Werkzeug des letzten Zufluchts ist der Driver Verifier (verifier /standard /all aus der Admin-Konsole), der verdächtige Treiber laut und sofort über ihre eigenen Bugs stolpern lässt. Er ist absichtlich gefährlich: Rechnen Sie mit Bluescreens, solange er läuft, und merken Sie sich den Ausgang — in den abgesicherten Modus starten und verifier /reset ausführen, um ihn abzuschalten. So geführt, treibt Verifier einen versteckten Treiber binnen ein, zwei Tage ans Licht.

Fragen und Antworten

Ist KERNEL_SECURITY_CHECK_FAILURE ein Zeichen für Schadsoftware?

Selten. Die Prüfung fängt Beschädigung, nicht Befall, und die Ursachen liegen fast immer an Hardware und Treibern. Ein Daten verdorbender Rootkit ist möglich, aber weit unten auf der Liste.

Kann defekter RAM KERNEL_SECURITY_CHECK_FAILURE auslösen?

Ja — er ist die häufigste Einzelursache. Zuerst mdsched.exe, dann XMP/EXPO abschalten und die Riegel einzeln testen, wenn die Abstürze nicht aufhören.

Wie stoppe ich KERNEL_SECURITY_CHECK_FAILURE beim Start?

Booten Sie über WinRE in den abgesicherten Modus (Starteinstellungen → Taste 4), deinstallieren Sie, was zuletzt kam, und lassen Sie SFC und DISM von dort laufen — der Absturz folgt selten hinein.

Vor dem Kauf genau wissen, was enthalten ist.

Der einmalige 30-Minuten-Test umfasst Basisfunktionen. PRO-markierte Werkzeuge bleiben bis zur Aktivierung einer kostenpflichtigen Lizenz gesperrt.

Weiterlesen

Alle Artikel · FAQ

Schreiben Sie uns: [email protected]