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

9

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

Quando eu acesso uma das páginas do servidor do escritório, a página é acessada uma vez. Inspecionar os logs do IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) mostra um GET para essa página, então eu pressiono um botão na página e o arquivo de log mostra um POST. Isso parece estar funcionando bem até agora.

Agora, quando eu me conecto remotamente na rede do cliente e acesso a página de uma de suas máquinas locais, o arquivo de log mostra um GET, depois pressiono o botão na página e o log mostra dois POSTs no mesmo segundo. O primeiro mostra status (sc-status, sc-substatus, sc-win32-status) 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 eu mascarei alguns dos dados):

#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 x.x.x.x GET /File.aspx - 80 - y.y.y.y 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 x.x.x.x POST /File.aspx - 80 - y.y.y.y 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 x.x.x.x POST /File.aspx - 80 - y.y.y.y 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

O problema é , 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 lança uma mensagem de erro. Os usuários acham que a 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, já que as duas solicitações POST mostram um status HTTP de 200, que o servidor é bem-sucedido em atender à solicitação, mas o cliente nunca é notificado e reenvia a solicitação.

  • Como posso solucionar isso?

  • Alguma ideia do que poderia estar causando esse comportamento apenas em sua rede interna?

  • Devo mencionar que isso está acontecendo em dois sites de clientes separados, mas não acontecem em seis de nossos outros sites de clientes, ou em nosso escritório, ou conectados a qualquer um de nossos oito clientes na 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: descobri que um número muito pequeno de solicitações POST duplicadas tinha o status sc-win32 de 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 anulada devido a uma saída de thread ou a uma solicitação de aplicativo." Isso não faz sentido (considerando que eu 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 bug de código aleatório.

    
por wweicker 11.08.2009 / 20:13

3 respostas

15

Este é o meu entendimento da questão até agora:

  • sc-win32-status 64 significa "O nome da rede especificado não está mais disponível".
  • Depois que o IIS enviou a resposta final ao cliente, normalmente ele aguarda uma mensagem ACK do cliente.
  • Às vezes, os clientes redefinirão a conexão em vez de enviar o ACK final de volta ao servidor. Esta não é uma conexão próxima, portanto 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.
  • As proxies tendem a fazer isso mais do que outras.

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

    
por 14.08.2009 / 20:55
1

Eu experimentei esse mesmo problema ao tentar exibir arquivos binários compactados do IIS6 por meio de um servidor proxy. Eu não estava tendo nenhum problema ao acessar diretamente o site.

Descobri que essa foi a causa no meu caso ao executar Fiddler em uma máquina cliente e inspecionar a resposta. O Fiddler avisa que a resposta está codificada e depois reclama que o número mágico no arquivo gzip não estava correto.

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

    
por 30.03.2010 / 13:44
-2

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

Talvez isso ajude um pouco ...

Mat.

    
por 20.08.2009 / 12:10