Recycle worker process IIS 6.0

Yesterday we had a customer that could not complete his order, during the checkout. Digging a bit deeper I found out that the IIS Worker Process restarted at exactly the same time.

Log in the Event Viewer:

A worker process with process id of ‘7232’ serving application pool ‘DefaultAppPool’ has requested a recycle because the worker process reached its allowed processing time limit.

Doesn’t sound very good, does it? As it turns out, this is default behavior and should protect IIS from Memory Leaks and other bad things in you application.


Luckily you can adjust this setting. In my case it was set to 1740 min (which is about once a day), which is not a very good solution. The problem is, that every time the worker process restarts, you loose all your session states. Now you have several alternatives:

  • Keep your session state out of process. Either via Session State Service or SQL Server, but both add complexity and are slower.
  • You can the recycle behavior. I’ve set it to restart at 22:00. This is 04:00 in Switzerland. Hopefully all clients in the USA and in Switzerland are done ordering at this time.

Nice would be if the Session State could be transferred from one process to the next, but that is not an option yet.

There is a nice forum post about the IIS 6.0 Recycling Tab:

And about retaining your session state:

Lucky for us, the customer actually called and we were able to save this order.


Same problem with IIS7

Ähnliche Beiträge

13 Kommentare zu “Recycle worker process IIS 6.0”

  • Fabian am 28. November 2007 3:01 pm Uhr

    Great you found the solution for this problem.

  • Paige am 10. April 2008 11:19 am Uhr

    Nice job, thanks for this info!

  • Carros DF am 26. May 2008 1:55 pm Uhr

    Nice tip, now I’m recycling every 1:00 AM.

  • IIS7: Worker process reached its allowed processing time limit am 4. August 2010 6:42 am Uhr

    […] already posted the solution for this for IIS6. It’s basically the same for IIS […]

  • ZLA am 1. May 2013 12:53 pm Uhr

    1740 min is exactly 29 days. Not once a day as stated.

  • Mr.Math am 26. July 2013 10:42 am Uhr

    ZLA – “1740 min is exactly 29 days. Not once a day as stated.”

    1740 min is 29 *hours* not *days*, which is about once per day.

  • Joe Luhman am 25. September 2013 9:47 am Uhr

    ZLA: 1740 min is exactly 29 hours, or, roughly, once a day. Not 29 days as you stated.

  • sandeep am 7. October 2013 4:10 am Uhr

    I have dought if i have setup ( recycle worker proccess at the following time ) means what exactly the process will be done. is there any down time for this process.??

  • Rémy Blättler am 7. October 2013 4:17 am Uhr

    Yes, there is a downtime. Should not be noticable, except if you use the in-memory sessions. They get lost.

  • sandeep am 7. October 2013 5:45 am Uhr

    i am sorry didnt get what exact you mean to say?
    downtime means server get shutdown or only service get restart?

  • Rémy Blättler am 7. October 2013 6:21 am Uhr

    The service gets restarted. Might take a few secs. But for a normal user, it just seems like the page takes a bit longer to load.

  • sandeep am 7. October 2013 6:31 am Uhr

    ok thanks for your update,it means we can stop causing the worker process issue using the above steps?

  • Rémy Blättler am 7. October 2013 7:25 am Uhr

    You didn’t mention your issue, but generally yes. Nevertheless, I would still set the worker process to recycle once in a while, just to clean up.

Leave a Reply

Your email address will not be published. Required fields are marked *