High memory, CPU, or other performance problems with .NET

The most common problems we see with ASP.NET (or any .NET application) are high memory and high CPU utilization.

The main issue that will cause this is rather simple to fix and rather simple to look for.  Any time there are issues around these things, the very first thing to check is if debug=true is set in the compilation section of the web.config file.  You can simply open up that file to see, or if you are looking at a dump file, you can also get that information out of the dump.

Note that in 2.0, debug=false is the default and we do much more to caution users about setting this so this tends to be less of a problem in 2.0 and later versions of .NET

In versions prior to 2.0, to check in a dump if debug is turned on, you run a command out of the debugger extension sos.dll that is installed with the debugger package.   A brief note about this extension.  This is like the sos.dll that ships with .NET but with some additional commands and some performance improvements.  It should load automatically for you when opening a dump containing .NET data, but if not, you can load it by running:

   .load clr10\sos

This version will work against .NET 1.0 and 1.1 dumps.  To see if debug is enabled, simply run:

   0:000> !clr10\sos.finddebugtrue
  Debug set to true for Runtime: 1350ba8, AppDomain: /Test
  Debug set to true for Runtime: 53a511c, AppDomain: /TestDebug
  Total 2 HttpRuntime objects

Another common thing to look for are modules that are built debug.  You can check inside Visual Studio for these, but that can be difficult sometimes to tell with production.  So you can check this using a dump and the same extension by running:

   0:000> !clr10\sos.finddebugmodules
  Loading all modules.
  Searching for modules built in debug mode... 


  test.dll built debug
  hbdp25u7.dll built debug
  1gxdnryw.dll built debug
  fzgq0g7y.dll built debug
  fhlpqzqm.dll built debug
  su0utu5-.dll built debug
  vhaewyii.dll built debug
  tdkuail7.dll built debug


  Searching for modules built in release mode with the /debug switch...


  Done Seaching
  Total 8 Debug modules
  Total 0 release modules with the /debug switch

ScottGu has some more interesting info on this on:

https://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

And even more helpful information from MSDN:

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

Comments

• Anonymous
  December 26, 2007
  The comment has been removed

• Anonymous
  November 18, 2010
  So, um, how do I get the debugger mentioned, how do I get to .load clr10sos? A lot is being assumed about me knowing what you're talking about....

• Anonymous
  January 04, 2011
  Owen, support.microsoft.com/.../892277 is a good place to start.