Clarifications on Debugging

When I'm talking to ASP.NET developers who are experiencing memory issues, crashes, hangs, etc., I will often say, "Hook up the debugger and see what's going on." More often than not, the response that I get from that recommendation is one of confusion. Most developers think of "the debugger" as Visual Studio or some other source code debugger. In fact, when I say "the debugger", I'm talking about Windbg, a debugger included in the Debugging Tools for Windows.

Windbg allows you to do most of the same debugging tasks that you can perform in Visual Studio, but it has additional capabilities. Those additional capabilities come at the price of being a bit harder to learn how to use. But hey, if you are an ASP.NET developer, you're obviously smart enough to learn new tricks. Learning to use Windbg is definitely a trick worth learning.

Suppose you have an ASP.NET application that consumes large amounts of memory over time. If you want to find out what's taking up so much memory, you can profile the application. However, there are some serious drawbacks to taking that approach. Profiling is expensive from a performance standpoint. In fact, in a production environment, running a profiler is most often not an option. What's a developer to do? I have an answer! You can use the Debugging Tools for Windows to create a user-mode dump file which can then be analyzed with Windbg to determine where you are consuming memory.

First thing you'll need to do is create a dump file. The easiest way to do that is to use ADPlus. Here's an article that will walk you through that process:

286350 How to use ADPlus to troubleshoot "hangs" and "crashes"
https://support.microsoft.com/default.aspx?scid=kb;EN-US;286350

After you've got a dump file, you'll need to set up Windbg to debug it. I wrote an article on this about a year ago. While I certainly wouldn't claim that this article is the best resource available on the subject, it's one that I have handy so it's what you're going to get. :)

892277 Troubleshooting ASP.NET using WinDbg and the SOS extension
https://support.microsoft.com/default.aspx?scid=kb;EN-US;892277

Note that this is all 1.x specific.

The article above is a crash dump analysis, and a very simple one at that. If you want details on how to debug memory issues, your best bet is to review our PAG documentation. It's excellent information for debuggers.

https://msdn2.microsoft.com/en-us/library/ms954594.aspx

From here on out, I'll try to provide you with some cool debugging tricks that come straight from the work that I do everyday. Hopefully it will be useful to you in your debugging endeavors!

Jim

Comments

• Anonymous
  February 28, 2007
  It's pretty common for me to work cases where something bad happens when an ASP.NET application is accessing

• Anonymous
  July 26, 2007
  The PAG link seems to be broken

• Anonymous
  July 26, 2007
  Fixed. Thanks.