Wednesday, August 20, 2008

Why application Pool crashes?


Why application Pool crashes for websites? I kept my promise to post about this issue. Quickest resolution for the application pool crash, may be the permission issue, which can be fixed easily, but if it fails then, Application pool crash may be the result of its actually crashed process or just got hang because of multiple queries.
Lets see the difference between a crash and a hang on the Windows Server .

A crash is the one who will remove out the host process; this will lead to stop the server side work and affect the output of that process been assigned. In old versions of IIS, whenever crash occurred, will go down and the browsers will display a disconnected connection and report some service disconnected or unknown error. In IIS6 Worker Process Isolation Mode, the HTTP.SYS holds the connections in kernel-mode, so even if user code running in w3wp.exe crashes, the connection remains connected and IIS takes care to start up a new process to handle further requests - so browsers like mozilla, IE will not see a disconnection for a crash. But the request in the crash process cannot be re-executed, [serious issue with any money transaction processes]. Now a hang, will keep its host process running but the it prevents to make any sort of changes in. Application code may be waiting for a lock that never gets released, may be because it was leaked or may be a logical deadlock or live lock, or may be infinite loop, etc. Any non processed response will never happen once the application code hang. From browser point of view, both the things, a crash and a hang on the server may prevent a complete HTTP response from being sent back, so may look quite similar. Now a crash is an unrecoverable event that may be resulted from some flaw/bug in the code that is executing. A bug is a logical flaw in the code that may result in some arbitrary set of inputs. so roughly you can say that bugs can cause crashes to the application... I want to make one point here, users attempt to resolve their crashes without diagnosing the cause. Like, most users just look at pattern matching problem symptoms and event log entries and applies presumed solutions and BLINDLY try them all, hoping that some of the solution may work... But its dangerous, leading to making it more complicated issue, than resolving in easy steps.

Now the scene arises that, if you do not know, which bug is causing this,
Now its time to look for debugging, so that NEXT crash can be avoided. you cannot do anything about the crash that has already occurred. You SHOULD NOT change any server settings to avoid it. You can set up debugging monitors like IIS State or DebugDiag for necessary processes running code those are crashing and then WAIT for the next crash. ;)

So whenever failure occurs, These debugging tools will record the event with the cause. After taking out the report from these tools, you will see, there is either only one culprit who is recursively causing it or there are multiple issues. So in initial stage, you can keep watch on the result and also get them fixed as soon as they occur.

2 comments:

Htowncoco said...

I tried DebugDiag and it didn't help me very much. I had to use WinDbg to properly process my crash dump files. Here is a good article that walks you through how to install WinDbg and use it to find where things crashed in your code.

Debugging Faulting Application w3wp.exe Crashes

Web Hosting India said...

Hi..This is very interesting and informative article.Thank you so much for your effective information.