This seems like a simple thing, really, but every single place I have worked that developed .net code has had this problem, and for some reason, devs don’t seem to get it. (It has been an uphill battle everywhere I have found it with resistance from devs. Why??)
Usually the symptoms start out with scaling issues in production, you’ll see things like threads running out, connections not being closed, and general poor application performance. You can track these down and eventually you will find that in the web.config the setting “debug=enabled” is in there. It is this way because it is the default when you create a .net application. YOU DO NOT LEAVE IT LIKE THIS IN PRODUCTION. When you do, bad things happen, such as timeouts all being set to infinite. Here’s an article with a complete list and some more info.
Depending on whether or not your organization pushes the .configs with the applications (this is a religious discussion in itself.. I recommend not pushing the configs with every build for reasons like this), then when you do your next code push, the process repeats because of this value being set improperly again. The way to fix this for good is that in the production environment, you make a change to the machine.config to enable “retail” mode, which disallows debug from being enabled, regardless of what is in the application’s web.config.
In my opinion, setting this in the machine.config should be part of the default build/installation/configuration of any production webserver.