Os logs do IIS mostram sc-win32-status = 64, mas somente através de algumas redes

Eu tenho um aplicativo ASP.NET em execução em um servidor cliente (W2k3, IIS6, .NET 2.0). FWIW, esta é uma instância de Teste , ainda não foi movida para Produção . Portanto, ele não está sendo executado sob SSL, balanceamento de carga etc.

Quando eu acesso uma das páginas em seu servidor no nosso escritório, a página é acessada uma vez. A inspeção dos logs do IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) mostra um GET para essa página, pressiono um botão na página e o arquivo de log mostra um POST. Parece que está funcionando bem até agora.

Agora, quando eu faço uma conexão remota na rede do cliente e acesso a página a partir de uma de suas máquinas locais, o arquivo de log mostra um GET, pressiono o botão na página e o log mostra dois POSTs no mesmo segundo. O primeiro mostra o status (status-sc, sub-status sc, status-sc-win32) 200 0 64, o segundo mostra 200 0 0.

No arquivo de log, os dois POSTs são idênticos. Basicamente, o log se parece com isso (exceto que eu mascarei alguns dos dados):

#Campos: data e hora s-ip método cs cs-uri-stem cs-uri-query s-port cs-nome de usuário c-ip cs (usuário-agente) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80-aaaa Mozilla / 4.0 + (compatível; + 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-aaaa Mozilla / 4.0 + (compatível; + 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-aaaa Mozilla / 4.0 + (compatível; + 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

O problema é que a página está sendo atingida duas vezes. O banco de dados executa uma operação para a primeira solicitação e, em seguida, a segunda solicitação detecta que uma operação duplicada está sendo executada e gera uma mensagem de erro. Os usuários acham que sua operação falhou, mas na verdade foi bem-sucedida.

A descrição do erro do sc-win32-status 64 é: "O nome da rede especificado não está mais disponível." Isso me leva a acreditar, considerando que ambas as solicitações POST mostram um status HTTP 200, que o servidor tem êxito em atender à solicitação, mas o cliente nunca é notificado e reenvia a solicitação.

• Como posso solucionar isso?

• Alguma idéia do que poderia estar causando esse comportamento apenas na rede interna?

• Devo mencionar que isso está acontecendo em dois sites de clientes separados, mas não ocorre em seis de nossos outros sites de clientes, ou em nosso escritório, ou se conectando a qualquer um de nossos oito clientes pela Web.

• O que poderia estar tornando isso reproduzível 100% do tempo em sua rede local, mas 0% do tempo em qualquer outro lugar?

Atualização: eu encontrei um número muito pequeno de solicitações POST duplicadas com o status sc-win32-995 em vez de 64, conforme relatado originalmente. A descrição do erro de sc-win32-status = 995 é: "A operação de E / S foi interrompida devido a uma saída do encadeamento ou a uma solicitação de aplicativo." Isso não faz nenhum sentido (considerando que tenho acesso total ao código). Ainda não entendo como ou por que esse problema está ocorrendo, mas o novo código de erro me leva a acreditar que talvez não seja um problema de rede e agora estou investigando a possibilidade de um erro aleatório no código.

Esta é a minha compreensão do problema até agora:

• sc-win32-status 64 significa "O nome da rede especificado não está mais disponível".
• Depois que o IIS envia a resposta final ao cliente, normalmente ele aguarda uma mensagem de confirmação do cliente.
• Às vezes, os clientes redefinem a conexão em vez de enviar o ACK final de volta ao servidor. Como não é uma conexão normal, o IIS registra o código "64".
• Muitos clientes redefinirão a conexão quando terminarem, para liberar o soquete em vez de deixá-lo em TIME_WAIT / CLOSE_WAIT.
• Proxies tendem a fazer isso mais do que outros.

Atualização: Eu encontrei algumas informações interessantes aqui e aqui , então basicamente reescrevi a página para garantir que não houvesse uma marcação ruim etc. e ... o problema agora se foi! Foi apenas um tiro no escuro, e eu não podia dizer com certeza o que resolveu o problema, pois estava afetando apenas alguns de nossos clientes em circunstâncias muito específicas ...

Eu experimentei esse mesmo problema ao tentar fornecer arquivos binários compactados com gzip do IIS6 por meio de um servidor proxy. Não tive nenhum problema ao acessar o site diretamente.

Eu descobri que essa era a causa no meu caso executando o Fiddler em uma máquina cliente e inspecionando a resposta. Fiddler avisa que a resposta está codificada e depois reclama que o número mágico no arquivo gzip não estava correto.

Desativei a compactação gzip para arquivos binários no meu código e o problema parou de ocorrer.

Eu não sou especialista nisso, mas me deparei com um problema semelhante que só acontecia ao usar um endereço IP em vez de um nome de host.

Talvez isso ajude um pouco ...

Esteira.