Care, Share and Grow! : Microsoft Support

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

Saurabh Singh — Sat, 05 Dec 2009 22:17:00 GMT

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:

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!

IIS ASP.Net Developer Support Group comes with its own Weblog

Saurabh Singh — Tue, 15 Apr 2008 05:15:52 GMT

Recently we have come up with a dedicated blog site for IIS support group. Our aim is to include topics which will be of relevance to end users with regard to troubleshooting, and technical readiness for IIS ASP.Net including the latest in offering i.e. IIS 7.0. Using this as a medium we will try to provide information on matters closely related to IIS and Web applications built in ASP/ASP.Net etc. I am myself being one of the bloggers for this site http://blogs.msdn.com/webtopics .

Watch out for some useful posts to come in future from the entire group here...

My turn will get over too...

Saurabh Singh — Tue, 18 Dec 2007 02:35:00 GMT

[Non Technical]

Recently I got an extra responsibility to be an On-call engineer for IIS/ASP.Net support for one week apart from my daily work schedule. And I never realized what toll it can take on me until I took over it.

Basically an On-Call engineer has to be available during the Night hours for the entire week. S/he is just a backup, reserved in case a Critical issue comes in and no one is around to take it. So its like passively working 24x7 for a complete week. Remember it's an extra add-on after one's office hours.

We have very limited number of Engineers in support during US night shift hours and weekends, assuming that call/case volume will be very low during this period. And when an incident case is opened during this time and no one is available to take it (assuming all the limited workforce is already occupied with work on other cases) the call goes on to the so-called privileged On-Call engineer. And depending upon the severity of the case s/he may have to work on it either from home or come to office and then take over the mantle. Look how that poor person has to manage if s/he already had a tough day in office. In my case I had no choice but to come to office.

And I was told that we don't get much calls for an On-call, and believing in the sanctity of the advice I was quite happy. But looks like everyday in my so called night hours (I work in US time zone although based in India) I get a ring for a critical (high severity and visible) case and the person on other line starts gabbling all the technical stuffs he damn cares to know about. And I am, brutally woken up from my deep slumber trying to recover at the earliest to make sense of what other person is speaking....It kind of, makes it amusing to me how fast I need to recover my senses (wherein few seconds back I was dreaming running around the trees in a state of bliss), to understand the technicalities of the phone conversation and get on with a bunch of people on the other line talking about how their server crashed like hell and how they saw their application getting into a hung state, or leaking memory etc. and what not. I understand their state (no one would like to work off hours in night or weekends out of choice after a hectic day unless a lot is on stake) and I try my best to empathize with their state and help them to the best of my abilities, meanwhile also knowing my own state at that point ;-)....well part of my job anyway.

In fact, these days I have started dreaming that my cell is ringing and when I wake up there is an utter silence, and I try to console myself that I will get a peaceful sleep today (I tell myself I won't get a call today for sure, let peace behold on me), which doesn't seem to be happening for the last few days.

I am happy that it won't last long, another few days to go :-) and then I can be a free bird enjoying my after-hours (beyond my shift) and then of course the weekends. You see there are a lot of plans one tend to make for weekends if their weekdays had a perilous impact on them. Just a kind of compensation I feel. One needs to find ways to freshen up. On a brighter note, I feel this stretch is really challenging and puts back hope in one's abilities (if you have lost one) to handle pressure and situation elsewhere too in other walks of life and shows how far one can stretch his/her own limits if required. I am an optimist at the end and knows ways to soothe myself.

Looking forward to an exciting weekend ahead....guess today is just the start of the week.

Cheers!

Hotfix available at a click...no more calls required to PSS!

Saurabh Singh — Fri, 03 Aug 2007 22:37:19 GMT

No more hassles to call into Microsoft Product Support services for any Hotfix...no more getting a case created just for a hotfix....no more waiting in the Queue to get a support professional to deliver you a hotfix. Ain't it a good news :-)

Recently Microsoft has come up with an online request submission for Hotfix. To obtain a Hotfix, you need to submit your request via this form to Microsoft Online Customer Service and Support – you can expect to receive a download link via email from Microsoft within 8 business hours.

Online Request for Hotfix: https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix