IIS App Pool recycles don't appear to observe the specified schedule

We are tracing a connection leak in an application that uses remoting hosted in IIS so to clear orphaned connections we have scheduled an AppPool recycle at specified times of the day. However I'm not seeing evidence that this recycle is happening according to the schedule - I have changed the metabase property so IIS will log all recycles and it does log manual recycle commands.

What might be stopping IIS from observing the schedule?

Solution

When you do an application pool recycle (on a scheduled basis), a new worker process (w3wp.exe) is started. The existing worker process is kept alive to service existing requests and then shut down when there are no more. All new requests are sent to the new worker process.

You can check to see if the application pool you are recycling is a new w3wp.exe process. You can do this by using the following IIS admin script:

c:>iisapp.vbs
W3WP.exe PID: 5924   AppPoolId: MSSharePointAppPool
W3WP.exe PID: 2840   AppPoolId: Problem Sites - ASP.NET 2.0
W3WP.exe PID: 2576   AppPoolId: DefaultAppPool
W3WP.exe PID: 6076   AppPoolId: ASP.NET 2.0
W3WP.exe PID: 4916   AppPoolId: Problem Sites - ASP.NET 1.1

Make a note of the process ID's before and after the scheduled recycle time to see if they change.

You may need to use: cscript iisapp.vbs if cscript isn't your default WSH script host.

When an application pool recycles you should also see the following event in your system event log:

Event Type: Warning
Event Source:   W3SVC
Event Category: None
Event ID:   1013
Date:       22/06/2009
Time:       19:18:09
User:       N/A
Computer:   UK1SRD1602
Description:
A process serving application pool 'ASP.NET 2.0' exceeded time limits during 
shut down. The process id was '2788'.

This event will appear after the number of minutes specified in the Idle timout (Application Pool properties -> Performance tab) plus the length of time it takes for the existing worker process to complete any pending requests and the last ASP.NET application domain is torn down (existing ASP.NET sessions will be serviced by the old worker process until there are no more).