Debugging a .NET application on a production server using WinDbg

I recently experienced a weird problem on a .Net application deployed to our production server.

 

The problem only occurred on the production server.

 

I was looking for a way to debug the process live on the server.

 

A quick Google search led me to Troubleshooting ASP.NET using WinDbg and the SOS extension (http://support.microsoft.com/kb/892277) and Debugging ASP.NET with the CLR Debugger (http://support.microsoft.com/kb/893657)

 

The latter solution seems very user friendly but also requires you to install the .NET Framework SDK. Hmm…Interesting solution but downloading and installing a 106.2 MB (.Net Version 1.1.) or 354.0 MB (.Net Version 2.0) package on the production Server just so I can use a debugger? I don’t think so. At least not today (I hope some one at Microsoft realizes the problem here and make a stand alone reasonably sized debugger install).

 

Ok so were left with the former solution….

 

Not bad only 15.8MB for WinDbg. The installation is very easy, takes very little time and does not require a restart, in short my favorite type of install.

 

I followed the instructions in the article and they are pretty straight forward. However, there are a couple of caveats that are worth mentioning and hopefully might save you some time and agony:

• When running the command line “cscript adplus.vbs -crash -pn aspnet_wp.exe -o c:\crashdump” you might see a message regarding a missing environment variable _NT_SYMBOL_PATH.

To solve the problem you can add an environment variable and set it to the debugger symbol path (e.g.: C:\Symbols). You can add an environment variable by pressing the right button on my computer and choosing properties and then advanced/environment variables… 

• To debug the asp.net process you will probably have to connect to your server remotely. If your server is running Windows 2000 and you are using a terminal services remote session, you can not debug a native process from another session. You can read Windows 2000 does not support cross-session debugging using a terminal server for more info. To solve this problem use the following trick. Although you can not debug the running process directly you can still make a snap shot of it and debug/examine the debug dump. The following command will take a snapshot of the asp net process:

        “cscript adplus.vbs -hang -pn aspnet_wp.exe -o c:\crashdump”

        Note the command line uses the –hang command line switch instead of the –crash.

• The article refers to using SOS extensions for debugging managed code. If you are running .Net 2.0 the following command “.load clr10\sos” will not work. Any command you try will give you the following descriptive message “Doesn’t work with 2.x”. To solve this problem use the “.loadby sos mscorwks” command instead. You can find more info about it here.