Why debug=false in ASP.NET applications in production environment

Have you ever wondered what harm does the flag Debug=True brings to your application?

Besides hurting your application's performance in production house, it turns website lifecycle into a vicious circle.

Here is my understanding of using <compilation debug="true" /> on your application's web.config file:

When <compilation debug=”true” /> is switched on within the application’s web.config file, it causes a number of non-optimal things to happen including:

1) You will see a lot more files in Temporary ASP.NET files folder when you use debug=true.

2) Your pages will not timeout when you have debug=“true” which is no an ideal production scenario.

3) Batch compilation will be disabled even if the batch attribute is true in the <compilation> element.

4) The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation. Basically, when you have debug=true, the DebuggableAttribute gets added to all generated code.

5) All client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.  This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources.  Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

6) When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers).  If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

7) When the debug attribute in the Web.config file is set to true, it generates symbolic information(.pdb information) every time the compiler compiles your .aspx pages as well as disables code optimization. If the application is not being debugged, you should change this attribute to false.

While the debugger is attached and in break mode, no requests to pages in the application execute. Therefore, you should not debug an application on a production Web server while it is in use.

Only one debugger can be attached to the Aspnet_wp.exe process at a time.

The CLR Debugger only debugs managed code, and it only debugs applications on the computer on which the CLR Debugger is running. If you need to debug remotely or if you need to debug code other than managed code, you should use the Visual Studio .NET debugger.

Please refer:http://support.microsoft.com/kb/301058

Now, let's see how can you turn OFF this flag at the server level ?

As obvious as this, please use the following configuration feature on the machine.config file:

          <deployment retail=”true”/>
You will disable the <compilation debug=”true”/> switch and this will disable the ability to trace output in a page, and turn off the ability to show detailed error messages remotely. Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).
For more information on this, please refer: http://msdn.microsoft.com/en-US/library/ms228298(VS.80).aspx

And, now let us see in what scenario you might want to turn on Debug=True:

ASP.NET supports compiling applications in a special debug mode that facilitates developer troubleshooting. Debug mode causes ASP.NET to compile applications with extra information that enables a debugger to closely monitor and control the execution of an application. Applications that are compiled in debug mode execute as expected. However, the performance of the application is affected.
To avoid the effect on performance, it is a good idea to enable debugging only when a developer is doing interactive troubleshooting. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot a problem, it is also frequently not disabled again after the problem is resolved. So, the best option would be to turn debug=“true,” fix your problem and turn debug=“false” back again.

Please refer following article:

Because many parts of an ASP.NET application (such as .aspx, .asmx and .ascx pages) are dynamically compiled at run-time, you need to configure the ASP.NET run-time process to compile the application with symbolic information before the application can be debugged. To do this, set the debug attribute in the configuration section of the Web.config file that is located in the root of the application folder to true, as follows:

    <compile debug=true/>

Alternatively, you can set the Debug attribute of the Page directive to true in your .aspx pages, as follows:

<%@ Page Debug="true" %>

Let's do a small exercise to illustrate why do we really need to set debug=true in your application's configuration.

Add the following code snippet in Page_Load method of Default.aspx of your sample web application. This code will cause a divide-by-zero(as expected) error message whenever you request the page.

Code Snippet:

protected void Page_Load(Object sender, EventArgs e)
     int32 i = 0;
     i = i/0;

Check the output if you have debug="false" (first) and the same page with debug="true" (second) in Code above.

Output when debug="false" 
 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) +18
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061
 Output when debug="true"
 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) in C:\My Documents\Visual Studio 2010\WebSites\DebugTrue\Default.aspx.vb:8
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

Notice that with debug=“true”, you get a more detailed stack output and it even tells you that the problem happened on line number 8 in a page located at C:\My Documents\Visual Studio 2010 Websites\DebugTrue\Default.aspx.vb:8.

If you are a debugger freak and have some knoweldge about WinDbg dump analysis, you should agree with me in my following notes:

To find out if any of the applications on your server run with debug=true you can run a nifty command in sos.dll called !finddebugtrue which will list out all applications where debug=true in the web.config
0:016> !finddebugtrue
Debug set to true for Runtime: 61b48dc, AppDomain: /SampleApplication
Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues
Total 16 HttpRuntime objects
And to find out if you forgot to compile some of your assemblies in release mode run !finddebugmodules
0:016> !finddebugmodules
Loading all modules.
Searching for modules built in debug mode...

SampleApplication.dll built debug
MemoryIssues.dll built debug
fl4sq-9i.dll built debug
wepr1t3k.dll built debug
r9ocxl4m.dll built debug
zmaozzfb.dll built debug

Done Seaching
The dlls above with weird 8 character names are the dlls generate when JITing the aspx pages, so they will go away when debug=false.

ScottGu has written an excellent blog on this issue, have a look at the below blog from him:


Have a happy read and share your thoughts.

Let me know if you have any questions and issues on this, I will be happy to answer them.

Comments (4)

  1. systemblogger says:

    I noticed that when you set compilateion debug = false, then the menu display at the top will ignore security settings and display all mlen items freely to all users regardless of role or login status.  Any comment about this?

  2. Hi, I believe that this setting <compilation> debug flag has nothing to do with UI rendering issues. This attribute belongs to the system.web namespace which solely governs the compilation life-cycle of your application. What i can imagine would be happening in your case is, if you are testing that in IE, then it may be your IE settings or CSS which would be doing that..

    Hope this helps, let me know if you find a solution for this problem..

  3. jayson says:

     _Default.Page_Load(Object sender, EventArgs e) in C:My DocumentsVisual Studio 2010WebSitesDebugTrueDefault.aspx.vb:8

      System.Web.UI.Control.OnLoad(EventArgs e) +99

      System.Web.UI.Control.LoadRecursive() +47

      System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

  4. Katy Dorjee says:

    thank you, this is very informative.

Skip to main content