Re: Log File Analysis - sc-win32-status codes: 64, 10054 & 32

[David Wang [Msft]]

Does this apply to your situation with sc-bytes=0 :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q254718

Win32 error codes are standard and can be looked up.
64 is ignorable.
10054 is "client disconnected the socket", which is what happens when you
hit the F5.

It sounds like you're sending content which can take a while to send, and
either the server or client is timing out while buffering the output
response. This would lead to the client "hanging" there, looking like the
content didn't get sent. This is usually a problem with the code in your
pages.

On Error Resume Next is a bad strategy because it hides all sorts of
errors -- so your code never handles errors properly -- and this can lead to
your page hanging/causing a timeout.

I suggest you remove "On Error Resume Next" and fix your code to handle
errors -- you'll likely never see the "content not reach the client" error
again.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"David Morgan" <da...@davidmorgan.me.uk> wrote in message
news:%23WtAV1S...@tk2msftngp13.phx.gbl...
Hello

I have been looking through our web server log files tonight and have found
the above codes in the sc-win32-status column for requests for different and
the same GIFs.

When the win32 code is 64 the sc-status is always 200 and the sc-bytes is 0.

When the win32 code is 10054 the sc-status is always 500 and the sc-bytes is
greater than 0 but the time-taken is 0.

Can anyone shed any light on to what is occurring here?

The reason I was looking at my log files is that we are still having a
problem where content is not reaching the client. It just stops, mid way
through. I captured log records for an occurrence of this below. There
were three requests. First one is where I opened the page, (a GET), second
one is where I submitted the form to query the database and return the
results. The third one is where I hit refresh as the content had stopped
coming on the second request. On the refresh/third request, the content
came down ok.

(See attached text file if you don't mind.)

Can anyone help me with any of this?

MTIA

David M

P.S. It appears from my log file that when you use On Error Resume Next and
then an error occurs, this does log a 500 error.

[David Morgan]

Hi David

Thanks for your response. I am happy with those codes you gave me. Me
pressing F5 was not related to those server logs, but I can assume that
other users are pressing F5 or that some other non-important network issue
occurred.

Regarding On Error Resume Next, it was a mere observation. I have to use On
Error Resume Next when doing file uploads, (with ASP Upload). If you have a
page that optionally allows a file to be uploaded, (whilst having a load of
other form fields), and they choose not to upload a file, you would get an
error "No Files Uploaded" or something. Obviously, in the optional upload
scenario you would want to be able to continue processing and access the
other submitted values.

In any case, when ever I do use On Error Resume Next, I immediately check
for errors and take the appropriate action.

I have this timeout problem with static files, e.g. WMV Movies that are
downloaded. It will start to download, (say get's to about 42k), and then
stops. If you refresh/retry it may then work. Some of the ASP output is
big and we experience this problem also. I thought it was a network issue
but on the advice of our ISP have recently completely flattened and
re-installed the operating system. Still having the problem. Have upped
the Performance slider to over 100,000 hits per day which seems to have made
the problem worse!

Regarding my code, well, it could be, but I have been doing ASP since about
1997 and I'm a performance perfectionist so normally have very streamlined
code.

Thanks for you help on this.

Regards

David

"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:uakUyGVO...@tk2msftngp13.phx.gbl...