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 是相同的。基本上日誌看起來像這樣（除了我屏蔽了一些數據）：
#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+(兼容;+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 操作已中止。” 這沒有任何意義（考慮到我可以完全訪問程式碼）。我仍然不明白這個問題是如何或為什麼會發生的，但新的錯誤程式碼讓我相信它畢竟可能不是網路問題，我現在正在調查隨機程式碼錯誤的可能性。
到目前為止，這是我對這個問題的理解：
- sc-win32-status 64 表示“指定的網路名稱不再可用。”
- 在 IIS 向客戶端發送最終響應後，通常它會等待來自客戶端的 ACK 消息。
- 有時客戶端會重置連接，而不是將最終的 ACK 發送回伺服器。這不是一個正常的連接關閉，因此 IIS 記錄“64”程式碼。
- 許多客戶端在完成連接後會重置連接，以釋放套接字而不是將其留在 TIME_WAIT/CLOSE_WAIT 中。
- 代理往往比其他人更容易做到這一點。
更新：我在這里和這裡發現了一些有趣的資訊，所以我基本上重寫了頁面以確保沒有任何錯誤的標記等……問題現在消失了！這只是在黑暗中的一個鏡頭，我不能肯定地說是什麼解決了這個問題，因為它只在一些非常特殊的情況下影響了我們的一些客戶……