IIS日志显示sc-win32-status = 64，但仅通过某些网络

我有一个在客户端服务器（W2k3，IIS6，.NET 2.0）上运行的ASP.NET应用程序。FWIW，这是一个Test实例，尚未移入生产环境。因此它不在SSL，负载平衡等环境下运行。

当我从我们的办公室访问其服务器上的页面之一时，该页面就会被点击一次。检查IIS日志（c：WINDOWS \ system32 \ LogFiles \ W3SVC1）显示该页面的GET，然后按一下页面上的按钮，日志文件显示POST。到目前为止，这似乎运行良好。

现在，当我远程访问客户端的网络并从其本地计算机之一访问页面时，日志文件显示GET，然后按页面上的按钮，日志同时显示两个 POST。第一个显示状态（sc状态，sc子状态，sc-win32状态）200 0 64，第二个显示200 0 0。

在日志文件中，两个POST是相同的。基本上，日志看起来像这样（除了我屏蔽了一些数据）：

#fields：日期时间s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs（User-Agent）sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx-80-yyyy Mozilla / 4.0 +（compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +。NET + CLR + 3.5.21022; +。NET + CLR + 3.5.30729; +。NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0）200 0 0
2009-08-11 20:19:45 xxxx POST /File.aspx-80-yyyy Mozilla / 4.0 +（compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +。NET + CLR + 3.5.21022; +。NET + CLR + 3.5.30729; +。NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0）200 0 64
2009-08-11 20:19:45 xxxx POST /File.aspx-80-yyyy Mozilla / 4.0 +（compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +。NET + CLR + 3.5.21022; +。NET + CLR + 3.5.30729; +。NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0）200 0 0

问题是，页面被击中了两次。数据库对第一个请求执行操作，然后第二个请求检测到正在执行重复操作，并引发错误消息。用户认为他们的操作失败了，但实际上成功了。

sc-win32-status 64的错误描述是：“指定的网络名称不再可用。” 鉴于两个POST请求都显示HTTP状态200，这使我相信服务器可以成功处理该请求，但是永远不会通知客户端并重新提交该请求。

• 我该如何解决？

• 有什么想法可能仅导致其内部网络上的此行为？

• 我应该提到，这是在两个单独的客户端站点上发生的，但是在我们其他六个客户端站点上或在我们的办公室中，或者在通过网络连接到我们八个客户端中的任何一个时都不会发生。

• 是什么使得这种100％的时间在其本地网络上可复制但在其他任何地方的0％的时间可复制？

更新：我发现很少的重复POST请求的sc-win32状态为995，而不是最初报告的64。sc-win32-status = 995的错误描述是：“由于线程退出或应用程序请求，I / O操作已中止。” 这没有任何意义（考虑到我可以完全访问该代码）。我仍然不了解此问题的发生方式或原因，但是新的错误代码使我相信这毕竟可能不是网络问题，现在我正在研究随机代码错误的可能性。

到目前为止，这是我对这个问题的理解：

• sc-win32-status 64的意思是“指定的网络名称不再可用。”
• IIS将最终响应发送给客户端后，通常它会等待来自客户端的ACK消息。
• 有时，客户端将重置连接，而不是将最终ACK发送回服务器。这不是正常的关闭连接，因此IIS记录“ 64”代码。
• 许多客户端在完成连接后将重置连接，以释放套接字，而不是将其留在TIME_WAIT / CLOSE_WAIT中。
• 代理往往比其他人做得更多。

更新：我在这里和这里发现了一些有趣的信息，因此我基本上重新编写了页面，以确保没有任何不好的标记等，并且...问题现在消失了！这只是黑暗中的一枪，我不能肯定地说出解决此问题的原因，因为它仅在某些非常特殊的情况下影响我们的某些客户...

当尝试通过代理服务器从IIS6提供压缩的二进制文件时，我遇到了同样的问题。直接进入网站时，我没有遇到任何问题。

在我的情况下，我是通过在客户端计算机上运行Fiddler并检查响应来找到原因的。Fiddler警告说响应已编码，然后抱怨gzip文件上的幻数不正确。

我在代码中关闭了二进制文件的gzip压缩功能，该问题不再发生。

我不是专家，但是遇到了类似的问题，仅在使用IP地址而不是主机名时才会发生。

也许有帮助...

垫。