Windbg is the tool for the ASP.NET support engineer. It is free and it’s available at www.microsoft.com/whdc/devtools/debugging/default.mspx. The learning curve is steep to say the least, but if you’re interested in finding out what is going on behind the scenes in your application, then Windbg is your new best friend. For information on how to configure windbg, please refer to the documentation. Pay special attention to the section concerning symbols.
There is an extension called SOS.dll that you will want to use. You’ll find it in the framework directory so for Framework 2.0 look in “C:\Windows\Microsoft.NET\Framework\v2.0.50727”. You might want to copy it into the same folder as windbg for easy access.
Get a memory dump
Windbg will allow you to either perform a post mortem analysis on a memory dump or to attach to a process during execution. I mainly deal with memory dumps, since it’s a lot easier to request a single file from a customer rather than access to their server. Maybe I’ll cover live debugging in another post, but for now we’ll just look at dump files.
If you’re running Windows Vista, then you can easily create a dump file from the task manager. Simply open up the “Processes”-tab, right-click the process you wish to dump and select “Create Dump File”.
For any other system or if you want to specify certain conditions I’d recommend using a script called adplus. It comes with the Windbg installation and is run from the command prompt. Adplus will take a number of arguments, but for basic operation there are two things you need to specify:
- When to take the dump
- The name or process ID of the process you wish to take a dump of
The dumps generated by adplus will be saved to a subfolder of the folder where you’ve installed windbg.
This will generate a full memory dump right before any process named w3wp.exe terminates or recycles. This will also generate minidumps on all first chance exceptions.
Same as above, but without the minidumps.
This will immediately get a full dump of the process with ID 2960. Commonly used when the process has hung, or is generally unresponsive. Hence the name.
If you’re trying to pin down the cause of a specific exception, then you can use a config file. This is a sample config file that will create a full memory dump once a System.Runtime.InteropServices.COMException occurs. Simply copy the code below into notepad and save it as MyConfig.cfg.
<RunMode> CRASH </RunMode>
<Cmd> !load clr10\sos</Cmd>
<Option> NoDumpOnFirstChance </Option>
<Option> NoDumpOnSecondChance </Option>
<!– This is for the CLR exception –>
<Code> clr </Code>
<Actions1> Log </Actions1>
<CustomActions1> !clr10\sos.cce System.Runtime.InteropServices.COMException 1; j ($t1 = 1) ‘.dump /ma /u c:\dumps\exceptiondump.dmp;gn’ ; ‘gn’ </CustomActions1>
<ReturnAction1> GN </ReturnAction1>
<Actions2> Void </Actions2>
<ReturnAction2> GN </ReturnAction2>
As you can see you can easily adjust the config so that it gets a dump on any other exception. The dump will be saved in c:\dumps, so you should also make sure that this folder exists. When you’re ready, run adplus with the following syntax:
Debugging through a Terminal Server session
If you don’t have direct access to the server you need to either attach noninvasively or schedule the command you wish to run. This can seem a bit complicated, but there’s a pretty good howto written in the knowledge base under the following article: http://support.microsoft.com/default.aspx/kb/323478
Well I guess that’s all for now.