web-dev-qa-db-fra.com

IIS Journaux Afficher SC-Win32-Status = 64 mais uniquement à travers certains réseaux

J'ai une application ASP.NET en cours d'exécution sur un serveur client (W2K3, IIS6, .NET 2.0). Fwiw, c'est un Test cas, il n'a pas été déplacé dans Production encore. Donc, il ne fonctionne pas sous SSL, équilibrage de la charge, etc.

Lorsque j'accumule l'une des pages sur leur serveur de notre bureau, la page est touchée une fois. Inspection des IIS LOGS (C: Windows\System32\logfiles\w3svc1) Affiche un message pour cette page, puis je appuie un bouton sur la page et le fichier journal affiche un message. Cela semble travailler bien jusqu'à présent.

Maintenant, lorsque je suis distant dans le réseau du client et accédez à la page à partir de l'une de leurs machines locales, le fichier journal affiche un get, puis je appuie sur le bouton de la page et que le journal affiche deux Messages à la même seconde. Le premier affiche Statut (SC-Status, SC-Stustatus, SC-Win32-Status) 200 0 64, la seconde indique 200 0 0.

Dans le fichier journal, les deux postes sont identiques. Fondamentalement, le journal ressemble à ceci (sauf que j'ai masqué certaines des données):

#Fields: Date Time S-IP CS-Méthode CS-URI-STEM CS-URI-QUERY S-PORT CS-URENAME C-IP CS (Agent utilisateur) SC-Status SC-Substatus SC-Win32 Statut 
 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; +. + 3.0.30618; + MDDR + 3.0.30618; + MDDR + 3.0.30618; + OfficeLiveconnector.1.4; + Officelivepatch.0.0) 200 0 0 
 2009-08-11 20:19:45 xxxx POST /file.aspx - 80 - AAAA 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

Le problème est, la page se fait frapper deux fois. La base de données effectue une opération pour la première demande, puis la deuxième requête détecte qu'une opération en double est en cours d'exécution et jette un message d'erreur. Les utilisateurs pensent que leur opération a échoué, mais elle réussissait effectivement.

La description d'erreur de SC-Win32-Status 64 est la suivante: "Le nom de réseau spécifié n'est plus disponible." Cela me conduit à croire, étant donné que les deux POST demandes affichent un statut HTTP de 200, que le serveur réussit à servir la demande, mais le client n'est jamais informé et soumet la demande.

  • Comment puis-je résoudre ce problème?

  • Des idées ce qui pourrait causer ce comportement sur leur réseau interne?

  • Je devrais mentionner, cela se produit sur deux sites clients distincts, mais fait ne pas arriver à six de nos autres sites clients, ou dans notre bureau, ou se connectant à l'un de nos huit clients sur le Web.

  • Qu'est-ce qui pourrait être reproductible 100% du temps sur leur réseau local, mais 0% du temps ailleurs?

Mettre à jour: J'ai trouvé un très petit nombre de Dupliqué POST Demandes comportait SC-Win32-Statut de 995 au lieu de 64, comme indiqué à l'origine. La description d'erreur de SC-Win32-Status = 995 est: "Le L'opération d'E/S a été abandonnée à cause d'une sortie de fil ou d'une demande d'application. "Cela n'a aucun sens (compte tenu de l'accès complet au code). Je ne comprends toujours pas comment ou pourquoi cette question se produit , mais le nouveau code d'erreur me conduit à croire que ce n'est peut-être pas un problème de réseau après tout et je suis maintenant enquêté sur la possibilité d'un bogue de code aléatoire.

networkingiisiis-6log-fileshttp
11
wweicker

C'est ma compréhension de la question jusqu'à présent:

  • sC-Win32-Status 64 signifie "Le nom de réseau spécifié n'est plus disponible."
  • Après IIS a envoyé la réponse finale au client, il attend généralement un message ACK du client.
  • Parfois, les clients réinitialiseront la connexion au lieu d'envoyer le dernier ack au serveur. Ce n'est pas une connexion gracieuse fermer, donc IIS enregistre le code "64".
  • De nombreux clients réinitialiseront la connexion lorsqu'elles sont finies avec elle, libérer la prise au lieu de la laisser dans Time_wait/Close_wait.
  • Les proxies ont tendance à faire cela plus que d'autres.

Mettre à jour: J'ai trouvé des informations intéressantes ici et - ici , donc j'ai essentiellement réécrivé la page pour vous assurer qu'il n'y avait pas de mauvaise balise, etc. et ... le problème est maintenant disparu! C'était juste un coup dans le noir et je ne pouvais absolument pas dire ce que c'était que c'était corrigé le problème, car il n'affectait que certains de nos clients dans des circonstances très spécifiques ...

18
wweicker

J'ai vécu ce même problème lorsque vous essayez de servir des fichiers binaires gzippés d'IIS6 via un serveur proxy. Je n'ai eu aucun problème lorsque je vais directement au site Web directement.

J'ai trouvé que c'était la cause dans mon cas en exécutant Fiddler sur une machine client et en inspectant la réponse. Fiddler avertit que la réponse est codée puis se plaint que le numéro magique sur le fichier GZIP n'était pas correct.

J'ai désactivé la compression GZIP pour les fichiers binaires de mon code et le problème s'est arrêté survenant.

2
Russ Giddings