Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After about half a day the IIS 6.0 ASP (VBScript) web server appears to die. It accepts TCP connections (i.e. I can telnet localhost 80 successfully) however it does not return any response.

When I restart the server (going through My Computer -> Manage -> IIS -> All Tasks -> Restart) I get a lot of entries in C:\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log at the time of restart that say:

... 80 HTTP/1.1 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool
... 80 HTTP/1.0 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool
... 80 HTTP/1.0 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool

where the ... refers to the prefix of the line, e.g.

2010-03-17 10:05:06 4927 80

There are 583 such lines (Connection_Abandoned_By_AppPool) in my log at time of restart.

What could be the cause of this problem?

share|improve this question
Do these connection abandoned errors occur before or after the restart of IIS. ie are they the cause of IIS not responding to requests, or a result of the restart. – Sam Mar 17 '10 at 10:24
The errors occur at the time of restart.. so it could be that IIS is holding those connections open and then blocks until previous ones are served. Actually next time it happens I'll do a netstat and look for how many connections are open to port 80... – PP. Mar 17 '10 at 10:38
One thing I've done to try and alleviate this problem is to use more than 1 worker process (configuring the DefaultAppPool), and also make it recycle worker processes after 10 minutes and 256MB of virtual memory.. – PP. Mar 17 '10 at 14:03
up vote 1 down vote accepted

My guess is that something with the app fails, causing a whole bunch of requests to queue. When you restart IIS, it's not able to catch up in the 90 second timeout, so it has to forcible end all outstanding requests. So, what you see in httperr is the affect and not the cause.

When it fails, do static pages work? That will tell you if it's IIS or ASP that is at fault. Your telnet test is a great one. That's helpful.

Check the IIS logs just prior to the restart and see if there are any other clues as to which pages are server, or what are the last few requests that worked successfully. That may give some more clues.

Perfmon has some counters that can show the number of queue requests and errors. You may be able to watch that and trend when it fails and possibly tell when the root issue first triggers.

share|improve this answer
accepting answer because 1. it's the only answer, and 2. your test for whether static pages work is a good test. As it is I just configured my DefaultAppPool to recycle worker processes regularly; this seems to have alleviated the problem (but of course did not fix the root issue) which is sufficient for now. – PP. Mar 23 '10 at 9:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.