Vor einiger Zeit habe ich ein kleines Einsteigertutorial zum Umgang mit WinDbg geschrieben. Etwas später folgte dann auch ein kurzes Video hierzu.
Sowohl im Tutorial als auch im Video war eine Windows Forms Anwendung das Ziel meiner Debuggingaktivitäten. In einem kurzen Nebensatz erwähnte ich, dass die Zielanwendung bei der gezeigten Vorgehensweise, nämlich dem direkten Anhängen an den Prozess der Wahl, zumindest zeitweise blockiert wird.
In einer Windows Forms Anwendung mag dies kein Problem sein, schließlich bin ich ja alleine auf dem System. Unschön wird es jedoch, wenn man Probleme in einer produktiven ASP.NET Anwendung sucht. Verständlicherweise reagieren hier nämlich die wenigsten Anwender erfreut, wenn die Website steht weil gerade jemand im Hintergrund daran herumfummelt. Außerdem ist es je nach IT Richtlinie auch problematisch den lokalen Administrator des Kundens davon zu überzeugen, dass man mal gerade physikalisch oder auch nur per Remote Desktop an seinen Webserver will.
Und nun?
Abhilfe schafft hier die VBScript Datei adplus.vbs innerhalb des WinDbg Verzeichnisses. Sie ermöglicht es, ein aktuelles Speicherabbild des problematischen Prozesses in Form einer *.DMP Datei zu erstellen. Diese kann wiederum in WinDbg geöffnet und analysiert werden.
Adplus kann in zwei verschiedenen Modi genutzt werden: hang und crash.
Im hang Modus wird einmalig ein aktueller Memory Dump des Prozesses zum Zeitpunkt der Ausführung des Scripts gezogen. Dieser Modus eignet sich besonders wenn die Applikation “hängt” ;-), also in Deadlock Szenarien, oder aber auch um Memory Leaks zu finden. Zur besseren Analyse sollten im Fall ein Memory Leaks jedoch mehrere Dumps bei verschieden hoher Speicherauslastung gezogen werden.
Der Befehl zum Erzeugen eines Dumps im hang Modus lautet übrigens:
adplus.vbs -hang -p processId
Die Id des Prozesses kann entweder über den Taskmanager, oder aber im Fall einer ASP.NET Anwendung die in einem IIS 6 gehostet wird, über den Befehl IISAPP gefunden werden.
Alternativ zum Parameter -p kann über den Parameter -pn auch ein Prozessname angegeben werden. Im Fall einer ASP.NET Anwendung wäre dies also W3WP.exe (Windows Server mit IIS) bzw. WebDev.WebServer.exe im Falle des lokalen Entwicklungsservers. Außerdem kann über den optionalen Parameter -o auch ein dediziertes Ausgabeverzeichnis angegeben werden. Standardmäßig wird nämlich sonst ein Unterverzeichnis, unterhalb des Ordners aus dem adplus heraus aufgerufen wurde, angelegt.
Innerhalb des Zielverzeichnisses wird nun eine Datei mit der Endung .DMP angelegt. Diese kann in WinDbg über den Menüpunkt File -> Open Crash Dump … geöffnet und mit den bereits bekannten Befehlen analysiert werden.
Der zweite Modus neben hang ist der Modus crash.
Der Aufruf erfolgt hier ähnlich zum hand Modus, mit dem einzigen Unterschied, dass statt -hang -crash übergeben wird.
adplus.vbs -crash -p processId
Im Crash Modus bleibt der Debugger so lange am entsprechenden Prozess angehangen, bis dieser unfreiwillig beendet wird. Tritt dieser Fall ein, wird ein Dump auf die Festplatte geschrieben. Außerdem werden Dumps geschrieben, wenn ein zuvor definierter Breakpoint erreicht wird, oder aber eine access violation Exception auftritt.
Fazit
Mit adplus liegt ein leichtgewichtiges Skript zur Hand, dass bei der Problemanalyse innerhalb produktiver Umgebungen enorm helfen kann. Gerade in Umgebungen, in denen das Live-System nicht durch Debugging blockiert werden darf, oder aber der Administrator keinen Zugriff auf das System gewährt, kann das Skript seine stärken Ausspielen.