Wie schon im letzten Post angedeutet, sind wir auf der Suche nach einem Memory Leak in unserer ASP.NET-Anwendung. Nach etwas Lektüre, u.a. des sehr erhellenden Blogs von Tess Ferrandez, im speziellen des Posts zum Debugging Lab 3: Memory, wollte ich endlich WinDbg kennen lernen!
Anfänglich schien auch Debug Diagnostic Tool (v1.1) eine Option zu sein, aber leider installierte das x64-Paket nur das Analysetool, mit dem nicht viel anzufangen war, wenn man nicht vorher mit dem fehlenden DebugDiag ein paar Dumps erstellt (mit dem Leak-Tracking evtl. sogar eine super Sache).
Auf Vista-basierten und neueren Systemen kann man aber Memory-Dumps ganz einfach mit dem Windows-eigenen TaskManager erstellen, die landen dann in einem Temp-Ordner des aktuellen Benutzers (bei mir also C:\Users\Oliver\AppData\Local\Temp). Das dauert einen kleinen Augenblick und lässt den aktiven Prozess für die Zeit der Dumperstellung einfrieren, er wacht danach aber wieder auf und läuft normal weiter (für ein Live-System essenziell).
Hat man einen oder mehrere Dumps angefertigt, startet man WinDbg am einfachsten ohne jegliche Parameter direkt aus dem Datei-Browser heraus oder von der Kommandozeile. Dann benötigt man noch die SOS.dll (Erklärung hier), von der man eine aktuelle Version in den .NET-Framework-Verzeichnissen findet (in 32- oder 64-bit-Version, typischerweise C:\Windows\Microsoft.NET\Framework64\v2.0.50727). Hier benötigt man immer jeweils dieselbe Bittigkeit, die auch der Prozess hat(te), dessen Memory-Dump man sich anschauen will. Der Einfachheit halber kann man sich die SOS.dll einfach neben WinDbg.exe ablegen.
Als nächstes muss man den Symbolserver eintragen, damit wir als Menschen einfacher verstehen können, was sich hinter den Bytes an einer gegebenen Adresse im Speicher verbirgt. Am besten trägt man srv*c:\symbols\public*http://msdl.microsoft.com/download/symbols; c:/symbols in das u.g. Fenster ein, setzt den Haken bei Reload und klickt OK:
Jetzt können wir einen Dump laden und zwar über den Menüpunkt Open Crash Dump… (ist im obigen Bild ausgegraut, weil schon einer geladen ist). Danach sollte man als erstes die SOS.dll laden und zwar indem man am unteren Rand des geöffneten Fensters (in die Console) .load sos eingibt:
Wenn jetzt ein Fehler auftritt, dann wurde womöglich die falsche Version der SOS.dll geladen:
The call to LoadLibrary(sos) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
Einen Hinweis darauf fand ich (zum Glück) hier. Jetzt sind wir bereit, in den Speicher reinzuschauen. Was es dort zu sehen gibt, zeige ich im nächsten Post!
Oliver