Windows BlueScreen-Analyse – Teil 3

In Teil 1 habe ich skizziert, wie sich ein automatisch startendes System so disziplinieren lässt, dass der Benutzer die Meldungen eines Blue Screens ablesen kann. In Teil  2 wurde gezeigt, wo Dump-Dateien gespeichert werden und wie sich deren Optionen anpassen lassen. Nun möchte ich auf die Auswertung von .dmp-Dateien eingehen.


Werbung



Dump-Dateien mit dem BlueScreenView analysieren

Zur schnellen Analyse einer Dump-Datei lässt sich das Tool BlueScreenView von Nirsoft verwenden. Das Programm kann kostenlos von dieser Webseite heruntergeladen werden. Das Programm liest nach dem Start automatisch die .dmp-Dateien aus dem Windows-Ordner Minidump aus. Der Ordner lässt sich aber über die Schaltfläche Advanced Options der Symbolleiste anpassen.

Anschließend zeigt es die Modulliste sowie eventuell die Einträge, die den Fehler verursachen, an. Alternativ kann der BlueScreen abgerufen werden. Die Auswahl der Darstellung erfolgt über das Untermenü Lower Pane Mode des Menüs Options.

In manchen Fällen kann mit diesem Ansatz die Ursache für den BSOD auf die Spur. Allerdings hat BlueScreenView seine Grenzen und zeigt gelegentlich sogar in die falsche Richtung. Hier kommt man nur mit einer Analyse der .dmp-Datei per WinDbg weiter.

Wo bekomme ich WinDbg her?

Der Windows-Debugger WinDbg wird von Microsoft kostenlos im Rahmen des Windows SDK angeboten [a, b]. Unter [c] hat Microsoft einen Artikel zum Installieren mit den Download-Links veröffentlicht. Allerdings ist es etwas doof, ein mehrere hundert Megabyte großes SDK herunterzuladen, nur um einen Debugger installieren zu können.

Nach ein wenig Suche bin ich aber auf die unter [d] verlinkte Blogseite gestoßen. Dort finden sich Links, um die Windows-Debugger in einer 32- oder 64-Bit-Version als Standalone-Version herunterzuladen. Nach dem Entpacken der ZIP-Archive lässt sich der Debugger installieren. Weiterhin gibt es das unter [e] verlinkte MSDN-Archiv, in dem sich die installierbaren .msi-Dateien befinden.

Achten Sie lediglich darauf, einen 64-Bit-Debugger zu verwenden, um Dump-Dateien von 32- und 64-Bit-Systemen zu analysieren. Bei Dump-Dateien von 32-Bit-Systemen lässt sich auch ein 32-Bit-Debugger einsetzen.

a: Debugging Tools for Windows 32-bit Versions
b: Debugging Tools for Windows 64-bit Versions
c: Download and Install Debugging Tools for Windows
d: Standalone windbg Downloads
e: Standalone windbg Downloads (MSDN-Archiv)

WinDbg einrichten

Ist WinDbg installiert, muss das Programm vor der ersten Verwendung eingerichtet werden. Hierzu starten Sie WinDbg, öffnen das Menü Datei und wählen den Befehl Symbol File Path.


Werbung

Anschließend tragen Sie im Dialogfeld Symbol File Path den String zum Symbolcache und zum Download-Pfad ein.

srv*c:\cache*http://msdl.microsoft.com/download/symbols

Das Sternchen in obigem String füllt die Leerzeichen im String. Die Angabe c:\cache legt den Pfad zum Symbolcache fest. Hier habe ich einen Ordner cache auf dem Laufwerk C: verwendet. Mit der Angabe:

http://msdl.microsoft.com/download/symbols

wird die Download-Adresse für die Symboldateien festgelegt. Dieser String muss korrekt definiert werden. Sie können sich unter [g] zusätzliche Symboldateien für diverse Windows-Versionen lokal herunterladen und dann in den Cache-Ordner kopieren. Dies hat den Vorteil, dass der Debugger sofort über die benötigten Symbolpakete verfügt – es muss nichts online vom Symbol-Server heruntergeladen werden. Zudem scheinen diese Symbolpakete vollständiger als die Pakete des Symbol-Servers zu sein. Nachteil ist aber, dass die Pakete recht umfangreich (750 MB bis 1 GB) sein können.

f: Debugger einrichten und debuggen
g: Zusätzliche Symboldateien MSDN-Download-Seite
h: Debug-Symbole herunterladen

Achtung: Die im Internet zu findenden Anleitungen (z. B. hier und hier) zum Festlegen dieses Strings sind teilweise problematisch, weil oft Fragezeichen, Anführungszeichen oder Blanks im Beispielstring verwendet werden. Ich habe viele Stunden der Fehlersuche verbracht, weil der Debugger nicht korrekt funktionierte. Beim hier verlinkten Beitrag sind die Screenshots zwar korrekt. Man sollte man das Video am Ende (wo es um die Interpretation der Ergebnisse geht) aber mit Vorsicht genießen.

Hinweis: Wird beim Debuggen der Text “Debuggee not connected” in der Statusleiste angezeigt? Dies ist kein Grund zur Sorge, der Debugger lädt dann Symboldateien, was eine Zeitlang dauern kann.

Dump-Dateien analysieren

Ist WinDbg eingerichtet, lassen sich .dmp-Dateien analysieren. Hierzu kopieren Sie die .dmp-Datei in einen lokalen Ordner und starten den Debugger WinDbg. Anschließend öffnen Sie das Menü File und wählen den Befehl Open Crash Dump. Dann ist die .dmp-Datei im Dialogfeld Open Crash Dump auszuwählen und über die Öffnen-Schaltfläche zu laden.

Anschließend sollten die Dump-Inhalte angezeigt werden. Hier ist das Fenster des Debuggers mit der Auswertung eines Dumps zu sehen. Am unteren Fensterrand findet sich ein Statusangabe (hier *BUSY*, d. h. WinDbg arbeitet noch) sowie ein Textfeld zur Befehlseingabe.

Im aktuellen Fall wird gemeldet, dass die Dump-Datei eine Ausnahme (Exception) aufweist. Diese kann mittels des Befehls .ecxr. ausgewertet werden. Hier ein Auszug aus einer solchen Auswertung:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(d48.85c): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=05e328b0 ecx=0768c3b0 edx=0523faf0 esi=05e32870 edi=0523ef30
eip=77590be2 esp=0523ebf0 ebp=0523ec00 iopl=0    nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
ntdll!NtGetContextThread+0x12:
77590be2 83c404         add     esp,4
0:002> .ecxr.
eax=3031007d ebx=31333837 ecx=0768c3b0 edx=0523faf0 esi=0768c3b0 edi=0523faf0
eip=111a7135 esp=0523faac ebp=0523fad4 iopl=0   nv up ei pl nz na pe nc
cs=0023  ss=002b s=002b es=002b  fs=0053  gs=002b    efl=00010206
Unable to load image C:\Program Files
(x86)\VMware\VMware Player\vmwarebase.DLL, Win32 error 0n2
*** WARNING: Unable to verify timestamp for vmwarebase.DLL
*** ERROR: Module load completed but symbols could not be loaded for vmwarebase.DLL
vmwarebase+0xa7135:
111a7135 8b7004 mov esi,dword ptr [eax+4] ds:002b:30310081=????????
^ Extra character error in '.ecxr.'

Mit dem im Testfeld eingegebenen Befehl !analyze –v lässt sich eine weitgehend automatisierte Analyse des Dumps starten. Besteht eine Online-Verbindung, versucht der Debugger Kontakt zu einem Microsoft-Server aufzunehmen, um Crash-Lösungen aus einer Datenbank zu beziehen. Hier ein Auszug aus einer solchen Analyse:

0:002> !analyze –v
*******************************************************************************
*
*
*  Exception Analysis
*
*
*
******************************************************************************

 

*** WARNING: Unable to verify timestamp for vmdbCOM.dll
*** ERROR: Module load completed but symbols could not be
loaded for vmdbCOM.dll
*** WARNING: Unable to verify timestamp for vmplayer.exe
*** ERROR: Module load completed but symbols could not be
loaded for vmplayer.exe
*** WARNING: Unable to verify timestamp for shell32.dll
GetPageUrlData failed, server returned HTTP status 404
URL requested:
http://watson.microsoft.com/StageOne/vmplayer_exe/7_0_1_11056/4b5a7e23/
vmwarebase_DLL/7_0_1_11056/4b5a7259/c0000005/000a7135.htm?Retriage=1

FAULTING_IP:
vmwarebase+a7135
111a7135 8b7004          mov     esi,dword ptr [eax+4]

EXCEPTION_RECORD:  ffffffff — (.exr 0xffffffffffffffff)

ExceptionAddress: 111a7135 (vmwarebase+0x000a7135)

ExceptionCode: c0000005 (Access violation)

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000
Parameter[1]: 30310081

Attempt to read from address 30310081

PROCESS_NAME:  vmplayer.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 – Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 – Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  30310081

READ_ADDRESS:  30310081

FOLLOWUP_IP:

vmwarebase+a7135

111a7135 8b7004          mov     esi,dword ptr [eax+4]

 

MOD_LIST: <ANALYSIS/>

APPLICATION_VERIFIER_FLAGS:  0

FAULTING_THREAD:  0000085c

BUGCHECK_STR:  APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_
not_busy_INVALID_POINTER_READ

PRIMARY_PROBLEM_CLASS:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy

DEFAULT_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy

LAST_CONTROL_TRANSFER:  from 111a063a to 111a7135

STACK_TEXT: 

WARNING: Stack unwind information not available. Following frames
may be wrong.

0523fad4 111a063a 0523faf0 026d6170 00000000 vmwarebase+0xa7135
0523fb18 111a0958 055d7220 026d6170 055d7220 vmwarebase+0xa063a
0523fb38 111a0f5c 026d6170 05433840 054a09b8 vmwarebase+0xa0958
0523fc9c 111a7b1d 05801778 026d82a0 026d7e58 vmwarebase+0xa0f5c
0523fcdc 1101a342 00000001 01770000 0523ff88 vmwarebase+0xa7b1d
0523fcec 1101a54a 02020002 536e6957 206b636f vmdbCOM+0x1a342
0523ff88 76bf3677 00000002 0523ffd4 775a9d72 vmdbCOM+0x1a54a

0523ff94 775a9d72 026d7e58 7221c32b 00000000
kernel32!BaseThreadInitThunk+0xe
0523ffd4 775a9d45 1101a480 026d7e58 00000000
ntdll!__RtlUserThreadStart+0x70
0523ffec 00000000 1101a480 026d7e58 00000000
ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  !heap ; ~2s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  vmwarebase+a7135

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vmwarebase

IMAGE_NAME:  vmwarebase.DLL

DEBUG_FLR_IMAGE_TIMESTAMP:  4b5a7259

FAILURE_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_
c0000005_vmwarebase.DLL!Unknown

BUCKET_ID:  APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_
block_not_busy_INVALID_POINTER_READ_vmwarebase+a7135

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/vmplayer_exe/7_0_1_11056/
4b5a7e23/vmwarebase_DLL/7_0_1_11056/4b5a7259/c0000005/000a7135.htm?Retriage=1

Followup: MachineOwner

———

 

An Hand der so ausgeworfenen Informationen gilt es nun, die Fehlerursache zu analysieren.

Hinweis: Beachten Sie, dass der Zugriff auf die Datenbank und die Analyse der Dump-Dateien eine ganze Zeit dauern kann. Die Anzeige *BUSY* im Statusbereich des Debugger-Fensters signalisiert, dass der Debugger noch mit der Analyse befasst ist. Der Text Debuggee not connected im Textfeld der Statusleiste ist ein Hinweis, dass keine Verbindung zum Microsoft-Symbolserver bzw. zur Dump-Datei besteht. Bei mir tritt diese Meldung z. B. auf, wenn der Debugger gestartet aber noch keine Dump-Datei geladen ist. Der zweite Fall für die Meldung liegt vor, wenn Symboldateien vom Microsoft-Server heruntergeladen werden müssen. Die Meldungen sollten aber nach einer gewissen Wartezeit verschwinden. Zudem habe ich zusammen mit Michael Bormann die Erfahrung gemacht, dass die heruntergefahren Symboldateien durchaus auch schon mal beschädigt werden können – so dass WinDbg bei der Analyse Mist macht. Dann hilft nur noch, den Symbol-Cache zu löschen und die Symbollisten neu aufbauen zu lassen.

Die Kunst ist es nun, möglichst viele Informationen über das System zu erhalten. Mit dem Befehl !sysinfo cpuinfo sollten CPU-Informationen angezeigt werden.

Mit dem Befehl lmnt lässt sich die Modulliste abrufen. Diese gibt u. U. Hinweise, ob ältere Module (Treiber) oder andere problematische Komponenten geladen sind und der Grund für den BlueScreen sein können.  Hier ein Auszug aus einer solchen Liste

0:036> lmnt
start             end                 module name
00000000`02580000 00000000`0259c000   MACDRAPI MACDRAPI.DLL Tue May 06 21:02:43 2008 (4820AB53)
00000000`02d80000 00000000`02da5000   XPCopyHook XPCopyHook.dll Thu Dec 17 21:33:30 2009 (4B2A959A)
00000000`09b70000 00000000`09d42000   nvui     nvui.dll     Sat Oct 16 19:03:07 2010 (4CB9DACB)

Es wird hier eine DLL aus dem Jahr 2008 verwendet, obwohl Windows 7 erst 2009 veröffentlicht wurde. Der Debugger kennt eine Reihe weiterer Befehle, um die Dump-Datei zu analysieren.

Tipp: Soll das Debuggen beendet und eine neue .dmp-Datei geladen werden, müssen Sie den Debugger erst stoppen. Die betreffenden Befehle finden Sie im Menü Debugg.

Wo gibt’s Hinweise zu WinDbg und zur BSOD-Analyse?

Das Einrichten und die Bedienung des Debuggers ist in der WinDbg-Hilfe beschrieben (aufrufbar über das Hilfe-Menü des Debugger-Fenstes). In der WinDbg-Hilfe finden Sie auch Hinweise, wie sich Dump-Dateien analysieren lassen.

Zudem gibt es unter [i] weitere Hinweise, wie sich Dump-Dateien analysieren lassen.

i: www.windbg.org Debugging Infos
j: Debug-Hinweise
k: Weitere Debug-Analyse-Hinweise

Bücher zu Dump-Analyse

Wer mehr über die Analyse von .dmp-Dateien erfahren möchte, findet im BOD-Titel “In den Abgrund gezogen” eine Anleitung. Auf 164 Seiten beschreibt Michael Bormann, Microsoft MVP und MSA-Communitymoderator, die Analyse von Dump-Dateien zur BlueScreen-Ursachenanalyse in deutsch. Details sind hier zu finden.

Michael Bormann: In den Abgrund gezogen
ISBN 978-3-8448-1742-3, Paperback,
168 SeitenWeitere englischsprachige Bücher zur Memory Dump-Analyse gibt es hier bei Amazon.de

Ähnliche Artikel:
1: Windows BlueScreen-Analyse – Teil 1
2: Windows BlueScreen-Analyse – Teil 2
3: Windows BlueScreen-Analyse – Teil 3


Werbung
Weitere Infos zu Windows 7 finden sich in meinen Windows 7-Titeln


Werbung

Dieser Beitrag wurde unter Windows 7, Windows 8 Beta, Windows Vista abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Ein Kommentar zu Windows BlueScreen-Analyse – Teil 3

  1. Pingback: Bluescreeen System Service Exception stop 0x0000003b - Seite 2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.