Como depurar porque w3wp.exe falha aleatoriamente?

Question

No servidor de produção principal, o processo de trabalho do IIS falha às vezes. No visualizador de eventos, recebo as informações a seguir.

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8 Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319 Exception code: 0xe053534f Fault offset: 0x0000b9bc Faulting process id: 0x%9 Faulting application start time: 0x%10 Faulting application path: %11 Faulting module path: %12 Report Id: %13

Isso acontece aleatoriamente no servidor prod e eu não consegui recriar essa falha em nenhum outro lugar. Isso estava acontecendo no IIS 6, e recentemente nos mudamos para o Windows Server 2008 e o IIS 7.5 e o problema também acontece lá.

Como encontrar a causa raiz disso?

    

Answer 1

Um guia passo-a-passo está incluído aqui no blog de Tess Ferrandez:

link

Essencialmente, você configurará o DebugDiag 1.2 x64 para acionar esse código de exceção e criar um dump de usuário completo. Depois que o dump é criado, você pode usar o DebugDiag para analisar o dump para você. Embora com essa exceção específica, você provavelmente precisará usar o WinDbg + SOS.

Algumas das informações mais relevantes:

"Para estouros de pilha, como a maioria de vocês provavelmente sabe, a razão mais comum é que estamos em algum tipo de loop recursivo, então o que realmente gostaríamos de saber aqui é o que está nessa pilha ... A razão pela qual é aparecendo apenas com endereços e não com nomes de métodos, é porque o debug diag não entende .net, então teremos que trazer o dump para windbg para analisá-lo e verificar a pilha .net.

"No windbg, podemos carregar sos ( .loadby sos mscorwks ) e executar! clrstack na pilha ativa para obter o callstack."

(Se você estiver executando o .NET 4, o comando para carregar sos é: .loadby sos clr )

Por fim, o que você está procurando é o código incorreto em seu aplicativo que está causando a recursão. Os nomes dos métodos que aparecem no WinDbg quando o SOS é carregado, provavelmente o colocam na direção certa.

    

Answer 2

Obtenha o ProcDump e configure-o para gerar dumps quando os processos do w3wp.exe travarem. Depois de ter um dump, inspecione-o com o Visual Studio ou com o Windbg .

    

Answer 3

Eu tive o mesmo problema. No meu código eu tinha a seguinte linha do código vb.net

Dim mPath as string = Environment.GetFolderPath (Environment.SpecialFolder.Desktop)

Meu ASP.NET inteiro falhou, porque não pode acessar essa pasta em tempo de execução. O tratamento de erros não funciona. Clr simplesmente falha.

Substituir esta linha por um diretório existente resolveu meu problema.