IIS file download hangs/timeouts - sc-win32-status = 64

Question

Any thoughts on why I might be getting tons of "hangs" when trying to download a file via HTTP, based on the following?

• Server is IIS 6
• File being downloaded is a binary file, rather than a web page
• Several clients hang, including TrueUpdate and FlexNet web updating packages, as well as custom .NET app that just does basic HttpWebRequest/HttpWebResponse logic and downloads using a response stream
• IIS log file signature when success is 200 0 0 (sc-status sc-substatus sc-win32-status)
• For failure, error signature is 200 0 64
• sc-win32-status of 64 is "the specified network name is no longer available"
• I can point firefox at the URL and download successfully every time (perhaps some retry logic is happening under the hood)

At this point, it seems like either there's something funky with my server that it's throwing these errors, or that this is just normal network behavior and I need to use (or write) a client that is more resilient to the failures.

Any thoughts?

Answer 1

You will have to use wireshare or network monitor to gather more data on this problem. Me think.

Answer 2

I suggest you put Fiddler in between your server and your download client. This should reveal the differences between Firefox and other cients.

Answer 3

Check the headers from the server, especially content-type, and content-length, it's possible that your clients don't recognize the format of the binary file and hang while waiting for bytes that never come, or maybe they close the underlying TCP connection, which may cause IIS to log the win32 status 64.

Answer 4

Perhaps your issue was a low level networking issue with the ISP as you speculated in your reply comment. I am experiencing a similar problem with IIS and some mysterious 200 0 64 lines appearing in the log file, which is how I found this post. For the record, this is my understanding of sc-win32-status=64; I hope someone can correct me if I'm wrong.

• sc-win32-status 64 means “The specified network name is no longer available.”
• After IIS has sent the final response to the client, it waits for an ACK message from the client.
• Sometimes clients will reset the connection instead of sending the final ACK back to server. This is not a graceful connection close, so IIS logs the “64” code to indicate an interruption.
• Many clients will reset the connection when they are done with it, to free up the socket instead of leaving it in TIME_WAIT/CLOSE_WAIT.
• Proxies may have a tendancy to do this more often than individual clients.