IIS-Protokolle zeigen sc-win32-status = 64 an, jedoch nur über einige Netzwerke

Ich habe eine ASP.NET-Anwendung, die auf einem Client-Server (W2k3, IIS6, .NET 2.0) ausgeführt wird. FWIW, dies ist eine Testinstanz , die noch nicht in die Produktion verschoben wurde . Es läuft also nicht unter SSL, Load Balancing usw.

Wenn ich von unserem Büro aus auf eine der Seiten auf ihrem Server zugreife, wird die Seite einmal getroffen. Beim Überprüfen der IIS-Protokolle (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) wird ein GET für diese Seite angezeigt. Anschließend drücke ich eine Schaltfläche auf der Seite und in der Protokolldatei wird ein POST angezeigt. Dies scheint bisher gut zu funktionieren.

Wenn ich jetzt eine Remote-Verbindung zum Netzwerk des Clients herstelle und von einem der lokalen Computer aus auf die Seite zugreife, wird in der Protokolldatei ein GET angezeigt. Dann drücke ich auf die Schaltfläche auf der Seite und im Protokoll werden zwei POSTs gleichzeitig angezeigt. Der erste zeigt den Status (sc-Status, sc-Substatus, sc-win32-Status) 200 0 64, der zweite zeigt 200 0 0.

In der Protokolldatei sind beide POSTs identisch. Grundsätzlich sieht das Protokoll folgendermaßen aus (außer dass ich einige Daten maskiert habe):

#Felder: Datum Uhrzeit s-ip cs-Methode cs-uri-Stamm cs-uri-Abfrage s-Port cs-Benutzername c-ip cs (Benutzer-Agent) sc-Status sc-Substatus sc-win32-Status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - JJJJ Mozilla / 4.0 + (kompatibel; + 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 - JJJJ Mozilla / 4.0 + (kompatibel; + 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 - JJJJ Mozilla / 4.0 + (kompatibel; + 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

Das Problem ist , dass die Seite zweimal aufgerufen wird. Die Datenbank führt eine Operation für die erste Anforderung aus, dann erkennt die zweite Anforderung, dass eine doppelte Operation ausgeführt wird, und gibt eine Fehlermeldung aus. Die Benutzer glauben, dass ihre Operation fehlgeschlagen ist, aber es ist tatsächlich gelungen.

Die Fehlerbeschreibung von sc-win32-status 64 lautet: "Der angegebene Netzwerkname ist nicht mehr verfügbar." Dies lässt mich glauben, dass der Server die Anforderung erfolgreich bearbeitet, da beide POST-Anforderungen einen HTTP-Status von 200 aufweisen, der Client jedoch nie benachrichtigt wird und die Anforderung erneut sendet.

• Wie kann ich das beheben?

• Irgendwelche Ideen, was dieses Verhalten nur in ihrem internen Netzwerk verursachen könnte?

• Ich sollte erwähnen, dass dies an zwei verschiedenen Kundenstandorten geschieht, jedoch nicht an sechs unserer anderen Kundenstandorte oder in unserem Büro oder bei der Verbindung zu einem unserer acht Kunden über das Internet.

• Was könnte dazu führen, dass dies 100% der Zeit in ihrem lokalen Netzwerk reproduzierbar ist, aber 0% der Zeit irgendwo anders?

Update: Ich habe festgestellt, dass eine sehr kleine Anzahl der duplizierten POST-Anforderungen den sc-win32-Status 995 anstelle von 64 hatte, wie ursprünglich berichtet. Die Fehlerbeschreibung von sc-win32-status = 995 lautet: "Die E / A-Operation wurde aufgrund eines Thread-Exits oder einer Anwendungsanforderung abgebrochen." Dies macht keinen Sinn (wenn man bedenkt, dass ich vollen Zugriff auf den Code habe). Ich verstehe immer noch nicht, wie oder warum dieses Problem auftritt, aber der neue Fehlercode lässt mich glauben, dass es sich möglicherweise doch nicht um ein Netzwerkproblem handelt, und ich untersuche jetzt die Möglichkeit eines zufälligen Codefehlers.

Dies ist mein bisheriges Verständnis des Problems:

• sc-win32-status 64 bedeutet "Der angegebene Netzwerkname ist nicht mehr verfügbar."
• Nachdem IIS die endgültige Antwort an den Client gesendet hat, wartet es normalerweise auf eine ACK-Nachricht vom Client.
• Manchmal setzen Clients die Verbindung zurück, anstatt die endgültige Bestätigung an den Server zurückzusenden. Dies ist kein ordnungsgemäßer Verbindungsabschluss, daher protokolliert IIS den Code „64“.
• Viele Clients setzen die Verbindung zurück, wenn sie damit fertig sind, um den Socket freizugeben, anstatt ihn in TIME_WAIT / CLOSE_WAIT zu belassen.
• Proxies neigen dazu, dies mehr zu tun als andere.

Update: Ich habe hier und hier einige interessante Informationen gefunden , also habe ich die Seite im Grunde genommen neu geschrieben, um sicherzustellen, dass es keine schlechten Markups usw. gibt und ... das Problem ist jetzt weg! Es war nur ein Schuss in die Dunkelheit, und ich konnte nicht definitiv sagen, was das Problem behoben hat, da es nur einige unserer Kunden unter bestimmten Umständen betraf ...

Das gleiche Problem trat auf, als ich versuchte, komprimierte Binärdateien von IIS6 über einen Proxyserver bereitzustellen. Ich hatte kein Problem, als ich direkt auf die Website ging.

Ich fand, dass dies die Ursache in meinem Fall war, indem ich Fiddler auf einem Client-Computer ausführte und die Antwort überprüfte. Fiddler warnt davor, dass die Antwort verschlüsselt ist, und beschwert sich dann, dass die magische Zahl in der gzip-Datei nicht korrekt war.

Ich habe die gzip-Komprimierung für Binärdateien in meinem Code deaktiviert und das Problem trat nicht mehr auf.

Ich bin kein Experte in diesem Bereich, aber ich bin auf ein ähnliches Problem gestoßen, das nur bei Verwendung einer IP-Adresse anstelle eines Hostnamens aufgetreten ist.

Vielleicht hilft das ein bisschen ...

Matte.