Bluescreen: Stoppcode lesen, Ursache finden

Ein Bluescreen ist Windows, das die Notbremse zieht. Danach wahllos den Arbeitsspeicher zu tauschen, ist, als würdest du den Zug auswechseln, weil die Bremse funktioniert hat. Dieser Guide liest zuerst die Beweise und gibt Geld zuletzt aus.

Die Kurzantwort

Wie findest du die Ursache eines Bluescreens? Notiere den Stoppcode, stelle sicher, dass Windows eine Dump-Datei speichert, öffne dann die neuesten Dumps in WinDbg und führe !analyze -v aus. Microsofts eigene Auswertung von Abstürzen führt etwa 70 Prozent auf Treibercode von Drittanbietern zurück, 10 Prozent auf Hardware, 5 Prozent auf Microsoft-Code und 15 Prozent auf Fälle, in denen der Speicher zu beschädigt war, um etwas zu erkennen [1]. Aktualisiere oder entferne also zuerst Treiber, teste danach Speicher und Datenträger und kaufe ein Teil erst, wenn ein Test den Defekt zeigt.

So funktioniert’s

1. Was ein Stoppcode ist. Stößt Windows auf einen Zustand, der das System oder deine Daten gefährden könnte, hält es absichtlich an. Microsoft nennt das Bug Check, Stoppfehler oder Kernelfehler [1]. Der Bildschirm zeigt einen Namen wie PAGE_FAULT_IN_NONPAGED_AREA oder MEMORY_MANAGEMENT und, falls vorhanden, das Modul, das gerade lief [15]. Zu jedem Code gehören vier Parameter. Der Name verrät die Art des Fehlers, nicht das Teil, das kaputt ist. Bei 0xD1, DRIVER_IRQL_NOT_LESS_OR_EQUAL, sagt Microsoft: Ein Kernel-Mode-Treiber hat auf auslagerbaren Speicher zugegriffen, während die Interrupt-Ebene des Prozessors zu hoch war, meist über eine falsche Adresse [13]. Ein Anwenderprogramm wie Notepad kann einen Absturz auslösen, ist aber selten die eigentliche Ursache [1].
2. Aufschreiben und in den Protokollen finden. Fotografiere den Bildschirm. Öffne in der Ereignisanzeige „Windows-Protokolle“ und dann „System“. Ereignis-ID 1001 von WER-SystemErrorReporting meldet, dass der Computer nach einem Bug Check neu gestartet ist, und nennt Code und Dump-Pfad. Ereignis-ID 41 von Kernel-Power meldet einen Neustart ohne sauberes Herunterfahren [8]. Ereignis 41 trägt den Bug-Check-Code dezimal; Microsofts Beispiel zeigt 159, das entspricht 0x9F [7]. Ein unsauberes Herunterfahren steht außerdem als Ereignis-ID 6008 im Protokoll [8]. Zeigt Ereignis 41 den Code null oder fehlt ganz, verweist Microsoft auf die Stromversorgung: ein gezogener Stecker am Desktop, ein leerer Akku oder ein zu schwaches oder defektes Netzteil [7].
3. Dafür sorgen, dass Dumps entstehen. Ein Rechner, der keinen Dump schreibt, hinterlässt keine Beweise. Öffne „Erweiterte Systemeinstellungen“, dann „Starten und Wiederherstellen“, und wähle unter „Debuginformationen speichern“ den automatischen Speicherabbild-Typ (Automatic memory dump) [1]. Kleine Dumps landen in %SystemRoot%\Minidump, die größeren Arten in %SystemRoot%\MEMORY.DMP [1]. Ein kleiner Dump ist winzig; Microsofts Seiten nennen 256 KB [1] und 64 KB [11]. Der Dump läuft über die Auslagerungsdatei, und für ein vollständiges Speicherabbild verlangt Microsoft eine ausreichende Auslagerungsdatei auf dem Startvolume [16]. Halte 10 bis 15 Prozent des Systemlaufwerks frei [1][15]. Bewahre mehrere Dumps auf. Ein Dump kann in die Irre führen; dasselbe Muster in dreien ist eine Spur.
4. Herausfinden, wann es anfing. Die Zuverlässigkeitsüberwachung zeichnet eine Zeitleiste der Fehler pro Tag. Starte sie mit perfmon /rel [9][10]. Vergleiche den ersten roten Eintrag mit Treiberinstallationen, Windows-Updates und Hardwareänderungen. Ereignis-ID 19 von WindowsUpdateClient markiert installierte Updates [8].
5. Zuerst die letzte Änderung rückgängig machen. Vor jeder Debugger-Arbeit gilt Microsofts allgemeine Liste [1][6][15]. Entferne Hardware, die du kurz vor dem ersten Absturz eingebaut hast. Starte im abgesicherten Modus, wenn Windows nicht bootet (er lädt nur das Minimum an Treibern [6]). Suche im Geräte-Manager nach Geräten mit Ausrufezeichen. Installiere Windows-Updates und die neueste BIOS- oder UEFI-Firmware. Setze einen frisch aktualisierten Treiber zurück oder nutze einen Wiederherstellungspunkt. Starte einen Malware-Scan, zum Beispiel mit dem Microsoft Safety Scanner [1].
6. Den Dump in WinDbg öffnen. Microsofts Weg: Kopiere den Dump auf einen anderen Rechner und installiere die Debugging Tools for Windows aus dem Windows SDK [1]. Kopiere die Dateien zuerst aus dem Ordner Minidump; zum Lesen brauchst du Administratorrechte. Setze in WinDbg die Symbole mit .symfix, das auf Microsofts öffentlichen Symbolserver zeigt, und führe dann .reload aus [5]. Symbole machen aus Adressen Namen; ohne sie sagt die Analyse wenig. Öffne die Datei über „File“ und „Open Crash Dump“ (Strg+D) [2]. Führe !analyze -v aus [2][3]. .bugcheck zeigt den Code mit seinen Parametern, lm listet die geladenen Module [2].
7. Die Ausgabe lesen. !analyze beginnt mit dem Namen des Bug Checks und einem kurzen Text, danach folgen Arg1 bis Arg4 mit je einer Beschreibung [4]. Weiter unten findest du MODULE_NAME und IMAGE_NAME, das Modul, das der Debugger beschuldigt, sowie STACK_TEXT, die Kette der Aufrufe [4]. Microsoft rät selbst, in STACK_TEXT nach der beteiligten DLL oder dem Dienst zu suchen [1]. Deine Ausgabe kann mehr Schlüssel zeigen als das Beispiel der Dokumentation. Wie wählt der Debugger den Namen? Er läuft den Stack von oben durch und beschuldigt den ersten Frame, dessen Besitzer er bestimmen kann [4]. Das ist eine Faustregel, kein Urteil. Zwei Beispiele von Microsoft zeigen, wie verschieden die Lösungen sind. Im einen zeigte der Stack auf den Windows-Firewall-Dienst, und das Zurücksetzen der Firewall-Richtlinien half. Im anderen saß ein D1-Absturz in NDIS.sys, einem Microsoft-Treiber, den du nicht entfernen kannst; die Lösung war, das Netzwerkgerät zu deaktivieren und das Upgrade erneut zu versuchen [1]. Bei 0xD1 gibt der Befehl dx KiBugCheckDriver den Treibernamen aus, den Windows gespeichert hat [13].
8. Warum ntoskrnl.exe selten der Täter ist. Microsoft führt nur etwa 5 Prozent der Abstürze auf Microsoft-Code zurück [1]. Der Kernel taucht oft auf, weil er das Problem bemerkt hat, nicht weil er es verursacht hat. Bei manchen MEMORY_MANAGEMENT-Fällen schreibt Microsoft ausdrücklich, der aufrufende Stack könne „Opfer oder Täter“ sein (im Original: „might be either a victim or a culprit“) [12]. Unsere Einschätzung: Nennt der Dump ntoskrnl.exe, behandle das Ergebnis als nicht zugeordnet. Installiere Windows nicht wegen dieses Dateinamens neu. Suche im Stack nach anderen Modulen, vergleiche mit deinen anderen Dumps und geh zum Driver Verifier über.
9. Driver Verifier. Das eingebaute Werkzeug stellt Treiber unter strenge Prüfung. Ein Treiber, der Speicher beschädigt, stürzt dann im Moment der Tat ab, und der nächste Dump nennt ihn [1]. Microsofts Warnungen: Es braucht viel CPU und kann den PC stark bremsen, es kann zusätzliche Abstürze und viele Dump-Dateien verursachen, du solltest nicht alle Treiber auf einmal prüfen, und Gruppen von 10 bis 20 Treibern gelten als Richtwert. Beginne mit kürzlich aktualisierten oder verdächtigen Treibern. Erreicht der PC den Desktop nicht mehr, starte im abgesicherten Modus, in dem Verifier nicht läuft [1]. Unser Rat: Lege vorher einen Wiederherstellungspunkt an und schalte Verifier aus, sobald du die Dumps hast. Dieselbe Microsoft-Seite nennt an anderer Stelle etwa 75 Prozent der Stoppfehler durch fehlerhafte Treiber, die Hauptstatistik sagt 70 Prozent [1]. Beide Zahlen sagen dasselbe: zuerst die Treiber.
10. Treiber, Speicher, Datenträger oder Strom? Mehrere Dumps mit demselben Code und demselben Drittanbieter-Modul weisen auf diesen Treiber. Codes und Module, die von Absturz zu Absturz wechseln, passen eher zu Hardware, und Microsoft hält fest, dass Hardwareprobleme erratisches, unvorhersehbares Verhalten auslösen und schwer zu diagnostizieren sind [1]. Die Tabelle unten sammelt, was Microsoft zu häufigen Codes schreibt.
11. Hardware nur testen, wenn die Beweise dorthin zeigen. Für den Arbeitsspeicher startest du die Windows-Speicherdiagnose (suche nach „Computerarbeitsspeicher auf Probleme überprüfen“). Danach zeigt die Ereignisanzeige das Ergebnis im System-Protokoll unter MemoryDiagnostics-Results [6]. Unsere Einschätzung: Ein sauberer Durchlauf ist ein Indiz, kein Beweis. Stürzt der PC weiter ab, teste ein Speichermodul nach dem anderen. Fürs Dateisystem nennt Microsoft chkdsk /f /r [1] und für Systemdateien SFC /scannow [6]. Bei Laufwerken meldet PowerShells Get-PhysicalDisk einen HealthStatus von Healthy, Warning, Unhealthy oder Unknown [18], und Get-PhysicalDisk | Get-StorageReliabilityCounter zeigt Temperatur, Fehler und Verschleiß [17]. Nicht jeder Datenträger meldet diese Werte [19]. Laut Microsofts Beispiel gilt jedes Laufwerk, das Lese- oder Schreibfehler meldet, als gefährdet [19]. Für SMART-Werte im Detail lies den Guide zur SSD-Gesundheit unter „Passt dazu“. Starte außerdem die Diagnose deines PC-Herstellers [6].
12. Wenn ein Teil wirklich defekt ist. Gib Geld nur für ein Teil aus, bei dem ein wiederholbarer Test das Ergebnis liefert: Speicherfehler in der Diagnose, Lese- oder Schreibfehler in den Laufwerkszählern, ein WHEA-Fehler, der bleibt, nachdem du Übertaktung abgeschaltet und die Kühlung geprüft hast. Sichere deine Daten, bevor du ein Laufwerk tauschst. Zeigt nichts einen Defekt, ist ein neues Teil geraten, und geraten wird oft doppelt teuer. Wir nennen in diesem Guide keine Shops.
13. Wenn du Hilfe brauchst. Sammle den Stoppcode mit allen vier Parametern, die neuesten Dump-Dateien, den Text von Ereignis 1001, die Liste aus lm t n [13] und alles, was du vor dem ersten Absturz geändert hast. Auch der Microsoft-Support bittet um ein Speicherabbild, um einen Fall zu beschleunigen [16].

Was Microsoft zu häufigen Stoppcodes schreibt

Ein Homelab-Beispiel

Das hier ist eine allgemeine Anleitung für deinen eigenen Windows-PC und kein Bericht über unsere Systeme. Zahlen und Namen in der Beispielausgabe sind erfunden, und wir haben diese Befehle nicht ausgeführt.

Schritt eins: Liste die Ereignisse zu unsauberen Neustarts auf und kopiere die Dumps in einen Ordner, den du lesen kannst.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1001,6008} -MaxEvents 20 |
  Format-List TimeCreated, Id, ProviderName, Message
New-Item -ItemType Directory "$HOME\Desktop\dumps" -Force
Copy-Item C:\Windows\Minidump\*.dmp "$HOME\Desktop\dumps\"

Schritt zwei: Öffne in WinDbg einen Dump mit Strg+D und führe nacheinander diese Befehle aus.

.symfix C:\Symbols
.reload
!analyze -v
.bugcheck
lm t n

Stell dir diesen Ausschnitt der Ausgabe vor (erfundene Werte):

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arg1: 0000000000000010, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80123456789, address which referenced memory
MODULE_NAME: examplegfx
IMAGE_NAME:  examplegfx.sys

So liest du ihn: Der Code ist 0xD1, also ist ein Treiber beteiligt [13]. Die genannte Datei examplegfx.sys stammt von einem Drittanbieter, das passt zu Microsofts 70 Prozent [1]. Öffne die beiden anderen Dumps. Nennen sie dieselbe Datei, aktualisiere den Treiber oder setze ihn zurück, lass den PC eine Woche laufen und sieh dir die Zuverlässigkeitsüberwachung noch einmal an. Nennen die anderen Dumps andere Dateien und andere Codes, höre auf, den Treiber zu verdächtigen. Starte die Speicherdiagnose und die Laufwerksprüfungen aus Schritt 11 und achte in Ereignis 41 auf Hinweise zur Stromversorgung.

Prüfliste

• Fotografiere den Bluescreen und schreibe den Stoppcode mit seinen vier Parametern auf.
• Prüfe, dass „Starten und Wiederherstellen“ ein automatisches Speicherabbild schreibt und das Systemlaufwerk 10 bis 15 Prozent frei hat.
• Kopiere die Dateien aus C:\Windows\Minidump in einen lesbaren Ordner, bevor du sie analysierst.
• Öffne die Zuverlässigkeitsüberwachung mit perfmon /rel und notiere das Datum des ersten Absturzes.
• Mache die letzte Treiber-, Update- oder Hardwareänderung rückgängig, bevor du tiefer testest.
• Setze die Symbole mit .symfix, führe !analyze -v auf mindestens drei Dumps aus und vergleiche die Modulnamen.
• Behandle ntoskrnl.exe als „nicht zugeordnet“ und sieh dir den Rest des Stacks an.
• Nutze den Driver Verifier nur für eine kleine Gruppe verdächtiger Treiber und mit einem Wiederherstellungspunkt.
• Führe die Windows-Speicherdiagnose und chkdsk /f /r aus und lies die Laufwerkszähler, bevor du ein Teil verdächtigst.
• Tausche ein Teil nur, wenn ein wiederholbarer Test den Defekt zeigt, und sichere vorher deine Daten.

Passt dazu

SSD-Gesundheit: SMART unter Windows und Linux · Arbeitsspeicher / RAM · NVMe-SSDs verstehen · Hardwarekonfiguration eindeutig dokumentieren · USV – unterbrechungsfreie Stromversorgung · Stoppcode (Bugcheck) · S.M.A.R.T.: Laufwerksgesundheit