ASP.NET Memory: If your application is in production… then why is debug=true

re: ASP.NET Memory: If your application is in production… then why is debug=true

NJ — Thu, 05 Jul 2012 15:00:48 GMT

Hi Tess,

This article is a great read. We have a web application project and use custom http handlers. It has a File import feature to import data from various sources. My question is does this affect custom http handlers? Are the custom http handlers compiled at runtime?

re: ASP.NET Memory: If your application is in production… then why is debug=true

Syed — Tue, 24 Apr 2012 20:17:22 GMT

Hi Tess,

Our application uses one dll called ISDBLayer.dll. This is one of the class library projects in a DLL Solution. When I compile it the solution in Debug mode, and deploy it to production its size is abot 48 kb and the app works fine. Whereas, when I compile it in Release mode (where the size becomes 44 kb), and then deploy it to prod, the application gives an error. This is baffling to me. Any ideas why would such a thing happen just because of a change in the debug/release option.

Thanks,

Syed.

re: ASP.NET Memory: If your application is in production… then why is debug=true

Chien — Tue, 10 May 2011 08:16:38 GMT

how do i run a a nifty command in sos.dll ?

re: ASP.NET Memory: If your application is in production… then why is debug=true

Scott Yee — Wed, 26 Jan 2011 16:30:07 GMT

Hi Tess,

Thank you for your posts. I would not have solved my application's memory issues without this particular post and all the debugging tips throughout your blog. I've really learned a lot!

re: ASP.NET Memory: If your application is in production… then why is debug=true

Gabriel Lozano-Moran — Sun, 05 Sep 2010 00:22:14 GMT

If debug=true you will NOT get time-outs no matter what the setting is for retail in machine.config. That is because the ASK.NET Deadlock detection mechanism literally looks in web.config and if denug=true it theoretically runs for an infinite amount of time so that you have more than enough time to attach a debugger.

re: ASP.NET Memory: If your application is in production… then why is debug=true

Keith — Wed, 04 Aug 2010 13:10:34 GMT

Thanks Tess for the response....we have an issue where the machine.config has retail=true yet when debug=true is set on the web applications our performance goes out the window.

If we set it to false (which why wouldn't we on production anyway?) it goes normal. Our issue has only really been that it slips up there in dpeloyments some times and the last time it got us we put in a critical support ticket with MS who turned around and said you have debugging enabled in production and we see in your dumps that is eating a lot of your resources.

Which started the debate on retail=true and debug=true. It seems to me there are a few gotchas still out there and possibly some further digging to what really changes when both these settings are true versus retail=true and debug=false.

re: ASP.NET Memory: If your application is in production… then why is debug=true

Tess1 — Wed, 04 Aug 2010 07:21:52 GMT

First I thought that debug=true would override this but after looking at this in more detail both in dumps and in documentation I found that retail=true disables the debug=true setting, so if retail=true then debug=true should not be in effect.

Thanks,

Tess

re: ASP.NET Memory: If your application is in production… then why is debug=true

Keith — Wed, 28 Jul 2010 14:16:13 GMT

We've run into this issue in our ASP.net 3.5 code where the machine.congif has the Deployment retail=true and our code managed to get updated in Prod with Debug=true in the web.config.

However since the machine.config is set it should have been fine, yet it seems this is not working. Do you know if this is something that works in 3.5? A look at my memory dumps during an issue led me to the setting and then mass debate occured between systems, architects/devs and our team over how this could not happen..the machine.config settings are there.

Any experience on this?

APS.net 3.5.20729.1 (.Net 3.5 SP1) on Windows 2003 64 Bit using 64bit framework.

Thanks!

re: ASP.NET Memory: If your application is in production… then why is debug=true

Tess1 — Fri, 08 Jan 2010 08:03:52 GMT

Tim,

Yes, it applies to web services as well. Web services (asmx) is basically a subset of asp.net

re: ASP.NET Memory: If your application is in production… then why is debug=true

Tess1 — Fri, 08 Jan 2010 07:35:41 GMT

Hi Krister,

There is really no good way to say. Picture this... if you have 20 pages = 20 assemblies, and then your app allocates 1 GB worth of memory for various datasets etc. then the overhead for the debug data for the 20 assemblies would be negligeable. If on the other hand you have 1000 assemblies/pages and your app is otherwise frugal with memory usage then the overhead is not so negligeable so it is really impossible to say. Even on a specific page/assembly you can't give a percentage, and it also depends on if the page is changed during the app lifetime. The best thing is probably to test with debug=true or debug=false and see. But more importantly, with debug=true you will not take advantage of timeouts or other code optimization and that is really a bigger issue than the memory usage.

What type of debug info does your support team use that would not be available if you have debug=false? debug.write output for example would still be present...