Share via

A simple exe to find DEBUG build for managed modules and DEBUG attribute in Web.Config for Web applications in IIS 6/7

  • Article

CAVEAT: Some stories before I get to the point, so you may want to skip to the end.

We in Microsoft PSS get lot many cases on a daily basis which are related to performance issues with Web applications developed using ASP.Net and hosted on IIS. Based on my experience with debugging these issues many-a-times I have seen that one (or two) very basic step is often missed by our customers. Guess what, they develop the projects/class libraries/modules/assemblies etc (name it whatever you want) and test it thoroughly in the development/testing/staging environments and then go ahead and deploy the same binaries in the Production. What they overlook or tend to forget is that they are deploying the same DEBUG build modules/dlls in the production as against the recommended RELEASE builds/dlls.

Most of us know that for performance reasons it is always recommended to deploy a release build in the production as against a debug build to reap more benefits from compiler optimizations etc. The above observation is generic and applies to any application running managed code.

There is one more thing people often overlook when it comes in specific to IIS ASP.Net Web applications, i.e. DEBUG attribute in the Web.Config file under system.web/compilation tag. This is one setting which has a lot of repercussions on the performance of the Web applications running ASP.Net as a web technology like memory issues, fragmentations, etc.

A very nice detailed tutorial by Rahul (one of our former Technical leads in IIS/ASPNET support group) just reflects what I will never be able to convey any better. Check this link if you want to know more on how this DEBUG attribute may affect your application.

What we often do in support is that we capture memory dumps of the IIS process and analyze it using various tools (most common here being WinDBG). There are some public extensions available to our customers like sos.dll to debug managed memory dumps. However this extension has been deprecated (from .Net 2.0) and it does not have a feature to find out debug modules that were loaded in the IIS process and the value of the debug attribute set in the Web.Config file.

I felt that getting memory dumps from our customers and then finding out the above in their application settings and then recommending them to fix it just adds to the overall delay in finally fixing their core issue. This should be done by default. This is something that does not even need our support in the first place if people are well aware of it.

I wrote this tool just to help reduce their downtime or getting one step closer to their ultimate resolution. I know I write a lot so I will come straight to the point now :).

Point:

Feature 1:

This tool (I rechristened it as DebugFinder.exe) will attach non-invasively to any currently running process on the system and find out if any managed modules that are loaded is a DEBUG or a RELEASE build. This is applicable to any process and not only to Web applications. That way you can find out at run time which managed modules referenced in the current process are deployed as release versus debug builds. This helps keeps track of any debug build assembly that is being referenced from the GAC at runtime apart from the modules loaded from its current working directory if any. Once done it then detaches from the attached process without terminating it.

Feature 2:

We know that it is always recommended to have DEBUG attribute set to false in a Web.Config file in a production server.

This tool scans the machine for the Web applications that are configured in IIS. It looks for the Web.Config files corresponding to all the web applications configured in IIS and checks if they have the DEBUG attribute set to true or false and notifies in the display.

The Debug flag checking in the Web.Config file works for the web applications running either in IIS 6.0 or IIS 7.0/7.5 by this tool.

Pre-conditions:

  • DebugFinder has to be run locally on the machine where we want to get the debug related details (remotely may be in another version).
  • It needs .Net framework 2.0 to be installed on the machine for successful running.
  • Currently it is designed/tested for Win2k3/Vista/Win2k8/Win7 for finding Debug attribute in the Web.Config file.
  • If we have UAC turned on on Vista/Win2k8/Win7 ensure we run it in the privileged mode.

Here are some screenshots:

image

image

Here I have used MdbgCore.dll to attach/detach to a process at run time and show the details for debug modules.

Attached is a zip file, containing a 32bit and a 64bit DebugFinder builds along with MdbgCore.dll. Ensure we keep both the DebugFinder32/64.exe and the MdbgCore.dll in the same folder while running it.

Chill!

DebugFinder.zip

Comments