Nach dem nächsten Crash den Memory-Dump zu Analysezwecken auf eine andere Maschine kopieren.
Von Microsoft das
Debugging Tool für Microsoft Windows herunterladen und installieren. Auf der gleichen Seite gibt es auch die Symbol-Dateien, die exakt zum installieren Betriebssystem passen müssen. Es gibt hier zwei Möglichkeiten:
------------------------------
[1] entweder (nicht empfohlen)
=> passende Symboldateien herunterladen und in C:\Symbols speichern im Debugging-Tool im Menü "File" unter "Symbol File Path" C:\Symbols angeben
------------------------------
[2] oder (empfohlene Methode)
=> leeren Ordner C:\Symbols anlegen und im Debugging-Tool im Menü "File" unter "Symbol File Path" folgende Zeile eingeben:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
------------------------------
Hier bitte auch den Haken in der Checkbox "Reload" setzen und die Einstellung schließen. Anschließend im File-Menü den Menüpunkt "Open Crash Dump" auswählen und das vorher gesicherte Dump-File (per default MEMORY.DMP) zur Analyse auswählen.
Von nun an verhält sich das Anaylse-Tool nicht gerade transparent, es ist für den einfachen Benutzer nicht wirklich zu erkennen, ob das Tool noch arbeitet oder wie weit die Arbeit fortgeschritten ist. Die Abfrage nach dem Speichern des "Work Place" kann verneint werden, eventuelle Meldungen zu fehlenden Symbols-Dateien können ignoriert werden, sofern die obige Anweisung zu dem Symbols-Dateien entsprechend ausgeführt worden ist (bei aktiver Internet-Verbindung ist die zweite Alternative vorzuziehen).
In der unteren Zeile des Debug-Fensters, dass wie ein Texteditor aussieht, sollte nach einiger Zeit ein Cursor blinken. Hier bitte den Befehl
!analyze -v
eingeben. Das Tool arbeitet wieder (auf langsamen Rechnern kann's dauern...), es erscheinen verschiedene Meldungen. Man kann sich den ganzen Inhalt in einen Texteditor kopieren und zur Weiterverarbeitung sichern. Man kann hier so einiges erkennen, aber vorzugsweise sollte der unbedarfte Benutzer nach folgendem Eintrag suchen:
Probably caused by
Hinter diesem Eintrag steht ein Dateiname. Es liegt nahe, dass diese Datei das Problem verursacht. Von jetzt an ist professionelles Arbeiten angesagt. Es gilt, einige Fragen zu klären wie zum Beispiel: zu welchem Programm gehört die Datei, wann und wo wird sie gestartet.
Da es sich meistens um Treiber, ggf. sogar um Kernel-Treiber handelt, kann man ja mal schauen, ob eine solche Datei unter den Treibern zu finden ist. Unter XP und 2k3 Server hilft da auf Kommandozeile der folgende Befehl:
sc query type= driver
Ist die Ausgabe zu lang, kann man sie natürlich auch in eine Datei umleiten und dann wieder mit einem Texteditor durchforsten. Sollte sich der Dateiname hier wiederfinden, hilft es vielleicht, diesen Treiber zu deaktivieren, wenn es nicht gerade der Treiber für den Boot-Controller ist, das würde eine "inaccessible bootdevice" Stopmeldung nach sich ziehen. Man kann den Treiber dann mit folgendem Befehl deaktivieren:
sc config treibername start= disabled
Solch gravierende Eingriffe sollten aber nur von Profis vorgenommen werden. Vorher empfiehlt sich in jedem Fall ein Backup des Systemzustandes oder mindestens die Sicherung der Registrierung mit einem geeigneten Programm wie ERUNT.
