Caveman's Blog

My commitment to learning.

Troubleshooting an IIS Crash/Hang

with 2 comments

This is an experience of mine at a client. It was a project about integrating a third party application with the client’s web application, so that the client could provide better service to its customers.

I have designed and implemented this ASP integration application and the project was deployed successfully. Everyone was very impressed with my work and I was happy.

I was thinking how well my design was and that all implementations should be as good as mine. how nice would it be if all the systems that are designed and implemented ran smoothly after a successful QA, with out ever crashing or needing any monitoring.

Phone rings !!!!

Wake up Caveman!!! Wake up !!! Ohhhhhhhh Shoot!! it was only a dreammmm….. damn-it!!

I woke up from my dream with the annoying ring of the phone. I got this call from the support group

Me: Hello, Me here

Support Guy(SG): Hi this is SG from the Support group, how are you?

Me: Good, How about you?

SG: alrite

Me: What’s up?

SG: The website is hanging intermittently and we are having to do an IISReset to bring back the site.

Me: hmm… Is there a pattern to this issue?

SG: The CSR Manager said that this happens randomly and that the business is getting effected because of the outage.

Me: Okay I will take a look at this and get back to you.

SG: This priority 1 issue.

Me: (I thought of shouting at him: so what!!! hold on !!! I will get to it when I can get to it) Thanks for letting me know about this…. and the call ends.

This is the time when I was scratching my head about what could possibly have gone wrong, that caused the website to hang. My first instinct told me that the third party component might be the culprit (as later turned out to be), coz I did not design/code it, heheheheeeee.

There could be several reasons like some of the following that could cause an application failure.

1. Network Issues.
2. Too many database connections.
3. Unreasonable CPU utilization.
4. Disk access errors.
5. Web Service failures.
6. Erroneous third party components.
7. Memory Leaks.
8. Threading issues, etc…

I would usually start with checking the health of the Web application that includes (but not limited to) checking the following:

  • No. of Database Connections.
  • CPU on Web Server and Database Servers..
  • Event viewers on all servers.
  • Memory consumed by Dllhosts or Worker (w3wp.exe) processes.
  • Web Service call durations.


At times this might also not help and all you would notice is a blip on the radar that does not tell you much, like an iisreset has been automated and that a crash has occurred. How would you know the cause of the crash/hang?

IIS State is a command line utility, that is a part of the IIS 6.0 Resource toolkit, that is a very handy to diagnize IIS related issues.To attach IISState to a particular w3wp.exe process execute the following command (where <PID> is the Process ID). This will do an immediate dump of the current process.

iisstate -p <PID>

IISState also supports the following optional switches:
  • -sc(waits for a “soft crash” such as an ASP 0115 Trappable Error Occured in an External Object)
  • -hc (waits for a “hard crash” where the process terminates unexpectedly)
  • -d(write out a dump file, which can be used for further analysis, e.g. by WinDBG)

IISState outputs a log file containing the stacks of all the threads in the process. I used the IISState utility to get a dump file and a logfile by hooking it to the only w3wp.exe process. I got lucky and the crash happened in a little time. Upon examining the dump I have noticed that the one of the threads was waiting on another thread to get its job done and that, that thread was waiting on another thread. I traversed through a bunch of threads to finally derive at a thread that was the culprit. I was able to figure out that this thread belonged to a third part dll as mentioned in the thread info. I have checked with the 3rd part software company and found out that they had released a newer version that took care of the thread issue.

Another way of diagnosing the issue would be by further analyzing the dump file with utility like DebugDiag, WinDBG. For this method of diagnosis you will need the .pdb files of the application and the necessary symbols.

Useful tools:
1. IIS 6.0 Resource Kit Tools
2. Debug Diagnostic Tool (DebugDiag)
3. WinDBG

Written by cavemansblog

April 16, 2008 at 2:19 pm

2 Responses

Subscribe to comments with RSS.

  1. […] by cavemansblog on June 9, 2009 A while ago I have posted a blog on Troubleshooting an IIS Crash/Hang, where I have mentioned that we can use a tool called Windbg to analyze the dump file that is […]

  2. […] 5. IIS crash because of a memory leak, thread locking, etc. Check out Troubleshooting an IIS Crash/Hang […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: