Solução de problemas ASP.NET usando o WinDbg e a extensão SOS

Saudação novamente e bem-vindo à edição de janeiro de 2005 da coluna de voz a suporte. Uma vez, gostaria de agradecer Jim Cheshire, um engenheiro de suporte aqui na Microsoft ASP.NET, de suporte para suas contribuições. Jim tem boas idéias para a coluna de voz de suporte e quiser continuar para compartilhá-los. Procure por contribuições Jim mês passado e sobre o próximo mês ou isso e como sempre, envie suas sugestões para colunas futuras. Jim Obrigado!

Jim tem trabalhado com a Microsoft há seis anos em equipes FrontPage, VB e ASP.NET. Durante esse tempo, ele escreveu para o Office Developer Center no MSDN e é autor de um livro no FrontPage, especial Edition usando o Microsoft Office FrontPage 2003 . Jim também tem um site onde ele fornece suplementos livres para o FrontPage permitem aos desenvolvedores da Web que o máximo de produtos da Microsoft. É aqui que endereço do site: Portanto, por favor, uma cadeira de recepção, disparar seus sapatos, leia nossa coluna Tudo sobre solução de problemas ASP.NET e lembre-se, você pode enviar suas idéias para nós usando o link "ASK FOR IT" incluído em cada coluna publicados.
Jeremy

Solução de problemas ASP.NET usando o WinDbg e a extensão SOS

Um bom desenvolvedor planejará para qualquer contingência. Naturalmente, parte do planejamento que está desenvolvendo alguns rotinas de manipulação de exceção robusta. Muitos desenvolvedores ASP.NET serão manipular exceções, apresentando o usuário com uma página da Web bem formatada e fazendo as informações de exceção em um arquivo para análise posterior.

Cenário:

ter desenvolvido e testado um aplicativo ASP.NET novo que fizer exceções em um arquivo de log. Você implantar as páginas ASPX e os assemblies para seu servidor Web de produção. Quando as pessoas usam seu aplicativo, eles estão vendo uma página de erro, mas nenhum log de exceção é gravado em seus arquivos de log. Você também Observe que há muitos ASP.NET eventos no log do aplicativo Visualizador de eventos dizendo que Aspnet_wp.exe interrompido inesperadamente de.

Isso é um tipo comum de problema que vemos no suporte ao desenvolvedor e a maioria dos nossos clientes realmente não sabe como abordar a solução de problemas-lo. Pior é a mensagem de erro "Servidor não aplicativo disponível" temida. Este mês, mostrarei como você pode solucionar esses tipos de problemas com as ferramentas de depuração para Windows.

Aviso de isenção de responsabilidade: Se você chamar o suporte da Microsoft Developer, nós geralmente pode pedir que você envie um arquivo de despejo de memória ou um arquivo de despejo travar. A análise do arquivo de despejo neste artigo será muito fácil e rápida. Em muitos casos, a causa de um problema não está aparente e pode levar várias horas de análise para obter a causa raiz. Não deixe que a facilidade e direto-forwardness dessa análise do arquivo de despejo enganar você pensar que eles são todos fácil assim. A maioria, é na verdade, não!

Obtendo preparado

Antes que podemos obter iniciados, você precisará instalar as ferramentas de depuração para Windows. Mesmo se você já tiver uma cópia instalada, certifique-se que você tem a versão mais recente porque nós estará usando uma extensão de gerenciada depuração que é incluído somente com a versão mais recente de ferramentas de depuração para Windows.

Você pode baixar as ferramentas de depuração para Windows do site da Microsoft: Quando você instala as ferramentas de depuração para Windows, você pode desejar executar uma instalação personalizada para a pasta C:\Debuggers. Nós será executando ferramentas a partir da linha de comando e se o caminho é um pequeno, ele fará fazer até mais fácil para você. Após a conclusão da instalação, você desejará download da página ASP.NET exemplo que irá travar o processo do operador. Observe que, em ordem para ser capaz de gerar o arquivo de despejo usando esta página, você precisa estar executando o ASP.NET 1.1 com o Service Pack 1 (SP1) instalado. Sem o SP1, esta página será executado sem gerar uma falha.

Você também desejará configurar o caminho de símbolo para WinDbg. Símbolos não são necessários para resolução de nome de função em assemblies gerenciados, mas você precisará de símbolos para resolução de função nativa. Para definir o caminho de símbolo no WinDbg:

1. Abra o WinDbg. Clique em Iniciar , aponte para Todos os programas e, em seguida, clique em Ferramentas de depuração para Windows .
2. No menu arquivo , clique em símbolo caminho do arquivo .
3. Na caixa de diálogo Symbol Path , digite o seguinte caminho de símbolo:
   SRV*c:\Symbols*http://MSDL.Microsoft.com/download/Symbols
4. Feche o WinDbg e, em seguida, digite Sim no prompt de salvar informações de espaço de trabalho base.

Agora você está pronto para criar o arquivo de despejo de memória.

Criar arquivo de despejo de memória

Nesta explicação passo a passo, clicando no botão na página de exemplo causará o processo do operador ASP.NET falha. Em muitos casos, você não saberá precisas etapas para gerar uma falha. Na verdade, o aplicativo de produção pode falhar em algum momento aleatório. Como você verá em breve, não importa se uma falha ocorre previsível ou aleatoriamente. Criar um arquivo de despejo é bastante fácil usando Adplus, o arquivo VBScript que automatiza todo o processo.

Para gerar o arquivo de despejo, você precisa primeiro navegue até a página exemplo. (Não clique no botão!) Após a página foi utilizada com êxito, você sabe que o processo Aspnet_wp.exe (ou o processo W3wp.exe no Windows Server 2003) foi iniciado. Agora você está pronto para anexar o depurador ao processo do operador para que você pode capturar um arquivo de despejo quando ele falha.

Para criar um arquivo de despejo:

1. Abra um prompt de comando novo no servidor web e, em seguida, altere para o diretório onde as ferramentas de depuração para Windows são instaladas.
2. Execute o seguinte comando:
   cscript adplus.vbs - falha - pn aspnet_wp.exe -o c:\crashdump
   Se você estiver executando o Microsoft Windows Server 2003, execute o seguinte comando:
   cscript adplus.vbs - falha - pn w3wp.exe -o c:\crashdump

Não entrarei em detalhes no adplus.vbs aqui, mas se você quiser obter mais informações, você pode analisar o seguinte artigo Microsoft Knowledge Base:Depois de executar este comando, você receberá algumas caixas de diálogo. Clique em OK em cada caixa de diálogo. Agora você deve ver um botão na barra de tarefas para o depurador, CDB, o nome do aplicativo para depurador. No entanto, ele pode ser diferente na sua janela.

Note Você deve estar no console no servidor web quando você executa Adplus no modo de falha. Não é possível executar Adplus remotamente no modo de falha.

Agora você está pronto para gerar uma falha! Clique no botão na página para travar o processo do operador. Se você tiver depuração JIT ativado no Visual Studio. NET, uma caixa de diálogo será exibida informando que ocorreu uma exceção, mas o depurador anexado não pôde lidar com ele. Se você não tiver JIT depuração ativada, o arquivo de despejo será criado sem qualquer caixas de diálogo seja exibidas. Em ambos os casos, após você ver o botão CDB desaparecem da barra de tarefas, o arquivo de despejo foi concluída e você está pronto para passar para a próxima etapa.

Check-out o arquivo de despejo

1. Inicie o WinDbg.
2. No menu arquivo , clique em Abrir pane despejo para abrir o arquivo de despejo. (Não clique em Abrir botão na barra de ferramentas.)
3. Vá para a pasta C:\Crashdump. Nessa pasta, você verá outra pasta com um nome longo que começa com Crash_Mode_Date. Adplus salvo os arquivos dentro da pasta de despejo. (Você deve ter mais de um arquivo de despejo na pasta.) O arquivo de despejo que você deseja abrir no WinDbg é o arquivo de despejo do 2 º chance de exceção. Deve ser óbvio pelo nome do arquivo qual arquivo de despejo é o arquivo de despejo do 2 º chance de exceção.

Depois que você já abriu o arquivo de despejo, o WinDbg iniciará Baixando símbolos. Dependendo da velocidade da conexão com a Internet, esse processo pode levar vários minutos. Quando ela é concluída, você verá o prompt de comando aparecem no WinDbg, como mostrado na figura a seguir.Figura 1: WinDbg - O "0: 000 >" no comando prompt indica o segmento atual, o segmento 0.

Você pode ver a pilha de falha, digitando o comando kb no prompt de comando. Aqui é a saída do arquivo de despejo:


Note Se você estiver executando em um sistema com vários processadores (ou um sistema hyper-threaded), você verá chamadas de função em mscorsvr em vez de mscorwks.

Você pode ver os nomes de função no mscorwks.dll porque WinDbg baixado símbolos para mscorwks. No entanto, após as chamadas em mscorwks, você vê nenhum nome de módulo e nenhum nome de função. Que é o código gerenciado (código é executado no Common Language Runtime) é semelhante no WinDbg por padrão, e é obviamente não saída úteis. Para ver o que aconteceu em que o código gerenciado, você precisará usar a extensão SOS para WinDbg.

A extensão SOS

SOS é uma extensão para WinDbg que lhe permite depurar código gerenciado. SOS adiciona muitos comandos ao WinDbg, que são voltadas para depuração de aplicativos gerenciado e muitas são específicos do ASP.NET. A extensão é um arquivo DLL chamado sos.dll e está localizado na pasta Clr10 da pasta onde as ferramentas de depuração para Windows estão instaladas.

Para carregar a extensão SOS, digite o seguinte comando no prompt de comando no WinDbg:Não ignore o período no início do comando! Se tudo correr bem, você será levado novamente ao prompt de comando. Se ocorrer um erro, verifique se você tem a versão mais recente das ferramentas de depuração para Windows instalado.

Abordaremos alguns dos comandos do SOS para o arquivo de despejo de falha de depuração, mas fique à vontade explorar os outros comandos SOS no seu próprio tempo. Você pode usar o ! ajudar comando para obter uma lista de comandos e uma breve descrição de cada.

Compreendendo a causa raiz

Agora que o SOS foi carregado, vamos tem uma olhada em alguns dos comandos que são úteis na solução de um arquivo de despejo de memória.

Vamos examinar a pilha gerenciada para o segmento atual, segmento 0. Faremos o que usando o ! clrstack comando. Tipo ! clrstack no prompt de comando. WinDbg inicia despejar a pilha. Uma pilha normal deve despejar completamente em apenas alguns segundos. Nesse caso, a saída parece ir para sempre. Vá em frente e pressione CTRL-BREAK (ou clique em quebra no menu de depuração no WinDbg) e vamos examinar. Here's a portion of the stack: If you look closely, you'll see a pattern here. Começamos processar a solicitação e gerar um PostBack. O evento OnClick, em seguida, é acionado para um botão. Que resulta em um Server.Transfer. Em seguida, parece o Server.Transfer iniciar todos os todo o processo novamente. Nesse caso, cada vez que esse loop é executado, objetos são colocados na pilha. Finalmente, o sistema ficar sem espaço de pilha e uma StackOverflowException ocorre.

Para ter uma idéia melhor do que aconteceu com aqui, você pode obter saída mais detalhada da pilha executando o ! clrstack -s comando. Isso lhe dá a pilha cheia. Eis alguns essa saída. Para a saída completa desse comando, crie um arquivo de despejo usando a página de exemplo e, em seguida, execute o comando. Eu ter editado-lo aqui porque a saída é muito extenso. você pode dizer deste que a chamada para Server.Transfer está passando crash.aspx como um parâmetro de saída. Como você pode dizer que? Uma indicação é que a página que é executado após a chamada é crash.aspx. No entanto, você também pode dizer, observando o objeto HttpRequest.

Você pode ver o objeto HttpRequest nesta pilha, então, vamos dê uma olhada no que para ver o que foi passado na solicitação. Faremos o que usando o comando de objeto de despejo, ! fazer . Esse comando assume um parâmetro: o endereço do objeto para despejar. Na saída anterior, o endereço é o segundo número hexadecimal na saída.

Aqui é a saída do objeto HttpRequest. Editar essa saída para fins de brevidade. nessa saída, você pode ver o objeto _filePath. Se você despejar que usando o ! fazer comando, você verá que ele é uma seqüência de caracteres que contém "/ crash.aspx". Isso confirma que a recursão é causada por crash.aspx carregando recursivamente. Por que é que acontecendo Embora? Vamos aprofundar mais profundo.

Examinar a saída de volta ! clrstack . Se você examinar cuidadosamente, você verá que o evento Click do botão está disparando sempre que a página for carregada. Isso informa que você está em um estado de PostBack cada vez as cargas de página. Você também pode dizer da pilha que Server.Transfer é chamado em que evento Click . Portanto, para impedir que o ASP.NET falhando quando esta página é carregada, você precisará impedir isso sendo cada vez que a página é carregada devido ao Server.Transfer um PostBack.

Note Se você fizer um Server.Transfer no ASP.NET Framework 1.1 com o SP1 instalado e você mantém dados de formulário, sempre fará com que esse problema. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: O método Server.Transfer tem dois parâmetros; a primeira é a URL para o qual a execução deve transferir e o segundo é um Boolean que especifica se os dados do formulário devem ser mantidos. O que acontece se nós manter os dados do formulário? Primeiro, o ASP.NET irá considerar que um PostBack. Você pode, portanto, interromper essa falha, definindo o segundo parâmetro como a chamada Server.Transfer para false.

Encapsulá-la

Este artigo apresentou uma breve explicação passo a passo de como você pode usar o WinDbg e SOS para depurar seus aplicativos ASP.NET. O objetivo deste artigo foi apresentar a você alguns dos conceitos e terminologia envolvida na depuração de modo de usuário. É uma habilidade definir que o código-fonte depuração e obter boa-requer um investimento de tempo significativo. É uma habilidade que aprendeu pela experiência.
Para obter mais experiência, recomendo que você carregar seu aplicativo ASP.NET em um ambiente de teste ou desenvolvimento e captura alguns arquivos de despejo travar em momentos diferentes. Você pode fazer isso executando Adplus no modo de paralisação, usando o comando a seguir:
Esse comando irá despejar o processo aspnet_wp.exe imediatamente e criar um arquivo de despejo na pasta C:\Aspnet_dump. Um arquivo de despejo travar como isso pode ser executado de uma conexão remota.

Microsoft grupo padrões e práticas (PAG) também escreveu alguns artigos excelentes e detalhados sobre depuração de aplicativos .NET usando WinDbg. Visite o seguinte site para exibir esses artigos: Na verdade, um dos meus objetivos em escrever este artigo foi fornecer-lhe a base necessária para aproveitar os artigos excelentes PAG forneceu. Altamente recomendo que você aproveite-los.

Vejo você volta aqui próximo mês quando eu ensina como usar WinDbg e a extensão SOS para analisar arquivos de despejo de falha. Até próxima vez,

Jim Cheshire
Engenheiro de suporte
Microsoft Developer Support

Como sempre, vontade enviar idéias sobre tópicos desejado no futuro abordada colunas ou na Base de dados de Conhecimento usando o formulário Ask For It (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) .