Stoppcode (Bugcheck)

Windows ist gerade umgekippt und hat einen Zettel hinterlassen. Lies den Zettel, bevor du den RAM verdächtigst.

Kurz gesagt

Ein Stoppcode, auch Bugcheck-Code genannt, erscheint, wenn Windows anhält, weil ein Weiterlaufen das Betriebssystem oder deine Daten beschädigen könnte [1][5]. Dazu gehören vier Parameter [2]. Der Code nennt die Art des Fehlers, etwa 0xD1 für DRIVER_IRQL_NOT_LESS_OR_EQUAL, aber nicht den Verursacher [3][4]. Unsere Einschätzung: Notiere Code, Modulnamen und Parameter und nimm sie als Startpunkt der Suche, nicht als Urteil.

So funktioniert’s

1. Warum Windows anhält. Trifft das System auf einen Zustand, der den sicheren Betrieb gefährdet, hält es an. Microsoft nennt das Bugcheck, außerdem Systemabsturz, Kernelfehler oder Stoppfehler [1][5].
2. Was der Bildschirm zeigt. Den Stoppcode-Fehler und, falls verfügbar, den Modulnamen des gerade laufenden Codes, zum Beispiel eine Treiberdatei mit der Endung .sys [1]. Jeder Code hat einen Hex-Wert und einen symbolischen Namen. 0x0000000A ist IRQL_NOT_LESS_OR_EQUAL, 0x0000009F ist DRIVER_POWER_STATE_FAILURE [3].
3. Vier Parameter. Ihre Bedeutung ist je Code verschieden und steht in der Referenz. Du findest sie im Systemprotokoll der Ereignisanzeige, mit !analyze auf einer Dump-Datei oder über einen angeschlossenen Kerneldebugger [2]. Bei 0xD1 sind es der angesprochene Speicher, die IRQL zu diesem Zeitpunkt, ob gelesen (0), geschrieben (1) oder ausgeführt (2 oder 8) wurde, und die Adresse des Codes, der den Speicher berührt hat [4].
4. Wahrscheinliche Ursachen. Microsofts Auswertung von Abstürzen: 70 % Treibercode von Drittanbietern, 10 % Hardware, 5 % Microsoft-Code und 15 % unbekannt, weil der Speicher zu stark beschädigt war. Ein Anwenderprogramm wie Notepad ist selten die Wurzel [5]. Für 0xD1 schreibt die Seite, die Ursache zu finden brauche den Debugger und den Quellcode, und meist stecke ein Treiber mit falschen Speicheradressen dahinter [4].
5. Dump-Dateien. Unter „Starten und Wiederherstellen“ entscheidet „Debuginformationen schreiben“, was gespeichert wird. Ein kleiner Speicherabbild landet in %SystemRoot%\Minidump, die größeren Arten in %SystemRoot%\MEMORY.DMP [5]. Nennt ein Debugger einen Treiber, zeigt ihn dx KiBugCheckDriver [4].

Ein Praxisbeispiel

Microsofts Dokumentation zeigt diese Beispielausgabe für 0xD1 [4]. Die Werte stammen aus der Doku und nicht aus einem Absturz bei uns:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arg1: fffff808add27150, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808adc386a6, address which referenced memory

So liest du das: Ein Treiber hat auf auslagerbaren Speicher zugegriffen, während die IRQL bei 2 (DISPATCH_LEVEL) lag, und das ist dafür zu hoch. Die Seite ergänzt, dass in den meisten dieser Fälle der Speicher das Problem ist und nicht die IRQL [4]. Die nächsten Schritte brauchen keinen Debugger: Installiere Windows- und BIOS-Updates, aktualisiere den genannten Treiber oder setze ihn zurück und lass Hardware und Arbeitsspeicher testen [5][1].

Prüfliste

• Notiere den Stoppcode, den Modulnamen und aus der Ereignisanzeige die vier Parameter [1][2].
• Suche nach dem genauen Code und vergleiche die Parameter mit der Referenz [3][4].
• Prüfe, ob Dumps entstehen: Stelle „Automatisches Speicherabbild“ ein und sieh in %SystemRoot%\Minidump nach [5].
• Installiere die neuesten Windows-Updates und aktualisiere BIOS und Firmware [5].
• Aktualisiere den Treiber, den der Bildschirm nennt, oder setze ihn zurück, und mache neue Hardware- oder Treiberänderungen rückgängig [1][5].
• Starte die Windows-Speicherdiagnose und lies das Ergebnis in der Ereignisanzeige [1]. Prüfe auch dein Laufwerk; siehe unseren Eintrag zu S.M.A.R.T.
• Lass 10 bis 15 Prozent der Platte frei, wie Microsoft es empfiehlt [5].
• Ändere immer nur eine Sache und notiere Datum und Ergebnis.