The workflow has reached its allowed processing time
We experience this problem about once a month. It is very difficult to determine the cause, so any help would be appreciated. This causes the App Pool to stop and brings the site down. We went through all the log files and did nothing. We are using version 2.0.3 on IIS 6.
I noticed that IIS uses web apps in a 29 hour redistribution schedule by default, which can be problematic as it can get recycled while your users aren't expecting it.
For example: a web application is launched at 12 a.m., which means that the next day it is processed at 5 a.m., the next day after that at 10 a.m., the next day after that at 3 p.m., etc. (assuming there is enough request activity against your application to keep it going so it doesn't get disconnected due to inactivity)
If your web application relies heavily on session state in memory, this is especially bad because re-looping will kill sessions and possibly cause users to re-authenticate and lose any unsaved work. (unless you are developing an app to run smoothly with recycle)
Check the recycling schedule and make sure it is recycling at the time you expect. See this for screenshots: http://remy.supertext.ch/2010/08/iis7-worker-process-reached-its-allowed-processing-time-limit/
Not sure if the infinite loop suggestion ... looks like you just have a problem with your recycling setup.
source to share
This probably indicates an infinite loop in your application code.
Basically, every time a request arrives at the web server, IIS passes the request to the worker process. You can configure in IIS how many are there and what the timeout value is. The timeout is to move things around in case the application code hangs - it is killed so the thread can return to the pool to continue serving new requests.
So, review your code for likely infinite loops. Or, alternatively, it could be an extremely long-running database query that may eventually complete but has exceeded the timeout value. Perhaps your web application is offering the end user the ability to make a query that is too wide, returning too much data, or taking too long to process the database.
It's hard to give a specific reason for you, of course, but try to think along these lines.
source to share
If you crash as a result (it looks like you are), you might want to grab a copy of the Debugging Tools for Windows and spend some time reading the Tess Ferrandez blog - she offers great advice on doing crash analysis after the autopsy and makes WinDbg much more affordable.
source to share