IISログにsc-win32-status = 64と表示されるが、一部のネットワークのみ

クライアントサーバー（W2k3、IIS6、.NET 2.0）でASP.NETアプリケーションを実行しています。FWIW、これはテストインスタンスです。まだ本番環境に移行されていません。そのため、SSL、負荷分散などの下では実行されていません。

私たちのオフィスからサーバーのいずれかのページにアクセスすると、そのページが1回ヒットします。IISログ（c：WINDOWS \ system32 \ LogFiles \ W3SVC1）を検査すると、そのページのGETが表示され、ページのボタンを押すと、ログファイルにPOSTが表示されます。これは今のところ問題なく動作しているようです。

クライアントのネットワークにリモートでアクセスし、ローカルマシンの1つからページにアクセスすると、ログファイルにGETが表示され、ページのボタンを押すと、ログに2つの POSTが同時に表示されます。1つ目はステータス（sc-status、sc-substatus、sc-win32-status）200 0 64を示し、2つ目は200 0 0を示します。

ログファイルでは、両方のPOSTが同じです。基本的に、ログは次のようになります（ただし、一部のデータをマスクしました）。

#Fields：date time 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

問題は、ページが2回ヒットすることです。データベースは最初の要求に対して操作を実行し、次に2番目の要求は複製操作が実行されていることを検出してエラーメッセージをスローします。ユーザーは操作が失敗したと思っていますが、実際には成功しました。

sc-win32-status 64のエラーの説明は、「指定されたネットワーク名は使用できなくなりました」です。これは、両方のPOSTリクエストが200のHTTPステータスを示していることを考えると、サーバーはリクエストの処理に成功しているが、クライアントには通知されず、リクエストを再送信することを信じています。

• どうすればこれをトラブルシューティングできますか？

• 内部ネットワークでのみこの動作を引き起こしている可能性のあるアイデアはありますか？

• これは2つの別個のクライアントサイトで発生しますが、他の6つのクライアントサイト、またはオフィスでは発生せず、8つのクライアントのいずれかにWeb経由で接続することもありません。

• これをローカルネットワーク上で100％再現できるが、他の場所では0％の時間を再現できるのはなぜですか。

更新：最初に報告されたように、重複したPOST要求の数が64ではなく995のsc-win32-statusであることがわかりました。sc-win32-status = 995のエラーの説明は、次のとおりです。「スレッドの終了またはアプリケーションの要求により、I / O操作が中止されました。」これは意味がありません（コードへの完全なアクセス権があると考えます）。この問題がどのようにまたはなぜ発生しているのかはまだわかりませんが、新しいエラーコードは結局のところネットワークの問題ではない可能性があると考え、ランダムコードのバグの可能性を調査しています。

これはこれまでの私の問題の理解です：

• sc-win32-status 64は、「指定されたネットワーク名は使用できなくなりました」を意味します。
• IISが最終応答をクライアントに送信した後、通常、IISはクライアントからのACKメッセージを待ちます。
• 時々、クライアントは最終的なACKをサーバーに返送する代わりに接続をリセットします。これは正常な接続のクローズではないため、IISは「64」コードをログに記録します。
• 多くのクライアントは、接続が終了すると接続をリセットし、ソケットをTIME_WAIT / CLOSE_WAITのままにせずに解放します。
• プロキシは、他のプロキシよりもこれを行う傾向があります。

更新：こことここで興味深い情報を見つけたので、基本的にページを書き直して、不適切なマークアップなどがないことを確認しました。問題は解消されました。これは暗闇の中でのショットであり、特定の状況下で一部のクライアントにのみ影響を及ぼしていたため、問題を修正したのは何であるかはっきりとは言えませんでした...

プロキシサーバーを介してIIS6からgzip圧縮されたバイナリファイルを提供しようとしたときに、同じ問題が発生しました。ウェブサイトに直接アクセスしても問題はありませんでした。

私の場合、クライアントマシンでFiddlerを実行し、応答を調べたところ、これが原因であることがわかりました。Fiddlerは、応答がエンコードされていることを警告し、gzipファイルのマジックナンバーが正しくなかったことを報告します。

コードでバイナリファイルのgzip圧縮をオフにしたところ、問題が発生しなくなりました。

私はこれに関する専門家ではありませんが、ホスト名ではなくIPアドレスを使用した場合にのみ発生する同様の問題に遭遇しました。

多分それは少し助けになります...

マット。