☰

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

tag-icon • tag-icon networking iis iis-6 log-files http
IIS 日志显示 sc-win32-status=64 但仅通过某些网络

我有一个在客户端服务器（W2k3、IIS6、.NET 2.0）上运行的 ASP.NET 应用程序。FWIW，这是一个测试例如，它还没有被移到生产目前还没有。因此它没有在 SSL、负载平衡等下运行。

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

现在，当我远程进入客户端网络并从其本地计算机之一访问页面时，日志文件会显示 GET，然后我按下页面上的按钮，日志会显示二在同一秒内 POST。第一个显示状态 (sc-status、sc-substatus、sc-win32-status) 200 0 64，第二个显示 200 0 0。

在日志文件中，两次 POST 完全相同。日志基本上如下所示（除了我屏蔽了一些数据）：

#字段：日期时间 s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs（用户代理）sc-status sc-substatus sc-win32-status
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - yyyy Mozilla/4.0+(兼容;+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+(兼容;+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+(兼容;+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-status 为 995，而不是最初报告的 64。sc-win32-status=995 的错误描述为：“由于线程退出或应用程序请求，I/O 操作已中止。”这没有任何意义（考虑到我对代码有完全访问权限）。我仍然不明白这个问题是如何或为什么发生的，但新的错误代码让我相信它可能根本不是网络问题，我现在正在调查随机代码错误的可能性。

答案1

这是我目前对这个问题的理解：

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

更新：我发现了一些有趣的信息这里和这里，所以我基本上重写了页面以确保没有任何不良标记等。并且...问题现在消失了！这只是一个盲目的尝试，我无法肯定地说出解决问题的方法，因为它只在某些非常特殊的情况下影响我们的一些客户...

答案2

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

我发现这是我的情况的原因Fiddler在客户端计算机上检查响应。Fiddler 警告响应已编码，然后抱怨 gzip 文件中的魔法数字不正确。

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

相关内容