Unbeantwortete Themen | Aktive Themen Aktuelle Zeit: Mo 14. Jun 2021, 01:42



Auf das Thema antworten  [ 1 Beitrag ] 
 Windows 7: Minidump auslesen nach Bluescreen 
Autor Nachricht
Benutzeravatar

Registriert: Sa 20. Nov 2010, 12:04
Beiträge: 29
EEE PC: Ja
Modell: Eee PC 1005P
OS: Windows 7 HP
Mit Zitat antworten
Beitrag Windows 7: Minidump auslesen nach Bluescreen
Hallo ihr Lieben,

Ich habe hier für Euch eine Schritt-für-Schritt-Anleitung, um selbstständig die mysteriösen Bluescreens von Windows zu analysieren. Wahrscheinlich alles kalter Kaffee für die alten Hasen, aber vielleicht hilft es dennoch dem einen oder anderen Spielkind wie mir weiter ;-)
Getestet habe ich es mit dem aktuellen SDK unter Windows 7:


1. Vorbereitung

Um ein Minidump auswerten zu können, muß er überhaupt erst mal angelegt werden.
Dazu sollte in den erweiterten Systemeinstellungen das Kernelspeicherabbild eingeschaltet und "Automatisch Neustart durchführen" ausgeschaltet sein (der Pfad zum Minidump ist in der Regel %SystemRoot%MEMORY.DMP):

Bild

Nun benötigt man die richtige Version des Windows Debug-Tools WinDbg aus dem SDK, um die Minidum-Datei analysieren zu können:
a) 32-bit: [url='http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx']klick[/url]
b) 64-bit: [url='http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx']klick[/url]

Der Minidump ist eben nur Mini - für den großen Rundumschlag benötigt Windows einen Cache-Ordner, in dem die Binärdateien zur vollständigen Analyse geladen werden können und in dem die sogenannten Symbole der Abbilddatei gespeichert werden können. Hierzu muß zum einen ein Dateipfad mit einem Ordner angelegt werden, zum anderen wird dieser Dateipfad später im Debugger eingetragen.
Man erstellt also einen Ordner mit folgendem Pfad und Namen (Name ist aber frei wählbar):
c:\symbols

Nun die richtige Version des Debuggers installieren und diesen dann starten.
Der Debugger kontaktiert zur Analyse online den Windows-Server. Diesen muß man manuell als Sympol Path File eintragen, zusammen mit dem oben angelegten Pfad für die Symbole.
Dazu unter dem Menüpunkt File -> Symbol Path File (Strg + S) folgendes eintragen (eventuell den Teil "c:\symbols" durch den eigenen Pfad ersetzen):
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Bild

Als letzte Vorbereitung gibt man dem Debugger noch das Windows-Systemverzeichnis bekannt:
File -> Image File Path (Strg + I) auswählen und folgendes eintragen:
C:\Windows\System32

Bild


2. Analyse starten

Nun im Debugger unter File -> Open Crash Dumb (Ctrl + D) den Pfad zum gewünschten Minidump einstellen:

Bild

Der Debugger kontaktiert nun den oben eingestellten Windows-Server, erstellt die Symbole und bereitet die Analyse vor. Dies kann einige Zeit dauern.
Wenn er fertig ist, sieht man links unten im Fenter der Analyse die Zeichen:
0: kd>
Während er arbeitet steht dort:
*BUSY*

Im Textfeld findet man einen blau unterlegten Link mit Namen:
!analyze -v

Bild

Diesen anklicken, und es werden weitere Daten online abgefragt, was wieder einige Zeit dauern kann.
Eine weitere "Bug Check Analysis" taucht in dem Fenter auf. Diesmal mit mehr Informationen.

Interessant ist hier nun der Bereich DEFAULT_BUCKET_ID: Hier steht nun der erste Hinweis auf den Übeltäter - er bekommt ein Gesicht.
In meinem Beispiel findet man den den Eintrag
COMMON_SYSTEM_FAULT
(aha - dann ist ja alles klar...)

Bild

Etwas weiter unten wird es konkreter - man sucht nach den Einträgen:
IMAGE_NAME: und MODULE_NAME

Bild

Und lernt die Datei win32k.sys kennen - der Übeltäter bekommt einen Namen, auch wenn der "Peter Schmidt" der Windows-Dateien noch keine wirkliche Erleuchtung bringt.
Aber noch ist man nicht am Ende der Möglichkeiten: um an weitere Informationen zu kommen, muß man allerdings tiefer graben.


3. Ergebnis deuten

Um den Debugger mehr Informationen zu entlocken, braucht man zum Glück keine Kristallkugel - man kann unten im Fenster des Debuggers nebem dem Infofeld (mit dem Inhalt"0: kd>") weitere Parameter mitgeben.
Hier gibt man nun folgenden Befehl mit:
lmv

Bild

Wieder dauert das Ergebnis eine Weile. Wenn unten im Infofeld die Anzeige wieder von "*BUSY*" auf "0: kd>" umspringt, ist der Debugger fertig und man kann unter Edit -> Find (Ctrl + F) den Übeltäter weiter entzaubern (Suchrichtung beachten):

Bild

Etwas unterhalb des Suchergebnisses enttarnt sich der Schuldige endgültig. Der Eintrag FileDescription z.B. gibt Gewissheit:
Der Grafikkarten-Treiber quält das System ;-)

Bild

Weitere Infos zu dem Thema findet man hier: MS KB315263.

Das war´s!
Sollten sich noch Fehler eingeschlichen haben, bitte korrigieren.

Ab jetzt gibt es also keine Ausrede mehr - jeder kann selbst zum Analyse-Profi werden. Auch wenn die Suchergebnisse nicht immer leicht zu interpretieren sein werden, aber für Restzweifel gibt es ja noch das Forum.

lg
Deva

_________________
Eee PC 1005P - Atom N450
1,66GHz, 667 MHz FSB - Intel NM10 Chipsatz
1GB DDR2 RAM - WSVGA Display 10,1'' (non glossy)
160 GB HDD - WLAN 802.11 bg
3 x USB 2.0 - VGA - Audio In und Out
Cardreader SD, MMC (SDHC)
6 Zellen Li-Ionen Akku 4400 mAh / 40 Watt
Multitouch Touchpad - 1,27 kg
Win 7 Ultimate


Mi 15. Dez 2010, 14:18
Profil
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Auf das Thema antworten   [ 1 Beitrag ] 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.
Deutsche Übersetzung durch phpBB.de