I'm running an ASP.NET application on IIS 7.
The server blissfully hums along until
- An Application_Start event is raised
- All requests made by currently connected users give a 'Connection_Abandoned_By_ReqQueue' error in httperrX.log
- An Application_End event is raised
It looks like a worker process recycle, right?
But w3wp never died, a new w3wp never started, and no recycle was logged.
What could have caused this? And how do I prevent it from happening?
Technical details:
- Windows Server 2008 R2
- IIS 7
- .Net v4.0 app pool with classic pipeline
- Maximum 1 worker process with overlap enabled
Update
I'm encountering this situation while load-testing a web application.
Throughout this testing process, I've recycled and restarted the web server many times. Apparently, this changes the cryptographic key being using to obtain web resources, as explained here: “Padding is Invalid and cannot be removed” exception on WebResource.axd. The testing software isn't smart enough to change its requests (without significant finagling) in response to a new key.
The result of all this was that several requests were failing with .Net cryptographic exceptions. I determined I didn't care about those requests and removed them from the test. This seems to take care of the bizarre pseudo-recycling this question is about.
Two things remain unknown:
- Is the recycling caused by erroring requests to WebResource.axd or by any requests to WebResource.axd?
- Why does this cause the pseudo-recycle instead of a regular recycle or no recycle at all? The behavior is still undocumented.
Best Answer
Anytime a file is changed in the application folder, this can trigger an recycle of an application pool. Antivirus real-time monitors are notorious for this, but there is actually quite a large list of potential offenders. Check the following from Tess Ferrandez:
http://blogs.msdn.com/b/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx
In particular, you can enable the ASP.Net Health Monitoring Event to record the activity to the application event log, with the reason for the restart.