Bluescreens haben etwas ziemlich mystisches an sich. Viele Anwender meinen, dass es Stop-Fehler nur unter Windows gibt, und diese etwas mit der (fehlenden) Stabilität des Betriebssystems selbst zu tun haben.
Wer sich über Microsoft und/oder Windows lustig machen möchte erwähnt gerne gehäßig diese Bluescreens of Death (BSOD) und ihre angebliche Häufigkeit unter Windows Betriebssytemen.
Man könnte dann kontern, dass in anderen Betriebssystemen ein Bluescreen gar nicht auffällt, weil er sich von der Benutzeroberfläche kaum unterscheidet ;-)
Tatsächlich gab es aber vor allem zur Zeit von Windows 98 und Windows ME noch sehr viele Bluescreens.
Heute - also unter NT basierten Betriebssystemen wie XP, Vista, Server 2003 und Server 2008, werden fast alle Stop-Fehler von fehlerhaften Treibern oder von sehr systemnaher fehlerhafter Software verursacht, oder - was noch schlimmer ist - von tatsächlich physisch schadhaften Hardwarekomponenten.
Egal was schuld ist, für mich als Trainer und Vortragender sind Bluescreens vor allem lästig und mitunter peinlich. In anderen Situationen - z.B. wenn durch einen Bluescreen Daten verloren gehen, kann so ein Stop Fehler sogar massiven Schaden anrichten.
Doch wie wird man aus den Crash Daten schlau? Woher weiss man, welcher Treiber daran schuld ist?
Nicht immer gibt der Blue Screen of Death selbst diese Auskunft.
Oft ist das einfacher, als man ob der kryptischen Daten vielleicht meint. Dieser Guide soll eine Anleitung dazu geben.
- Zunächst besorgen wir uns die Debugging Tools für unsere Plattform: 32Bit 64Bit.
- Dann starten wir windbg - Wichtig: Als Administrator ausführen!
- Im File Menü, klicken wir auf Symbol File Path.
- Im Symbol Path Fenster geben wir folgendes ein:
"srv*c:\cache*http://msdl.microsoft.com/download/symbols;"
und bestätigen mit 'ok'
- Im File Menü wählen wir "open crash dump..." und wählen unter c:\Windows\Minidump das File aus, das wir analysieren wollen - in der Regel das neueste.
Bei mir gab es ja schon einige Crashes - es wird also Zeit dass ich dem Übeltäter auf die Spur komme. Für jeden Crash liegt ein Crash Dump File mit einem Namen wie Mini102107-03.dmp in dem Verzeichnis.
- Jetzt ein paar Sekunden auf das Ergebnis warten - Falls die Firewall sich meldet - es wird versucht auf die Symbol Files unter msdl.microsoft.com/download/symbols zuzugreifen - muss man die Firewall Warnung bestätigen, windbg schliessen und noch einmal bei Punkt 2 bestätigen.
- Im Ergebnisfenster sucht man die Zeile "Probably caused by: " - Danach steht der Übeltäter fest:
Mit einer guten Suchmaschine findet man schnell näheres heraus, dann einfach eine neue Treiberversion vom Hersteller herunterladen und das Problem sollte behoben sein.
Möchte man mehr wissen, kann man noch !analyze -v ausführen und bekommt dann noch genauere Hinweise:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 88651030, Physical Device Object of the stack
Arg3: 8855a3d0, Functional Device Object of the stack
Arg4: 86225950, The blocked IRP
In meinem Fall war also der Übeltäter usb8023x.sys - der Remote NDIS USB driver.
Ach ja - das für mich überraschende Ergebnis meiner Websuche:
http://support.microsoft.com/kb/931671/en-us
Der Treiber dürfte in meinem konkreten Fall also ein Windows eigener Treiber sein und der Bugfix ist über den oben genannten Knowledge Base Artikel erhältlich. Hoffen wir dass damit meine Bluescreen Probleme behoben sind...
The Hidden Guide: How To Analysis Crash Dump