Ein Bluescreen ist meist mehr als nur ärgerlich. Manche
haben Glück und sehen ihn nur selten, andere sind fast täglich damit konfrontiert. Kaum einer weiss aber, was die angezeigten Zeichenfolgen bedeuten und wie er sich nach einem Bluescreen zu verhalten hat.
Zumindest bezüglich des zweiten Teils gibt es eine einfache Antwort. Der erste Schritt ist, die Informationen zur Sicherheit zu notieren – und zwar mindestens die Zeile mit einem Text in Grossbuchstaben wie DRIVER_IRQL_NOT_ LESS_OR_EQUAL sowie die Zeile unterhalb von technische Informationen mit dem STOP-Code und typischerweise vier Parametern. Der nächste Schritt ist dann normalerweise ein Neustart, falls dieser nicht ohnehin automatisch ausgeführt wird. Aber auch wenn der Neustart klappt, bedeutet das noch keineswegs, dass das Problem behoben ist.
Wer sich noch an frühere Windows-NT-Versionen erinnert, weiss, dass es damals wesentlich häufiger Bluescreens gegeben hat. Aber auch bei den aktuelleren Windows-Versionen wie Windows 2000 und Windows XP tritt diese Situation gelegentlich noch auf.
Ein Bluescreen ist immer ein Hinwies auf einen schwerwiegenden Fehler. Die Ursache kann sowohl in Software- wie auch bei Hardwareproblemen liegen. Die Fehler werden erzeugt, wenn bei einer Komponente, die im Kernel Mode läuft, ein Fehler auftritt, der vom System nicht selbständig behoben werden kann. Normale Anwendungen dagegen können keinen Bluescreen verursachen, weil diese im User Mode laufen und die Fehler dort vom Betriebssystem abgefangen werden können.
Im Kernel Mode werden ausschliesslich Betriebssystemkomponenten und Gerätetreiber ausgeführt. Letztere stehen meistens auch in Verbindung mit Bluescreens – Hardwarefehler werden für das System über Ausnahmesituationen bei Gerätetreibern sichtbar. Softwarefehler von Gerätetreibern wiederum sind deshalb so kritisch, weil Komponenten im Kernel Mode recht frei auf Speicher und andere Ressourcen zugreifen und damit Probleme mit anderen Modulen verursachen können.
Durch Änderungen in der Programmierung des Kernels sowie mit einer klaren Schnittstellendefinition, speziellen Entwicklungs- und Testwerkzeugen und einem umfassenden Test- und Zertifizierungsprogramm für Treiber hat Microsoft das Problem zwar recht gut in den Griff bekommen. Aber Fehler in der Software lassen sich nie vollständig ausschliessen, weshalb es auch weiterhin zu Bluescreens kommt.
Ein Bluescreen bedeutet übrigens nicht, dass das System vollkommen stillsteht. Vielmehr wird ein schwerwiegender Fehler «kontrolliert» vom System behandelt. Informationen über den Fehler werden protokolliert und die Meldungen am Bildschirm angezeigt. Je nach Systemkonfiguration wird auch eine Dump-Datei erzeugt. Die Systemkomponente, die Bluescreens erzeugt, heisst übrigens KeBugCheckEx.
Im Bluescreen werden in den meisten Fällen neben einigen Informationen dazu, was man als nächstes machen sollte, zwei wichtige Aussagen geliefert. Die wichtigste Information ist die eingangs genannte Meldung. Es gibt ungefähr 150 verschiedene Meldungen. Die meisten Bluescreens lassen sich aber auf ganz wenige Meldungen zurückführen – und nur rund 20 bis 25 Stop-Codes sind wirklich relevant. Am wichtigsten sind
• 0x0A, IRQL_NOT_LESS_OR_ EQUAL: Eine Komponente hat eine ungültige Speicheradresse verwendet.
• 0x7F, INVALID_KERNEL_MODE_TRAP: Hängt in der Regel mit falschen Informationen in bestimmten Speicherbereichen zusammen, die von Anwendungen falsch gesetzt wurden.
• 0x1E, KMODE_EXCEPTION_ NOT_HANDLED: Fehler in Kernel-Mode-Komponenten, für die es keine definierte Fehlerbehandlungsroutine gibt – also der grosse Rest.
• 0x7B, INACCESSIBLE_BOOT_ DEVICE: Das Laufwerk mit dem Betriebssystem ist beschädigt. Tritt nur beim Systemstart oder nach schwerwiegenden Hardwarefehlern auf.
Eine Meldung wie IRQL_NOT_ LESS_OR_EQUAL hat immer einen zugeordneten Code, in diesem Fall 0x0A oder 0x0000000A. Die Darstellung variiert etwas, wobei oft die führenden Nullen gestrichen werden. Zusätzlich werden einige Parameter ausgegeben, meist drei oder vier. Diese informieren in den meisten Fällen beispielsweise über die Speicheradresse der den Fehler verursachenden Komponente. Die Parameter sind in den Technet-Artikeln unter den unten genannten URLs umfassend erläutert. Die Informationen sind nicht nur für das Verständnis der Stop-Codes, sondern auch für die Werkzeuge wichtig, mit denen die Fehler weiter analysiert werden können.
Umfassende Informationen zu einzelnen Meldungen in Bluescreens finden sich einerseits für den
Windows 2000 Server und andererseits für Windows XP Professional. Die Informationen bezüglich Windows XP können auch für Windows 2000 und den Windows Server 2003 verwendet werden und sind sehr umfassend. Dort werden sowohl die Ursachen als auch Lösungsmöglichkeiten für das den Bluescreen auslösende Problem beschrieben.
Damit man die Fehler weiter analysieren kann, sind Dump-Dateien erforderlich. Diese lassen sich im Bereich System der Systemsteuerung und dort über die Schaltfläche Einstellungen im Abschnitt Starten und Wiederherstellen des Registers
Erweitert konfigurieren. Im angezeigten Dialogfeld wird im unteren Bereich das Verhalten des Systems bei schwerwiegenden Fehlern gesteuert.
Bei Domänencontrollern unter dem Windows Server 2003 werden in solchen Situationen zwingend Einträge in das Ereignisprotokoll geschrieben, bei allen anderen Systemen ist das optional. Diese Massnahme ist allerdings sinnvoll, weil in dem Eintrag der Stop-Code und die generierten Parameter noch einmal aufgeführt sind – die entsprechende Option sollte deshalb in allen Windows-Systemen eingeschaltet werden.
Die Administrator-Warnmeldung bringt dagegen wenig, da sie nur über unzuverlässige Kommunikationsmechanismen ausgeliefert wird. Der automatische Neustart macht dagegen Sinn, weil er meistens funktioniert und das System dann relativ schnell wieder verfügbar ist.
Am interessantesten sind die Einstellungen zu den Crash-Dump-Dateien, für die ab Windows XP und dem Windows Server 2003 vier Optionen zur Verfügung stehen. So können etwa ein kleines Speicherabbild mit 64 kByte, ein umfassenderes Kernel-Speicherabbild oder ein vollständige Dump erzeugt werden, man kann aber auch komplett darauf verzichten. Das kleine Speicherabbild reicht für viele Analysezwecke aus, auch für Microsofts Online Crash Analysis (OCA). Komplexere Analysen erfordern dagegen meist zumindest das Kernel-Speicherabbild. Allerdings muss man dabei und insbesondere bei einem vollständigen Dump berücksichtigen, dass diese Dateien je nach installiertem Hauptspeicher sehr gross werden können: Bei 512 MByte Hauptspeicher ist ein vollständiger Dump eben auch 512 MByte gross.
Der einfachste Ansatz für die Analyse von Dump-Dateien ist die Microsoft OCA. Ein Link dazu findet sich unter www.microsoft.com/windows/reskits/webresources. Die Verwendung der OCA kann über das Register Erweitert im Bereich System der Systemsteuerung aktiviert und deaktiviert werden. In bezug auf die Bluescreens reicht es aus, die Fehlerberichterstattung für kritische Fehler einzuschalten. Die Informationen aus dem kleinen Speicherabbild werden dann im Fehlerfall an Microsoft geliefert. Man benötigt allerdings ein Passport-Konto, damit Microsoft automatisch über die Ergebnisse der Analyse informieren kann.
Falls man die Sache lieber selbst in die Hand nimmt, muss man die Debugging Tools for Windows von www.microsoft.com/whdc/ddk/debugging/default.mspx laden und die Symboldateien für das Betriebssystem installieren, die übrigens oft aktualisiert werden. Die Update-Aufgabe kann aber auch der grafische Debugger windbg übernehmen, indem man dort den Symbol Search Path als SRV*c:\debug\ symbols*http://msdl.microsoft.com/download/symbols einträgt. Das lokale Verzeichnis lässt sich natürlich anpassen.
Windbg ist das wichtigste Werkzeug für die Analyse. Nach dem Öffnen einer Dump-Datei wird automatisch der Analyseprozess gestartet. Falls die angezeigten Informationen nicht ausreichen sollten, lässt sich über den Befehl !Analyze -v eine umfassendere Analyse und Ausgabe starten.
Die gelieferten Informationen setzen in jedem Fall ein gewisses Verständnis für die Systemprogrammierung voraus. Immerhin wird man darin aber meist auch Hinweise auf den Treiber finden, der das Problem wahrscheinlich verursacht hat. Und mit diesen Informationen kann man versuchen, ein Update für den fehlerhaften Treiber zu finden. Manchmal hilft es auch, den Fehler an den Hersteller weiterzuleiten, damit dieser eine entsprechende Aktualisierung vornehmen kann.
Auch wenn ein Debugger im ersten Moment ein sehr komplexes Werkzeug zu sein scheint – als erfahrener Administrator kann man damit auch ohne vertiefte Programmierkenntnisse wertvolle Informationen erhalten, die helfen, ein Problem zu lokalisieren und schliesslich zu lösen.
