Da es - wie ich hoffe - doch einige User ernsthaft interessiert, einmal hinter das Geheimnis eines Bluescreens zu schauen, habe ich mich entschlossen, ein How-To betreffs Bluescreens und ihrer Analyse zu schreiben. Das Material lehnt sich dicht an einen Artikel aus einer c’t des Jahres 2004 an, indem die gesamte Vorgehensweise sehr gut beschrieben wird.
Zuallererst sollte man sich von dem Gedanken freimachen, ein BSOD sei etwas schlechtes. Erscheint ein Bluescreen, dann heisst das, das das Betriebssystem festgestellt hat, das es sich momentan in einem Zustand befindet, in dem es nicht mehr sicher weiterarbeiten kann. Jede noch folgende Aktion könnte größeren Schaden nach sich ziehen, weshalb das System sich folgerichtig kontrolliert selbst herunter fährt.
Ich empfehle deshalb auch im Fall eines völligen Einfrierens des Systems selbst einen Bluescreen hervorzurufen, anstatt per Reset-Schalter oder ähnlichen Experimenten das System noch mehr zu schädigen.
Die Voraussetzungen dafür sind ganz einfach einzurichten:
- in der Registry zum Schlüssel
HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\i8042prt\Parameters
navigieren
- dort einen neuen DWORD-Wert mit dem Namen CrashOnCtrlScroll einrichten und diesem den Wert 1 zuweisen
-Neustart
Nach dem Neustart kann jederzeit ein Bluescreen ausgelöst werden, indem man die rechte Strg-Taste gedrückt hält und zweimal auf Rollen drückt (die mittlere Taste in der Dreiergruppe über dem Cursor-Block, die auch manchmal mit Scroll oder ScrlLock beschriftet ist.
User, die noch keinen Bluescreen zu Gesicht bekommen haben, sich aber über einen manchmal aus heiterem Himmel erfolgenden Neustart des Systems wundern, sind (unwissentlich) Microsofts honigsüßen Worten auf den Leim gekrochen, das es unter XP keine Bluescreens mehr gäbe.
Diese Aussage ist insofern korrekt, als das die Bluescreens einfach versteckt wurden. Sollte ein Ereignis wie ein plötzlicher scheinbar unmotivierter Neustart auftreten, dann sollte man unter folgendem Pfad nachschauen und wenn man an einer Bluescreen-Analyse interessiert ist, die Optionen wie folgt einstellen
Rechtsklick auf Arbeitsplatz/Eigenschaften/Erweitert/Starten und Wiederherstellen/Einstellungen/Systemfehler
Hier gibt es drei wichtige Optionen:
"Automatisch Neustart durchführen" - sollte deaktiviert sein.
(Ist es aktiviert, kommt es eben zu einem Neustart, ohne dass ein Bluescreen gezeigt und die CPU angehalten wird)
"Debuginformatioen speichern" - hier ist standardmäßig das "kleine Speicherabbild" ausgewählt, was jedoch für eine Analyse des BSOD nicht ausreicht. Hier sollte "Kernelspeicherabbild" eingestellt werden. Ein "vollständiges Hauptspeicherabbild" ist so groß wie der komplette Hauptspeicher plus ein paar zusätzliche MB, bringt jedoch keine Vorteile.
"Vorhandene Dateien überschreiben" - sollte aktiviert sein, da andernfalls Windows einfach kein Speicherabbild schreibt, wodurch man den Fehler dann auch nicht analysieren kann. Resultierend daraus sollte man nach einem BSOD und dem Neustart des Systems den erstellten Memory-Dump entweder umbenennen oder durch Kopieren sichern.
Damit ist der erste Teil der Analyse-Vorbereitung abgeschlossen.
Zur Sicherheitsarchitektur von XP gehört es, dass ein x-beliebiges Programm Windows nicht zum Absturz bringen kann, da dieses im sogenannten User-Mode (auch "Ring 3") genannt in einem eigenen virtuellen Adressraum läuft und nicht auf den Adressraum anderer Programme oder gar der Hardware zugreifen kann.
Ein Bluescreen kann nur entstehen, wenn Code im Kernel-Mode (auch "Ring 0" genannt) etwas tut, was er nicht darf.Das können Gerätetreiber, oder der Mikrokernel selbst sein. Im "Ring 0" teilen sich alle Treiber einen gemeinsamen Adressraum und können sich deshalb auch gegenseitig Schwierigkeiten machen.
Soviel zur Theorie.
Zeigt das System nun einen Bluescreen, bekommt man schon ein paar wichtige Informationen geliefert, die man allerdings interpretieren muss.

(dieser Bluescreen gehört nicht zur später folgenden Analyse. Ich habe ihn nur benutzt, um die nächsten Zeilen besser darstellen zu können)
Jeder Bluescreen liefert eine Zeile, die mit STOP beginnt, worauf sich eine
achtstelllige Hexadezimal-Zahl anschließt. Diese Zahl gibt einen ersten Hinweis auf den Fehler, wenn sie richtig interpretiert wird.
Oft steht ausserdem noch eine Zeile in der Art
BAD_POOL_HEADER
IRQL_NOT_LESS_OR_EQUAL
oder ähnliches dabei. In vielen Fällen kann man mit dieser Zeile und etwas Googelei (besser ist Scroogelei) schon im Netz Hinweise auf den Übeltäter und Lösungsvorschläge finden.
Oft hat man allerdings auch Pech.
Genau dann brauchen wir das beim BSOD erstellte Speicherabbild, das normalerweise unterhalb WINDOWS als MEMORY.DMP erstellt wurde.
Microsoft bietet uns nun ein Werkzeug an, um das Speicherabbild zu analysieren - den Debugger WinDbg (ca. 15,8 MB), der von Microsoft heruntergeladen werden kann. Allerdings nützt der Debugger allein wenig, man braucht auch noch so genannte Symboldateien, die jedoch im vollen Umfang ca. 195 MB groß sind. Die sind allerdings nicht zwingend komplett notwendig, vereinfachen aber das Verfahren, wenn sie komplett auf der Platte liegen, was bei ordentlichen DSL-Anschlüssen kein größeres Download-Problem darstellen dürfte. Allerdings erkennt der Debugger mitunter nach der Installation der Symboldateien diese nicht richtig und bringt ständig eine Fehlermeldung; deshalb bevorzuge ich auch eher die Methode des selektiven Downloads bei Bedarf wie folgt.
Wer die Symbole nicht komplett downloaden will, kann den Debugger so einrichten, dass er nur die Symboldateien aus dem Netz lädt, die gerade gebraucht werden. Das funktioniert folgendermaßen:

- WinDbg installieren
- irgendwo nach Belieben einen neuen Ordner anlegen
- im WinDbg den Menübefehl File Symbol Path wählen und in das Eingabefeld eintragen:
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
wobei statt "C:\Symbols" der neu erstellte Ordner eingetragen werden muss. Dort speichert WinDbg die heruntergeladenen Symbole. Ich nehme dafür WINDOWS\SYMBOLS, wie man sieht.
Jetzt lädt man das beim Bluescreen erstellte Speicherabbild mit File/Open Crash Dump, woraufhin sich zwei Fenster mit den Titelzeilen Command und Disassembly öffnen. Das letztere kann man gleich wieder schließen, da es uns nichts nützt. In neueren Versionen des WinDbg öffnet sich dieses Fenster in der Regel nicht mehr mit, bei älteren Versionen war das jedoch der Fall.
Im Command-Fenstersind jetzt schon ein paar wichtige Informationen zu sehen:

- die Zeile, die mit Probably caused by: beginnt (was soviel heisst wie: "vermutlich verursacht von:") meldet einen Dateinamen, der in den meisten Fällen schon ein Treffer ist. Handelt es sich hier um eine Datei mit der Endung .sys dann lohnt es sich, zu untersuchen, woher sie stammt. (Wir nehmen hier im Beispiel mal an, es ist eine Datei namens i8042prt.sys)
- die zweite interessante Zeile beginnt mit BugCheck und enthält eine Hexadezimalzahl und weitere kryptische Angaben in Klammern. Und siehe da - es handelt sich hier um dieselbe Zahl, die nach dem STOP-Befehl auf dem Bluescreen auftauchte.
Wir sind also auf dem richtigen Weg und müssen jetzt in Erfahrung bringen, was uns diese Zahlen eigentlich sagen wollen.
Nächster Schritt:

- unten im Comand-Fenster hinter "kd>" den Befehl
!analyze -v
eingeben. Es erscheint eine Menge an Informationen, wobei wir uns auf die ersten Zeilen konzentrieren.Die Art des aufgetretenen Fehlers wird durch einen aus Großbuchsataben und Unterstrichen gebildeten Namen wie MANUALLY_INITIATED_CRASH angezeigt, verbunden mit einer (zu) kurzen Beschreibung des Fehlers. Um dazu ausführlichere Informationen zu erhalten, kopieren wir diesen Namen und fügen ihn in der Eingabezeile hinter dem Befehl ".hh" wieder ein, was dann so aussieht:
.hh MANUALLY_INITIATED_CRASH
Dieser Befehl startet die WinDbg-Hilfe, in der der Name automatisch gesucht und ausführlichere Angaben dazu angezeigt werden. Sehr oft findet man hier auch Lösungsansätze und Tipps wie der Fehler zu eliminieren ist. Steht dort, dass defekte Hardware die häufigste Fehlerursache ist, dann sollte man das Ernst nehmen.
Bei den Informationen, die der "!analyze -v"-Befehl ausgibt interessieren uns ausserdem noch die Zeilen unter der Überschrift STACK_TEXT:.
Dort steht eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte der jeweiligen zeile steht der Name des zuständigen Moduls und dahinter, durch ein + oder ! abgetrennt die Adresse innerhalb des Moduls. Wenn hier in den ersten paar Zeilen ein anderer Modulname als nt steht, dann ist dieses Modul zumindest schon mal schwer verdächtig.
mit dem Befehl
!thread
bekommt man eine weitere Ausgabe. Enthält diese die Überschrift IRP List, dann nimmt man die Adressen aus der ersten Spalte der Liste und gibt sie mit dem Befehl !irp ein. Das sieht dann z. B. so aus:
!irp ffabccd8
Daraufhin erhält man weitere Verdächtige, nämlich den Inhalt des so genannten I/O Request Packets, das an dieser Adresse im Speicher liegt. Das Packet enthält immer auch die Namen der an dieser Ein/Ausgabe beteiligten Treiber.
Weiter gehts. Wir sind fast fertig.
Den weiter oben zuerst herausgekitzelten Modul-Namen, in der Zeile, die mit Probably caused by: beginnt (i8042prt.sys), benutzen wir nun für die End-Analyse.

Wir geben den Befehl lm v ein, gefolgt vom Modulnamen ohne die Endung .sys, dafür hängen wir jedoch ein m davor. Das Ganze sieht dann so aus:
lm v mi8042prt
Jetzt sollten wir in der Ausgabe den kompletten Dateinamen mit Pfad der Treiberdatei und Herstellernamen bekommen. Ist das nicht der Fall, dann probieren wir den Befehl
!devnode 0 1

der uns eine Liste aller geladenen Gerätetreiber ausgibt. In dieser Liste suchen wir wieder den Modulnamen (ohne Endung) (über die Funktion Edit/Find in der Menüleiste)
In dem Eintrag, in dem er hinter Service Name erscheint, interessiert uns der Instance Path. Diesen notieren wir uns.
Und damit hat die schwere Geburt fast ihr Ende gefunden.
Wir starten wieder regedit und gehen in den Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum
und von dort aus weiter genau entlang des eben notierten Pfades.Und hier verrät uns endlich der Eintrag DeviceDesc, um was für ein Gerät oder Treiber es sich bei dem wahren Übeltäter handelt.
Fertig!
Hat man die den Fehler auslösende Komponente dann identifiziert, sollte man sich z. B. im Gerätemanager noch ein paar weitere Infos zum Treiber besorgen, wie Hersteller, Versionsnummer usw. und sich dann auf die Suche nach einem neuen Treiber machen. Manchmal hilft auch eine einfache Neuinstallation des bewußten Treibers, bzw. eine Systemwiederherstellung oder das Zurückspielen eines vorher angelegten Images, um den früheren Zustand vor der Veränderung, die den Fehler ausgelöst hat, wieder herzustellen. Natürlich kann man sich - mit diesen gesammelten Angaben bewaffnet - auch auf in die Weiten des Netzes begeben, um eine intensive Internet-Recherche zur Fehlerbeseitigung zu betreiben. Sollte es sich um defekte Hardware handeln, dann wäre wohl ein Austausch das passende Procedere.
Ich gebe zu, das Ganze ist kein Kinderkram, aber einen richtigen Computerfreak sollte es schon mal reizen, solche Geheimnisse zu erforschen und zu entdecken, anstatt nur mit den Schultern zu zucken, wenn ein BSOD auftaucht.
Übrigens, wer keinen Bluescreen mehr sehen will, kann auch die Farbe ändern und hat dann eben einen RSOD oder GSOD.
Dazu braucht nur folgendes:
- im WINDOWS-Ordner zur SYSTEM.INI navigieren und diese wie folgt editieren:
Nach [386Enh] folgende Einträge hinzufügen:
MessageTextCOLOR=X
MessageBackCOLOR=X
Das X einfach durch die Nummer der gewünschten Farbe ersetzen:
Black = 0
Blue = 1
Green = 2
Cyan = 3
Red = 4
Magenta = 5
Yellow/Brown = 6
White = 7
Grey = 8
Bright Blue = 9
Bright Green = A
Bright Cyan = B
Bright Red = C
Bright Magenta = D
Bright Yellow = E
Bright White = F
Wobei ich 7 und F nicht ernsthaft in Erwägung ziehenn würde. Denn weisse Schrift auf weissem Grund, das erinnert mich irgendwie an die ostfriesische Nationalflagge…
Viel Spaß und gutes Gelingen.
Eingetragen unter: Software, Technik
1 Kommentar June 5th, 2007
Etwa einmal im Monat findet bei mir der große PDF-Kehraus statt und jedesmal bin ich am Verzweifeln.
Es ist ja eine sehr erfreuliche Entwicklung, dass immer mehr Wissenschaftler dazu übergehen, einen Teil ihrer Publikationen frei online zur Verfügung zu stellen. Im Zuge des Open Access-Gedanken und der CC-Lizenzen sind inzwischen viele qualitativ hochwertige Werke frei erhältlich, die in den Tiefen des Netzes schlummern und von fleißigen Bloggern in einem lecker medialen Potpourri geborgen werden. (Hat sich diesbezüglich schon mal jemand über die Gatekeeper-Funktion von Bloggern Gedanken gemacht?)
Das große Ärgernis ist aber die Unfähigkeit Sorglosigkeit, mit der die Autoren die Metadaten ihrer PDF-Files pflegen.
Ich sitze dann einmal im Monat dran, einen Ordner mit kryptisch benannten PDFs (man kann schon froh sein, wenn der Dateiname Hinweise auf den Inhalt des Dokumentes zulässt) zu sichten und die Metadaten langwierig selbst auszufüllen. Im besten Fall. Im üblichen Fall verschwindet die Datei fhrst754_gh.pdf in den unerforschten Weiten meiner Festplatte.
Selbst Wissenschaftler, die zu Online-Themen forschen, ignorieren meist die Möglichkeit der Metadaten im PDF-Format.
Jan Schmidt zum Beispiel, der Weblog-Forschung betreibt und dem ich enorm dankbar dafür bin, dass er so viele seiner Ergebnisse und Vorträge frei zur Verfügung stellt, benennt zwar die Dateien halbwegs assoziativ und gibt sogar auf den Downloadseiten die akademische Zitationsweise an, in den PDFs selbst aber: nada!
Dabei ist es doch im eigenen Interesse der Autoren, wenn die Datei, die sich nach Publikation ja sonst wie verbreiten kann, wenigstens die Download-URL in den Metadaten enthält.
Worst case scenario: Du willst ein Dir vorliegendes PDF zitieren und findest die Quelle nicht mehr!
Mein Verdacht: Es wird noch immer davon ausgegangen, dass ein geladenes PDF sofort "in den Druck" gegeben wird.
Das eigentlich Überraschende: Es gibt kaum Tools um Meta-Daten in PDFs komfortabel zu bearbeiten.
Einzig der PDF Explorer scheint sich mir in richtige Richtung zu bewegen: Eine Explorer-ähnliche Oberfläche erlaubt das sofortige Editieren der Metadaten, ist aber bei einer großen Anzahl von PDFs doch recht umständlich zu bedienen.
Adobe bietet mit Adobe Bridge seit kurzem eine ähnliche Lösung; Bridge dient aber eher der Organisation sämtlicher in der Creative Suite erstellten Daten und ist deshalb für die gewünschten Zwecke völlig überzüchtet und für den Privatanwender eh nicht bezahlbar, da das Modul nur mit der kompletten Creative Suite bezogen werden kann.
Obwohl ich das Problem am Beispiel von wissenschaftlichen Publikationen aufgezeigt habe, dürften aber auch die Leser, die nur aus privaten Gründen mit PDFs zu tun haben, die Situation kennen.
Deshalb meine Frage an Euch: Wie organisiert Ihr Euer PDF-Archiv?
Eine Google-Recherche zu dieser Problematik erbrachte (neben erstaunlich wenigen relevanten Treffern) noch die Nutzung einer Desktop-Suchmaschine, wie z.B. Google Desktop. Diese Tools scannen auch die Inhalte von PDFs, erlauben also die Festplatten-übergreifende Suche nach Inhalten in PDFs. Halte ich aber aus zwei Gründen für wenig praktikabel:
Erstens will der Kram auch mal weggebrannt werden (Ja, da gibts auch Lösungen; dann wirds aber wirklich umständlich…) und zweitens bin ich oftmals gar nicht auf der Suche nach konkreten Inhalten, sondern will mich von Texten erstmal inspirieren lassen - von denen ich gar nicht mehr weiß, dass Sie auf meiner Platte liegen…
Um Hilfe und Ideen wird gebeten.
netbib - übernehmen Sie!
Eingetragen unter: Literatur, Text, Software
3 Kommentare April 27th, 2007