Blue Screen Of Death (BSOD)

Microsoft MiniDump Dateien debuggen

Blue Screen Of Death (BSOD)Wenn ein Windows Computer mit einem sogenannten Blue Screen Of Death (BSOD, Blauer Schirm des Todes) abstürzt, dann werden die Fehlerinformationen in einem Speicherabbild gespeichert. Dieses wird als Datei im Verzeichnis C:\Windows\Minidump abgelegt. Das Verzeichnis existiert in der normalen Windows-Ordnerstruktur nicht, sondern wird beim ersten BSOD angelegt.

Minidump-Dateien sind kompilierte Dateien, die man mit den Debugging Tools für Windows, die kostenlos auf der Microsoft-Seite verfügbar sind, öffnen, einsehen und interpretieren kann. Zusätzlich zu den Tools benötigen Sie noch Symbol-Dateien. Diese können Sie ebenfalls kostenlos von Microsoft herunter laden. Hier die Speicherorte:

Bei den Symbol-Dateien müssen Sie sich die entsprechenden Dateien für das jeweilige Betriebssystem, das abgestürzt ist, herunterladen. Installieren Sie dann die Tools und danach die Symbols. Bitte beachten Sie auch, dass Sie mit einem 64-Bit Debugger sowohl 32-Bit als auch 64-Bit Dateien debuggen können, nicht aber mit einem 32-Bit Debugger 64-Bit Dateien (also Minidumps, die von 64-Bit Maschinen generiert wurden).

Den Windows-Debugger WinDbg einrichten

  • Nach der Installation starten Sie das Programm WinDbg.
  • Dann gehen Sie auf Files->Symbol File Path… (alternativ drücken Sie Strg+S)
    WinDbg Fenster Symbol Search Path

    • Hier geben Sie den folgenden Wert ein:
      SRV*C:\Windows\Symbols*http://msdl.microsoft.com/download/symbols

      • Wobei Sie C:\Windows\Symbols bitte mit dem Pfad ersetzen, unter dem Sie die Symbols installiert haben.
  • Danach gehen Sie auf Files->Image File Path… (alternativ drücken Sie Strg+I)
    WinDbg Fenster Image Search Path
  • Hier geben Sie den folgenden Wert ein:
    C:\Windows\System32

    • Wobei Sie C:\Windows durch das Windows-System-Verzeichnis ersetzen.

Die MiniDump Datei öffnen

  • Gehen Sie auf Files->Open Crash Dump (alternativ drücken Sie Strg+D)
  • Wählen Sie die .dmp Datei aus und öffnen Sie diese
  • Der Debugger startet und verbindet sich mit der Datei. Sobald er fertig ist, sehen Sie am Ende des Vorgangs einen Link !analyze -v. Klicken Sie diesen und warten Sie den Debug-Vorgang ab.

Im Video erkläre ich Ihnen, wie Sie die Ergebnisse interpretieren können.

httpvhd://www.youtube.com/watch?v=9JKUr4wNwYc

Somit wünsche ich Ihnen noch viel Erfolg bei der Fehlersuche und freue mich auf Ihre Meinung, Anregungen und Kommentare.

3 comments

  1. J.C. Denton says:

    Wenigstens einmal ein Vernünftiger Artikel. Würden sich mehr Menschen damit auseinandersetzen und ordentlich diagnostizieren, dann könnte man sich Millionen Forenbeiträgen, IRC-Logs und Support-Tickets bei Softwareherstellern sparen. Ich als Ubuntu-Developer und Sysadmin einer heterogenen Umgebung sehe die Probleme täglich. Debugging ist das A&O um zu vernünftigen Aussagen gelangen zu können und umso wichtiger je teurer die Systeme und je irrelevanter die Personalkosten sind. Ein Verständnis von der Systemmechanik vorausgesetzt kann so schnell ein Problem erkannt und gelöst werden. Dies u.U. Sogar viel kostengünstiger als durch trail and error. In einer Welt in der jedoch alles schnell aus dem Fenster geworfen und neu gekauft wird – gleich ob Systemhardware oder -software – ist die Fähigkeit debuggen zu können jedoch eine Randerscheinung und eher, als zum Reich der Entwickler zugehörig, zu betrachten. Dies ist gerade vor dem Hintergrund immer knapperer Ressourcen jedoch äußerst bedauerlich.

  2. J.C. Denton says:

    Wenigstens einmal ein Vernünftiger Artikel. Würden sich mehr Menschen damit auseinandersetzen und ordentlich diagnostizieren, dann könnte man sich Millionen Forenbeiträgen, IRC-Logs und Support-Tickets bei Softwareherstellern sparen. Ich als Ubuntu-Developer und Sysadmin einer heterogenen Umgebung sehe die Probleme täglich. Debugging ist das A&O um zu vernünftigen Aussagen gelangen zu können und umso wichtiger je teurer die Systeme und je irrelevanter die Personalkosten sind. Ein Verständnis von der Systemmechanik vorausgesetzt kann so schnell ein Problem erkannt und gelöst werden. Dies u.U. Sogar viel kostengünstiger als durch trail and error. In einer Welt in der jedoch alles schnell aus dem Fenster geworfen und neu gekauft wird – gleich ob Systemhardware oder -software – ist die Fähigkeit debuggen zu können jedoch eine Randerscheinung und eher, als zum Reich der Entwickler zugehörig, zu betrachten. Dies ist gerade vor dem Hintergrund immer knapperer Ressourcen jedoch äußerst bedauerlich.

Schreibe einen Kommentar

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