web-dev-qa-db-ja.com

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が表示され、ページのボタンを押すとログに表示されます 二 同じ秒の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 +（互換; + 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リクエストのHTTPステータスが200であるとすると、サーバーはリクエストの処理に成功しますが、クライアントには通知されず、リクエストを再送信します。

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

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

  • 言及しておきますが、これは2つの異なるクライアントサイトで発生していますが、 ない 他の6つのクライアントサイトで、またはオフィスで、または8つのクライアントのいずれかにWeb経由で接続します。

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

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

networkingiisiis-6log-fileshttp
11
wweicker

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

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

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

18
wweicker

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

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

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

2
Russ Giddings