From SharePoint with love

I guess most of you have seen an error reporting dialog for the IIS Worker Process from time to time when you log on to your SharePoint (or IIS) server – I know I have and far too often.

There is not a lot of information on how to properly troubleshoot this but there are a lot of people that wants to know what to do about it. I hope that I will be able to shed some light on this through a series of posts, although I will be posting these as I troubleshoot.

This means that I have no real idea where I will be heading or if I even solve the problem. Then again, it makes for a lot more interesting reading.

Searching for information about this mainly returns two links:

• An IIS 6.0 application pool may unexpectedly exit when a worker process shuts down or is recycled
• David Wang's HOWTO: Understand and Diagnose an Application Pool Crash

The first one is an IIS-generic knowledgebase article on how to set permissions for applications pools but it is of course applicable to WSS/MOSS as well.

Do the following in order to figure out what identity your SharePoint application pool runs as:

1. Open IIS manager on the SharePoint server
2. Expand the tree under the server and application pools section
3. Right click the correct application pool (in my case it's Sharepoint – 80) and select Properties
4. Select the Identy tab and note down the identity used

I won't go through the KB article but suffice to say that it didn't help me solve the problem as everything already was hunky dory.

The next link above leads to a very comprehensive How-To/philosophical discussion on how to handle application pool related snafus. David Wang has been at Microsoft for five years in the IIS team (if I can read his long winded bio correctly and has put together a very interesting article about how IIS handles processes. Well worth a read, even if it is quite meaty.

Still – there's no real practical information there other than that we need to capture the crash in the wild, so to speak. We can't troubleshoot this error after the fact and he reccommends two applications; IIS State or DebugDiag. I went with DebugDiag myself as it's an official Microsoft tool.

Setting up DebugDiag wasn't entirely straight forward as I didn't want to wade through huge amounts of trace dumps if I could avoid it. This meant that I first created one filter for only the SharePoint – 80 application pool but it seems as if it didn't catch the error (as I did get one in the event viewer during the time DebugDiag was running).

This meant that I set up a new filter – alongside with the old one, just in case – that is meant to catch all IIS related crashes but so far I haven't been able to reproduce the crash.

And here ends this first installment. I know some of you wanted an actual answer but I have to blog it like this or my memory will fade and/or I won't have the time to blog about it at all.

So join me for the next part of the saga, hopefully within a week at the latest.

This entry was posted on Wednesday, October 1st, 2008 at 8:36 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.