Memory Dumps on the fly

Ich hatte in einem unserer Release-Kandidaten ein massives Problem. In bestimmten nicht reproduzierbaren Situationen, blieb zeitgleich auf allen angeschlossenen Arbeitsstationen das Programm stehen. Und nun?

Der Deadlock, der auftrat war so fatal, dass ich nicht mal mehr über eine versteckte Funktion einen Speicherdump auslösen konnte. Dazu verwende intern üblicherweise eine reservierte Tastenkombination. Nur wenn keine Nachrichten mehr abgearbeitet werden, gibt es auch keine Funktionen, die man per Tastatur aufrufen kann.

Glücklicherweise wurde auf allen betroffen Rechner Windows Vista eingesetzt. Und die Lösung für diesen Fall ist unter Vista so einfach wie genial. Im Task-Manager unter Vista findet sich im Kontextmenü ein unauffälliger Menüpunkt: „Abbilddatei erzeugen“:

Memory dump on demand

Jupp! Er macht genau was ich brauchte. Durch diesen netten Befehl wird im %TEMP% Verzeichnis des Benutzers ein voller Speicherdump erzeugt.

Ich musste von 6 Dumps genau 2 durchsehen, bis ich das Problem lokalisiert hatte.
Eine wirklich nette und nützliche Funktion des Taskmanagers.

Unter Windows XP kann man ähnliches machen nur ist es hier ungleich komplizierter, aber es geht auch mit dem mitgelieferten symbolischen Debugger NTSD und den folgenden Schritten:

  • PID über den Task-Manager ermitteln (entsprechende Spalte einblenden lassen)
  • NTSD starten mit der entsprechenden PID
    NTSD -p 4656
  • Dump erzeugen:

    0:001> .dump /f c:\temp\crash\full.dmp
    Creating c:\temp\crash\full.dmp – user full dump
  • Wird der Debugger mit Quit (q) verlassen wird auch der Prozess beendet.

7 Gedanken zu „Memory Dumps on the fly“

  1. Die Frage die ich mir dann meist stelle ist, was erkenn ich nur aus solchen Dumps. 🙂 Ich schau da meist nur noch blind rein, vor allem wenn ich wirklich mal einen Deadlock habe, was ja durchaus auch schon vorgekommen ist, mir ist es meist lieber ich gehe per Remote-Debugging auf den Rechner.

  2. Ich lade den Dump in den Debugger.
    Dann besorge ich mir das Threads Fenster und beobachte den Callstack eines jeden Threads. In diesem Fall wartete der UI Thread auf einen CriticalSection nachdem er in einer Transaktion für eine DB mehrere Statements ausgeführt hatte.
    Leider hatte ein zweiter Thread begonnen diese CriticalSection zu sperren und durch eine falsches Design einen DB-Zugriff gestartet, was nie hätte passieren dürfen.
    Die Folge diese eine Applikation hat sich selbst lahmgelegt und da sie auch eine Transaktion für eine Tabelle ausführte war diese Tabelle für andere Stations auch gesperrt. Alles steht…

    Also als Tipp:
    – Dump in den Debgugger
    – Debuggen
    – Threadfenster besorgen
    – Callstacks der einzelnen Threads analysieren!

Schreibe einen Kommentar

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.