A recent question came into my queue asking about the meaning of the Connection_Dropped log entry in the Http.sys error log (%windir%\system32\logfiles\httperr). This error message, by defination, is not clear to most users -
The reason phrase indicates that a zombie connection was dropped by IIS and not resolved correctly
Example log:
2007-01-01 23:48:12 [IP] 3362 [IP] 80 HTTP/1.0 POST /URL/Page - 1 Connection_Dropped
2007-01-01 23:48:12 [IP] 4187 [IP] 80 HTTP/1.0 POST /URL/Page - 1 Connection_Dropped
2007-01-01 23:48:12 [IP] 4212 [IP] 80 HTTP/1.0 POST /URL/Page- 1 Connection_Dropped
No Zombies 'Round Here
The nice thing about working at Microsoft is two-fold:
a) You *might* have access to source code
b) You don't have access to source code but you do have access to someone who does
Luckily, we recently got one of the experts on HTTP.sys to share the real "reason" that you might get an out of body experience out of your Windows & IIS server. It isn't rocket science, yet more that someone got creative with their use of terms an came up with the nice zombie term just to scare you <g>
Under Load - Data has been Lost
The Connection_Dropped error message isn't overly scary. It most likely means that you Web application is under heavy load and because of this no threads are available to currently provide logging data to HTTP.sys. The most "typical" situation is when an ISAPI is too busy to provide IIS with logging data, which in turn slows communication to HTTP.sys, which in turn gives up and assumes the connection is no longer valid.
But wait, it is still valid. Too late - HTTP.sys has moved on to bigger and better things. This happens approxiatmely at the 2 minute threshold.
As gracefully noted by the expert (not me), think more of this error message meaning LoggingTimeout rather than a connection failure. I like that meaning, or rather name, better than any alien-like experience.
Application Sends are Failing
It is possible as is usual with MIcrosoft technology that there is never just one explanation for the problem, rather, there are a couple. There is a possiblity that the issue isn't related to load or disconnects between IIS & HTTP.sys but instead related to your application. There is the possibility that your application who is responsible for building the response is failing to send the response. In short, it is broke. The key narrowing point to this problem is to understand your threads and their status - use the Event Viewer. If your application is not sending the response then it will typically mean that threads running in usermode are blocking and\or failing. Use SP1's tracing to really watch these things...
Comments