When using Visual Studio 2005 to debug a web application under IIS7 you will find that after 90-120 seconds the debugger will time out and you will get an appropriate error message in your browser. Visual Studio will return to it's "non debugging"-state and pretend like nothing happened.
Changing the ExecutionTimout property in web.config doesn't change anything, and since you're debugging you'd expect IIS to ignore that setting anyway.
With every new software release there are always small changes that will effect performance / behavior in certain situations. I've mentioned this before in my I've upgraded and now my application doesn't work anymore - post. There are always a few scenarios in which a new feature will appear to limit functionality when it is in fact increasing it.
IIS will periodically ping your worker process in order to ensure that it is still responsive. By default it will be pinging the process every 30 seconds, and the process will have 90 seconds to respond. If it doesn't respond in time it is terminated. All in all this means that If your application pool has hung for some reason it will be recycled and everything will return to normal.
This is not a new feature, but it can, however, cause some problems while debugging. When you hit a breakpoint all execution stops, pending requests are not served and the worker process freezes completely. It will not respond to the health monitoring ping and if it doesn't continue execution within this 90-120 window it will be terminated.
There are three settings you can tweak with to resolve this. You'll find them all in the "Process Model"-section of the Advanced Settings for the Application Pool:
- Open up the IIS manager
- Locate the Application Pool in question
- Right-click on it and select "Advanced Settings"
- Scroll down to the "Process Model"-section
The settings of interest, and their default values are:
- Ping Enabled (True)
- Ping Maximum Response Time (90 seconds)
- Ping Period (30 seconds)
This means you can either turn off health monitoring altogether by setting "Ping Enabled" to false, or you can tweak with the response time or the interval. Please note that the settings are there for a reason, so once you're getting close to production you really should return them back to their default values. I personally think the settings are excellent. An application pool that has hung will be reset within a maximum of 2 minutes. With a decent out of process State Server setup your clients will probably notice an unusually long response time for one request, but think nothing else of it.
Over and out / Johan