OK, this was bugging me, so I dug around and finally found this posting from a guy who apparently was on the IIS team:
The reason that IIS6 recycles every 29 hours by default (and we had a reason
The reason that IIS6 recycles every 29 hours by default (and we had a
reason for choosing 29 hours as the default value) is because more
likely than not, the web application running on it is unreliable and
literally needs to restart frequently.
Thus, IIS6 is built around the premise (admitedly cynical) that the
user's web application will not run for more than 24 contiguous hours,
features are planned accordingly, and defaults chosen. Worker
processes recycle every 29 hours, process startup and shutdown are
monitored, the process is constantly pinged to make sure it is
running, the process handle is tracked and signaled when it terminates
unexpectedly, etc etc.
Realizing that recycling is a normal part of operations, IIS6 also
makes sure to isolate such recycling from the end user -- the end
user's TCP connection never terminates during a recycle, due to some
kernel-mode magic. Combined with user-mode application which stores
session-state out-of-process (like ASP.Net Session State Service), one
is virtually guaranteed reliable uptime with no user-visible data
loss, even if the web application crashes after processing every
single user request.
This is about as good as IIS6 can make it -- given an unreliable web
application, make it appear reliable to the end-user, and do it
without requiring any fixes of the unreliable web application.
Of course, not all unreliable application can be made to appear
reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries
a whole lot more to be resiliant.
In your case, it just happens that the resiliancy has a side effect on
non-persisted user state, but it can be easily adjusted.
Assuming your web application never has a problem and stays with in-
process session state, you will want to change these defaults:
1. Turn off the 29 hour periodic recycling
2. Turn off the 20 minute idle timeout
This will prevent unexpected loss of session state.
Of course, if you ever use an application with out-of-process session
state, you can leave everything as the defaults and never notice a
difference in functionality nor reliability.