IIS7.5 Application pools advanced settings – WAS reporting exceed job limit settings

I found this thread while searching for the exact same error description. And I found what was causing it in my case.

I was converting an application from .net 3.5 to 4.0 and after I changed the app-pool from 2.0 to 4.0 this started. It only happened in classic mode not integrated.

In my case I had wildcard http handlers in web.config:

<add name="Wildcard .net 64 bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="bitness64"/>    
<add name="Wildcard .net 32 bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="bitness32"/>

But I had forgotten to change the path to the .net 4.0 directory

so after changing \v2.0.50727\aspnet_isapi.dll to \v4.0.30319\aspnet_isapi.dll the website started behaving normally.

Hope this helps someone.

This looks like one of those cases where simulation (or source code access...>sigh<) is probably going to be the only way to see what the behaviour is with any degree of confidence.

The documentation for the event log entry for CPU quota recycling talks about recycling as follows:

By default, application pool recycling is overlapped, which means that the worker process that is to be shut down is kept running until after a new worker process is started. After a new worker process starts, new requests are passed to it. The old worker process shuts down after it finishes processing its existing requests, or after a configured time-out, whichever comes first. This way of recycling ensures uninterrupted service to clients. However, if an application in the application pool cannot run more than one instance of itself at a time, overlapping rotation can be disabled.

It would seem to me that, by definition, terminating a worker process because of excessive CPU consumption would mean that pending requests wouldn't be allowed to be completed (since they're exhausting the CPU quota).

To speak to your major concern: I'm not seeing anything that leads me to believe that a new worker process wouldn't be spun up automatically. The statement in your Stack Overflow link does make me question if the algorithm used by IIS may, in fact, tie recycling to the resolution of the timer used to measure CPU quota exhaustion. The best way I know to determine that would be to write a CPU-wasteful server-side component, deploy it into a test environment, and see how its recycling behavior acts. A simple component that sits in a tight loop for a few seconds and then returns a known string, combined with a client running a test harness with something like a pool of parallel "wget" processes might be enough. Hammer on it with a bunch of parallel requests from a client and report on how may requests receive the proper response versus error messages, etc. (It makes me feel so silly to have to resort to things like this as opposed to just going to look at the source code...)