It happens: someone’s trying to debug a problem in a rush, a dev environment gets migrated – sometime’s it happens that your web.config Debug Mode switch gets inadvertently left in “true” mode. This is all kinds of bad- ScottGu highlights:

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached

On production, unless you have a multi-tenant server where some users may expect to be able to flip debug mode on (not a likely scenario in the SharePoint world!), it’s a wise best practice to alter the Machine.config to use Retail Mode.  Full reference here – link is SP 2007 but same principles apply.

<deployment retail=”true” />

Just remember that editing the Machine.config is no trivial task- root instructions are here:, but it doesn’t explain that you must ensure nothing else on the machine is trying to update that machine.config while you have it open in Notepad. If this machine.config get’s out of synch with other settings, you will hose your server. You can ensure this doesn’t happen by:

  1. Turning of all IIS Sites and App pools
  2. Backing up the machine.config
  3. Open the machine.config in Notepad
  4. Change the Deployment to retail=true
  5. Save and close machine.config
  6. Start IIS Sites and App Pools