Bluescreen und andere "Ausfälle"

Es ist schon schlimm genug, wenn ein Server ein "Problem" hat. ein "Bluescreen" ist mittlerweile zwar schon sehr selten geworden, aber leider immer noch Realität. Viele Administratoren merken es aber gar nicht einmal, dass der Server einen Fehler hatte, weil die Server heute einfach einen DUMP Schreiben und neu starten. Die "unterbrechung" bei einem normalen Server bewegt sich daher im Bereich von "Minuten". 

Bluescreen erkennen

Daher sollten Sie einfach jetzt mal schnell nachschauen, was ihr Server in letzter Zeit so getrieben hat. Schauen Sie doch einfach mal in die entsprechenden Verzeichnisse unter Windows Server oder ihrer Workstation. Im Idealfall ist der Ordner leer, wie hier

Minidumo Vista

Finden Sie dort aber diverse Dateien mit der Endung "DMP", dann hatte ihr Server mindestens einmal einen Bluescreen, den es weiter zu untersuchen gilt.

Dump-Verhalten einstellen

Wie ein Server auf einen Bluescreen reagiert, können und sollten Sie in den Eigenschaften des Systems konfigurieren. für die meisten Firmen ist ein "Kleines Speicherabbild" mit den wesentlichen Teilen für eine spätere Auswertung ausreichend.

Wer hier von vollständiges Abbild konfiguriert, zwingt den Server dazu, beim nächsten Start den vorher komplett gesicherten Speicher in eine Datei zu schreiben, was bei 2 und mehr GB RAM entsprechend lange dauert und nur in de seltensten Fällen mehr Informationen bringt. 

Minidump auswerten

Wie kommen sie nun aber an die Daten, die in diesem Dump enthalten sind? Früher gab es das Programm DUMPEXAM, was einem Administrator die Möglichkeit gegeben hat, den Dump des Servers wieder auszuwerten. Das Programm ist aber nicht mehr für Windows 2000 und höher zu finden. Statt dessen gibt es aber die Windows Debugging Tools, die man dazu nutzen muss.

  • Debugging Tools installieren
    Zuerst müssen wir uns die Windows Debugging Tools installieren (ca. 17 MB)
    Install Debug Tools

Download der aktuellen Tools
32bit http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#a
64bit http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

  • optional Debug-Symbole installieren
    Vielleicht haben Sie sich schon gewundert, warum es von Windows auch "Debug-Builds" gibt oder Sie auf der CD ein Verzeichnis "SYMBOLS" finden oder auch im Downloadcenter SYMBOLS-Dateien erhalten können. Diese Dateien enthalten Informationen für den Debugger, an welcher Stelle welche Routinen beginnen und welche Variable genutzt werden. Ohne Symbole kann man im Code kaum etwas sinnvolles erkennen. Aber auch ohne diese Symbole kann man zumindest die Module auf dem Stack erkennen und damit fast immer das "schuldige" Modul extrahieren.
  • WinDBG starten und Dump laden
    Dann starten wir den Windows Debugger aus dem Startmenü und öffnen über die GuI das DMP-File
    WinDBG öffnen
  • Schon ohne weitere Aktionen zeigt WinDBG den Inhalt des DUMP an.
    WinDBG Dumop auswerten
  • Dump auswerten mit "!analyze -v"
    Wer noch etwas genauer rein schauen will, kann mit eine "!analyze -v" den Bugcheck weiter auswerten lassen. Meist reicht aber auch schon die erste Ausgabe um das zuletzt aktive Modul einzugrenzen, welches des Fehler verursacht hat.

DebugDiag

Mitterlweile gibt es noch das Programm "DebugDiag" von Microsoft, mit welchem Sie einen DUMP auswerten können

DebugDiag (4MB bzw. 10 MB x64))
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24370

Dieses kleine Tool erlaubt es zum einen die Dumps einen Bluescreen aber auch die Dumps eines laufenden Prozesses zumindest "grob" zu analysieren. So eine "Momentaufnahme" als Dump können Sie auch über den Taskmanager erzeugen.

Die DMP-Datei wird dann einfach im DebugDiag eingeladen und nach einer kurzen Zeit wird im Browser einen HTML-Auswertung erstellt.

Eine sehr tiefgreifende Analyse ist dies natürlich nicht.

Weitere Links