Ursachen von Bluescreens aufspüren
Seit Windows XP sind sie seltener geworden, aber auch hier gibt es sie doch noch:
Rätselhafte Systemneustarts oder die blauen Bildschirme, mit denen das Betriebssystem sich für arbeitsunfähig erklärt. Auch der Hinweis „Wenden Sie sich an den Administrator“ hilft nicht weiter, wenn dieses Schicksal den Heim-PC ereilt.
Eigentlich ist so ein Bluescreen nichts Schlechtes: Wenn er erscheint hat das Betriebssystem festgestellt, dass es in einen Zustand geraten ist, in dem ein sicheres Weiterarbeiten nicht mehr möglich ist. Jede weitere Aktion könnte mehr Schaden anrichten, als ein vielleicht seit einer halben Stunde nicht gespeichertes Word-Dokument für den Anwender bedeutet. Um die Hardware und den Inhalt der Festplatte vor Schäden zu bewahren, fährt sich das System in so einem Fall kontrolliert herunter. Ob es den Rechner danach automatisch neu startet oder einen Bluescreen anzeigt und die CPU anhält, kann der Anwender einstellen.
Die zuständigen Optionen verbergen sich in den Systemeinstellungen (Rechtsklick auf „Arbeitsplatz“ dann auf „Eigenschaften“) im Register „Erweitert“. Hier führ ein Klick auf „Einstellungen“ im Bereich „Starten und Wiederherstellen“ auf einen Dialog, dessen Einstellmöglichkeiten im Bereich „Systemfehler“ definieren. Was Windows im Falle eines Komplettabsturzes noch alles unternimmt.
Zur Fehlersuche sind hier 2 Optionen wichtig: „Automatisch Neustart durchführen“ sollte ausgeschalten sein (kein Haken im Kästchen), damit ein Bluescreen nicht sofort wieder verschwindet, dem man unter Umständen noch wertvolle Informationen entnehmen kann. Kommt es dann trotzdem zu plötzlichen reboots, ist in der Regel nicht Windows oder sonst eine Softwarekomponente schuld, sondern es liegt ein Hardwareproblem vor. In Frage kommt zum Beispiel ein Netzteil, das die Versorgungsspannung nicht stabil genug liefert und so einen Reset auslöst.
Zum Aufspüren der Ursache für Bluescreens ist es außerdem wichtig, möglichst genaue Informationen über den Systemzustand zum Zeitpunkt des Absturzes zu haben. Das unter „Debuginformationen speichern“ standardmäßig ausgewählte „Kleine Speicherabbild“ reicht dazu in der Regel nicht aus. Besser ist es hier, ein Kernelspeicherabbild anzufordern. Die Größe einer solchen Datei entspricht etwa einem Drittel der Hauptspeichergröße. Ein „Vollständiges Hauptspeicherabbild“ wird dagegen stets so groß wie der Hauptspeicher (plus einem Megabyte für einen Header und ein paar Verwaltungsinformationen). Dieser zusätzlich belegte Platz zahlt sich aber für die reine Fehlersuche in der Regel nicht aus.
Ob man das Häkchen bei „Vorhandene Dateien überschreiben“ setzt, ist nicht nur Geschmackssache: Fehlt es, legt Windows beim nächsten Absturz nicht etwa ein neues Speicherabbild an, sondern schreib schlicht ein kleines und man hat keine Chance, den Fehler zu analysieren. Ist die Option eingeschaltet, geht beim nächsten Crash eine schon vorhandene und vielleicht noch nicht komplett ausgedeutete Datei verloren. In dem Fall empfiehlt es sich, nach einem BSOD und anschließendem Neustart den Memory-Dump so schnell wie möglich durch Umbenennen oder Verschieben in Sicherheit zu bringen.
Ermittlung
Auch wenn ein Bluescreen reproduzierbar immer im selben Programm auftritt: Die Anwendung selbst kann daran nicht schuld sein – jedenfalls nicht unmittelbar. Unter Windows NT Abkömmling laufen ordinäre Programme nämlich im so genannten User-Mode (auch „Ring 3“ genannt). Sie bekommen einen eigenen virtuellen Adressraum zugewiesen und können nicht auf den Adressraum anderer Anwendungen oder direkt auf die Hardware zugreifen. Wenn in einer Anwendung etwas Gravierendes schief geht, kommt es daher allenfalls zum Absturz dieses einen Programms, was sich ain einer Fehlermeldung der Art „WinBugPro.exe hat ein Problem festgestellt und muss beendet werden“ äußert. Windows selbst läuft in so einem Fall unbeeindruckt weiter.
Ein Betriebssystemabsturz in Form eines Bluescreen kann nur enstehen, wenn Code etwas Illegales tut, der im so genannten Kernel-Mode („Ring 0“) läuft. Dazu gehören Gerätetreiber und der Mikrokernel selbst. Im Ring 0 teilen sich alle Treiber einen gemeinsamen Adressraum und können sich durchaus gegenseitig abschießen.
Um herauszufinden, welche Komponente genau den Fehler verursacht hat, muss man sich den Zustand des Systems unmittelbar vor dem Absturz ansehen. Einige Informationen zeigt schon der Bluescreen selbst: Eine Zeile, die mit „*** STOP“ gefolgt von einer achtstelligen Hexadezimalzahl beginnt, ist auf jedem BSOD zu sehen. Sie liefert einen ersten Hinweis auf die Art des Fehlers – wenn man sie denn zu interpretieren weiß. Manchmal findet sich in der Nähe der STOP-Zeile eine symbolische Beschreibung des Fehlers, etwa IRQL_NOT_LESS_OR_EQUAL oder INACCESSIBLE_BOOT_DEVICE, und damit zumindest einen Anhaltspunkt für eine Google-Suche. Mit etwas Glück enthält der Bluescreen auch einen Hinweis auf eine Datei mit der Endung. Sys. Die ist damit natürlich verdächtig, aber leider noch lange nicht als eindeutig schuldig identifiziert.
Mit den Informationen auf dem Bluescreen selbst kommt man also nicht allzu weit. Ein Blick in das Speicherabbild ist angesagt. Glücklicherweise bietet Microsoft dafür ein geeignetes Werkzeug an: den Debugger WinDbg [1 siehe unten], den Sie über den Softlink herunterladen können.
Die Download-Größe ist mit knapp 9 MByte noch erträglich. Um den Debugge allerdings sinnvoll einsetzen zu können, benötigen Sie noch die so genannten Symboldateien – und die schlagen je nach Windows-Version mit ca. 70 bis 170 MByte zu Buche. Ein Komplett-Download ist aber nicht unbedingt nötig, wenn der Rechner, auf dem Sie die Analyse durchführen wollen (das muss nicht notwendigerweise der von den Abstürzen betroffene sein), mit dem Internet verbunden ist. Dann können Sie nämlich WinDbg so einrichten, dass er immer nur die benötigten Symbole lädt und auf dem Rechner zwischenspeichert. Dazu legen Sie nach der Installation des Debuggers zunächst irgendwo auf der Festplatte ein neues Verzeichnis an.
In WinDbg wählen sie den Menübefehl „File/Symbol File Path“ und tragen in das Eingabefeld die Zeile
SRV*C: \Symbols*http://msdl.microsoft.com/download/symbols ein. Statt „C: \Symbols“ müssen Sie dabei den neuen Ordner angeben; hier wird der Debugger die heruntergeladenen Symboldateien zwischenspeichern.
Ein Speicherabbild lädt WinDbg mit dem Menübefehl „File/Open Crash Dump“. Daraufhin öffnet der Debugger zwei Fenster mit den Titelzeilen „Command“ und „Disassembly“. Letzteres kann man der Übersichtlichkeit halber gleich wieder schlissen – die dort dargestellten Informationen zu interpretieren erfordert so viel an System- und Programmierkenntnissen, dass eine Beschäftigung damit den Rahmen dieses Turtorials sprengt.
Das „Command“ – Fenster enthält dagegen meist schon durchaus wertvolle Informationen. Beachtenswert sind zwei Zelen: Eine beginnt mit „Probably caused by:“ (deutsch: „Vermutlich verursacht von:“) gefolgt von einem Dateinamen. Der Tipp, den WinDbg hier abgibt, trifft schon erstaunlich oft ins Schwarze. Zumindest wenn die benannte Datei die Endung .sys trägt, lohnt es sich, zu untersuchen, woher sie stammt.
Die zweite interessante Zeile in WinDbgs Kurzanalyse beginnt mit „BugCheck“ und enthält danach eine Hexadezimalzahl und eine Reihe weiterer kryptischer Angaben in geschweiften Klammern. Hier handelt es sich um eine Wiederholung dessen, was der Bluescreen in der STOP-Zeile angezeigt hat. Um Genaueres über die Bedeutung dieser Angaben zu erfahren, gibt man unten im Command-Fenster hinter „kd>“ den Befehel !analyze –v
Ein . Er liefert meist einen Wust an Informationen, von denen zunächst die ersten Zeilen besondere Beachtung verdienen: Ein symbolischer, aus Großbuchstaben und Unterstrichen bestehender Name wie NTFS_FILE_SYSTEM nebst einer Kurzbeschreibung erklärt die Art des aufgetretenen Fehlers. In den folgenden Zeilen gibt es eine kurze Erklärung der mitgelieferten Parameter. Wer es noch genauer wissen will, kopiert das Fehlersymbol und fügt es in der Eingabezeile hinter dem Befehl .hh wieder ein:
.hh NTFS_FILE_SYSTEM
startet die WinDbg-Hilfe und zeigt einen Artikel an, der weitere Informationen zu dem Fehler enthält. Bei vielen Fehlerarten finden sich hier auch gleich Erklärungen, wie man die möglichen Fehlerursachen einschränken kann oder was zu tun ist, um den Fehler künftig zu vermeiden. Wenn dort steht, dass die häufigste Fehlerursache defekte Hardware ist, dann sollten Sie das durchaus ernst nehmen und die weitere Fehlersuche zunächst darauf konzentrieren.
Detektivarbeit
In der Ausgabe von !analyze –v sind außerdem noch die Zeilen unter der Überschrift „STACK_TEXT:“ interessant: Sie enthalten eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte steht dabei jeweils der name des zuständigen Moduls und dahinter, abgetrennt durch ein Ausrufe- oder ein Plus Zeichen, die Adresse innerhalb des Moduls. Taucht hier in den ersten paar Zeilen ein anderer Modulname als „nt“ auf, ist dieses Modul zumindest verdächtig, an dem Crash beteiligt gewesen zu sein.
Weitere Kandidaten kann man manchmal identifizieren, indem man den Befehl !thread eingibt.
Enthält die Ausgabe die Überschrift „IRP List:“, dann sollte man die Adressen aus der ersten Spalte dieser Liste an den Befehl !irp verfüttern: Ein Kommando wie
!irp ffabccd8
gibt detailliert Auskunft über ein so genanntes I/O Request Packet, das an dieser Adresse im Speicher liegt. Es enthält immer auch die Namen der Treiber, die an dieser Ein-/Ausgabeoperation beteiligt sind, und damit weitere mögliche Schuldige für den Absturz.
Wenn der Rechner immer beim Diskettenzugriff oder beim Anstöpseln eines USB- Gerätes abschmiert, lohnt ein Blick auf die I/O Request Packets.