Zu aller erst: ein Bluescreen (Bluescreen of death, BSOD) ist etwas Gutes – auch wenn die Folgen (Datenverlust, o.ä.) manchmal störend sind. Dazu später aber mehr.

Was ist ein Bluescreen (landläufig, inhaltlich aber falsch):

“Windows hat einen Fehler und ich darf neustarten und meine Email komplett neuschreiben, so ein Sch***”

Was ist ein Bluescreen (Informatik):

  1. Eine unhandled Kernelmode Exception (<= dies ist die häufigste Variante)
  2. Eine Sicherheitsmaßnahme sofern system relvante Anwendungen/Dienste (un)gewollt beendet werden (z.B. Absturz, Virenaktivität, etc), Bsp.: csrss
  3. Ein durch NMI oder “Crash on CTRL Scroll” manuell herbeigeführter Bluescreen, oftmals für Support Zwecke eingesetzt (gehe ich hier nicht weiter darauf ein)
  4. Durch einen angehängten Debugger, Stw.: Kernel Debug (würde den Rahmen hier sprengen, wenn ich hier weiter darauf eingehen würde)
  5. Ausgelöst durch den Driver Verifier (soll hier auch nicht Thema sein)

All diese Gründe resultieren in einer Ausnahmebehandlung in der nur noch rudimentäre Dinge funktionieren. Daher wird ein blauer VGA Screen angezeigt auf dem eine Zusammenfassung des Problems dargestellt wird:

image

Übrigens: ein Bluescreen wird manchmal auch als “Bug check” bezeichnet.

Und das bedeutet?

Nun kommen wir zu der Begründung, warum ein Bluescreen etwas Gutes ist:

“Während” des Bluescreens funktionieren nur noch wenige Dinge wie Diskzugriffe und Zugriff auf das RAM. Dies wird dazu benötigt um sog. Memory Dumps (Speicherabbilder) schreiben zu können. Diese Speicherabbilder dienen dazu, dass eine nachgelagerte Analyse des Problems durchgeführt werden kann.

Außerdem sichert diese Ausnahmebehandlung die Integrität der Daten, denn sobald eine solche Ausnahme erkannt wird, ist die Integrität des Betriebssystems (Operating System, OS) und damit der darin verwendeten Daten nicht mehr sichergestellt und zum Schutz dieser muss das OS an dieser Stelle beendet werden und die Daten neugeladen werden.

Dies führt uns zum nächsten Punkt:

Wodurch kann ein Bluescreen ausgelöst werden?

Streng genommen nur durch eine Kernel Komponente. D.h., dass das OS selber oder aber ein diesem angeschlossener Treiber die einzigen Gründe für einen Bluescreen darstellen. Zu ca. ~80% (zumindest zu Windows XP Zeiten) waren in der Tat fehlerhafte 3rd party Treiber die Ursache für Bluescreens.

Bei Hardwarefehlern wird zu irgendeinem Zeitpunkt ein Treiber oder das OS einen Fehler erzeugen, der dann in einem Bluescreen resultiert. Insb. wenn auf einer Maschine sehr häufig bei unterschiedlichsten Aktionen sehr unterschiedliche Bluescreen IDs (s.u.) beobachtet werden, liegt die Vermutung nahe, dass es sich um einen HW Defekt handelt.

Das bedeutet aber auch, dass KEINE USER ANWENDUNG DIREKT EINEN BLUESCREEN AUSLÖSEN KANN!

Eine Anwendung kann zwar einen Treiber anstoßen etwas zu tun, der Treiber sollte aber idealerweise alle Parameter auf Gültigkeit prüfen und außerdem an den richtigen Stellen Exception Handler implementieren, so dass unhandled Exceptions nach Möglichkeit nicht auftreten – oder zumindest sehr unwahrscheinlich werden.

Angefangen mit Windows Vista und fortgesetzt mit Windows 7 wurde die Kernelarchitektur überarbeitet, so dass heute deutlich weniger Treiber überhaupt in der Lage sind tatsächlich einen Bluescreen auszulösen. Als Beispiel möchte ich hier den Grafikkarten Treiber nennen. Früher (also auf Windows XP) konnte man sehr häufig Bluescreens mit den IDs 0xA bzw. 0xD1 ausgelöst durch Grafikkartentreiber beobachten. Heute (also Windows Vista/7) flackert der Bildschirm kurz und eine Ballonnachricht erklärt kurz, dass der Grafikkartentreiber neugestartet worden ist.

Merke: Windows 7 hat alleine durch die veränderte Kernelarchitektur deutlich seltener Bluescreens und kann so das Risiko von Datenverlusten reduzieren!

Was kann ich tun, wenn ich einen Bluescreen hatte?

Alle:

Nach einem Bluescreen wird man gefragt, ob man ein Speicherabbild zu Microsoft Servern hochladen möchte um zu überprüfen, ob es eine bekannte Lösung für das Problem gibt. Wenn man dies tut, so wird ein sog. Mini-Dump (je nach OS und Bit Variante 64kb bis typischerweise ~300kb) hochgeladen. In diesen Mini Dumps ist nicht viel enthalten, schon gar keine persönlichen Informationen. Dort ist der letzte Callstack, der Zustand der CPUs und deren Register sowie die geladenen Module (also Treiber, Prozesse, etc) enthalten.
Mehr nicht!

Diese Minidumps werden automatisch durch einen Debugger geführt und mit einer Datenbank verglichen. Wenn ein vergleichbarer Dumpeintrag vorhanden wird, wird dieser neue dem alten hinzugefügt und geschaut, ob für diesen Eintrag eine Lösung verfügbar ist. Wenn es eine Lösung gibt, dann wird diese dem Übersender mitgeteilt, z.B. mit Hinweis auf ein Treiberupdate.

imageimage

IT Pros:

Hinweis: Bei Unsicherheit unbedingt den Microsoft Support einschalten!

Wichtig: Prinzipiell sind ohne Zugriff auf sog. “private symbols”  und ohne Assemblerkenntnisse nur sehr rudimentäre Analysen möglich!

Zuerst muss ein entsprechendes System für den richtigen Memory Dump konfiguriert werden:

image

Oder aber über die Registry:

image

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Und dann auf den Bluescreen, bzw. den Memory Dump gewartet werden.

Der Einstieg in die selbständige “Analyse” (ich meine damit eigentlich ein schnelles draufschauen und dann den Support anrufen! Winking smile ) beginnt bei den Debugging Tools for Windows. Dort wird auch erklärt, was Symbols sind und wie diese konfiguriert werden können (ich möchte hier zwar nicht weiter darauf eingehen, nur soviel: man sollte sie setzen und z.B. über das File->Symbols Menü “SRV*c:\symbols*http://msdl.microsoft.com/download/symbols” einstellen, ansonsten sind Debugging Kurse nicht mal in zwei Wochen hands on sinnvoll durchzuführen! Winking smile )

Wenn nun die Debugging Tools for Windows installiert sind, muss jetzt der Windows Debugger “Windbg” geöffnet (übrigens sollte man hier die x64 Variante nutzen, wenn x64 Dumps betrachtet werden sollen und x86 Version bei x86 Dumps) und über das File Menu “open Crash dump…” ausgewählt und das entsprechende Memory Dump File geöffnet werden.

image

Das Öffnen kann je nach Dump, Symbols und aktueller Sonneneruptionen etwas länger dauern.

Nach dem Öffnen werden schon erste Informationen über den Dump gezeigt:

image

Nun kann – ohne mehrwöchige Trainings - eigentlich nur noch eins getan werden und zwar auf den Link “!analyze –v” geklickt werden (oder alternativ kann dies auch in die Konsole eingegeben werden).

Dadurch wird ein Script/Debugger Extension gestartet (ähnlich dem wie es bei der o.g. automatischen Analyse passiert), welches versucht (!! es ist wirklich nicht mehr als ein Versuch) einen wahrscheinlichen (!!) Verursacher zu identifizieren, z.B.:

image

In einem solchen Fall (typischerweise können für den Laien nur sinnvolle Ergebnisse erzielt werden, wenn Bluescreen IDs 0xA oder 0xD1 verwendet wurden), bei dem ein Treiber genannt wird, kann jetzt überprüft werden, ob es neuere Versionen von dem Treiber gibt, bzw. ob der Treiber tatsächlich auf der Maschine benötigt wird. Wenn beides nicht weiterhilft sollte spätestens dann der Microsoft, bzw. Hersteller Support des Treibers kontaktiert werden!

Zum besseren Verständnis des aufgetretenen Problems kann die Hilfe des WindBG sehr nützlich sein. Dort werden die Bluescreen/Bug Check IDs und deren Parameter erklärt und in vielen Fällen auch Hinweise auf das weitere Vorgehen genannt. Über den Index einfach “bug check %ID%” eingeben:

image

 

Ich hoffe ich konnte ein wenig Licht ins Blau bringen.

 

-Stephanus

 

Links:

Debugging Tools for Windows

How to generate a kernel dump file or a complete memory dump file in Windows Server 2003

http://de.wikipedia.org/wiki/Blue_Screen_(Fehlermeldung)

Bluescreeen Screen Saver v3.2