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

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 892277
Coluna de voz de suporte do ASP .NET

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

para personalizar esta coluna às suas necessidades, queremos convidá-lo para enviar suas idéias sobre tópicos que interessam a você e problemas que você deseja ver abordados artigos do Knowledge Base no futuro e colunas de voz de suporte. Você pode enviar suas idéias e comentários usando o formulário Ask For It. Há também um link para o formulário na parte inferior desta coluna.
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:
286350Como usar o ADPlus para solucionar problemas de "trava" e "falhas"
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.
 WinDBg window
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:
0:000> kbChildEBP RetAddr  Args to Child              00771018 791b6173 00000643 00000000 00b59bc0 mscorwks!_EH_prolog+0x200771928 791b60c0 00771a04 00000000 00000000 mscorwks!EEClass::DoRunClassInit+0xbe0077193c 791d75a7 00771a04 00771a50 00b59bc0 mscorwks!MethodTable::CheckRunClassInit+0x1d00771a14 791d7746 00000000 0086fb88 00771a50 mscorwks!MethodDesc::DoPrestub+0x28e00771a2c 00a92f76 00771a50 0180f154 00ee5cd4 mscorwks!PreStubWorker+0x42WARNING: Frame IP not in any known module. Following frames may be wrong.00773a38 0337f2bc 00f8463c 00eb593c 00ee5cc8 0xa92f7600773a64 031cd7e4 00eb593c 0180ea7c 00f84560 0x337f2bc00773aac 033a3299 00000000 00eb593c 0180ea7c 0x31cd7e400773b50 033a3031 00000001 00000000 0180e238 0x33a329900773bec 0332ee47 00edb274 0180df00 00f8463c 0x33a303100773c28 0332e71b 0180df00 033a35c5 0180d870 0x332ee4700773cc4 033a3031 00000001 00000000 0180d2b4 0x332e71b00773d60 0332ee47 00edb274 0180cf7c 00f8463c 0x33a303100773d9c 0332e71b 0180cf7c 033a35c5 0180c8ec 0x332ee4700773e38 033a3031 00000001 00000000 0180c330 0x332e71b00773ed4 0332ee47 00edb274 0180bff8 00f8463c 0x33a303100773f10 0332e71b 0180bff8 033a35c5 0180b968 0x332ee4700773fac 033a3031 00000001 00000000 0180b3ac 0x332e71b00774048 0332ee47 00edb274 0180b074 00f8463c 0x33a303100774084 0332e71b 0180b074 033a35c5 0180a9e4 0x332ee47


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:
.Load clr10\sos
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:
Void System.Web.HttpServerUtility.ExecuteInternal(String,Class System.IO.TextWriter,Boolean)Void System.Web.HttpServerUtility.Transfer(String,Boolean)Void ASP.crash_aspx.btnCrash_Click(Object,Class System.EventArgs)Void System.Web.UI.WebControls.Button.OnClick(Class System.EventArgs)Void System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String)Void System.Web.UI.Page.RaisePostBackEvent(Class System.Web.UI.IPostBackEventHandler,String)Void System.Web.UI.Page.RaisePostBackEvent(Class System.Collections.Specialized.NameValueCollection)Void System.Web.UI.Page.ProcessRequestMain()Void System.Web.UI.Page.ProcessRequest()Void System.Web.UI.Page.ProcessRequest(Class System.Web.HttpContext)Void System.Web.HttpServerUtility.ExecuteInternal(String,Class System.IO.TextWriter,Boolean)Void System.Web.HttpServerUtility.Transfer(String,Boolean)Void ASP.crash_aspx.btnCrash_Click(Object,Class System.EventArgs)Void System.Web.UI.WebControls.Button.OnClick(Class System.EventArgs)Void System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String)Void System.Web.UI.Page.RaisePostBackEvent(Class System.Web.UI.IPostBackEventHandler,String)Void System.Web.UI.Page.RaisePostBackEvent(Class System.Collections.Specialized.NameValueCollection)Void System.Web.UI.Page.ProcessRequestMain()Void System.Web.UI.Page.ProcessRequest()Void System.Web.UI.Page.ProcessRequest(Class System.Web.HttpContext
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.
0:000> !clrstack -sThread 0System.Web.HttpServerUtility.ExecuteInternal(String,Class System.IO.TextWriter,Boolean)    ESP/REG  Object   Name    00773ac4 0180e7f4 System.EventArgs    00773ac8 00f86c14 System.Web.HttpServerUtility    00773acc 0180e238 System.Web.UI.WebControls.Button    00773ad0 0180eac0 System.Object[]    00773ad4 0180ea7c System.String    /crash.aspx    00773ad8 00eb593c System.String    c:\inetpub\wwwroot\crash.aspx    00773ae4 00f84754 System.Web.HttpResponse    00773ae8 00f846bc System.Web.HttpRequest    00773b00 00f86bec System.String    crash.aspx    00773b04 00f86c14 System.Web.HttpServerUtility    00773b2c 00eef57c System.String    btnCrash    00773b34 00eef57c System.String    btnCrash 00773b38 0180e2e4 System.Collections.Specialized.ListDictionary/DictionaryNode    00773b44 00f797d8 System.String    CausesValidation    00773b4c 0180e2e4 System.Collections.Specialized.ListDictionary/DictionaryNode00773b60  033a3031 [DEFAULT] [hasThis] Void System.Web.HttpServerUtility.Transfer(String,Boolean)    ESP/REG  Object   Name    00773b60 0180e238 System.Web.UI.WebControls.Button00773b6c  03360398 [DEFAULT] [hasThis] Void ASP.crash_aspx.btnCrash_Click(Object,Class System.EventArgs)    ESP/REG  Object   Name    00773b70 0180e7f4 System.EventArgs00773b74  033a2fc5 [DEFAULT] [hasThis] Void System.Web.UI.WebControls.Button.OnClick(Class System.EventArgs)    ESP/REG  Object   Name    00773b74 0180df00 ASP.crash_aspx    00773b78 0180e238 System.Web.UI.WebControls.Button    00773b7c 00f8601c System.Web.HttpValueCollection    00773b80 0180e314 System.ComponentModel.EventHandlerList00773b88  033a2da2 [DEFAULT] [hasThis] Void System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String)
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.
0:000> !do 00f846bc Name: System.Web.HttpRequestMethodTable 0x03089170EEClass 0x02e9a1ccSize 152(0x98) bytesmdToken: 02000072  (c:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll)FieldDesc*: 030888b0      MT    Field   Offset                 Type       Attr    Value Name03089170  4000626       14                CLASS   instance 00f8457c _path03089170  4000627       8c       System.Boolean   instance 0 _computePathInfo03089170  4000628       18                CLASS   instance 00f8457c _filePath03089170  400062e       2c                CLASS   instance 00f845a4 _pathTranslated03089170  400062f       30                CLASS   instance 00e6703c _baseVirtualDir03089170  4000630       34                CLASS   instance 00edce64 _contentType03089170  4000631       88         System.Int32   instance 85 _contentLength03089170  400063c       60                CLASS   instance 00f8601c _form
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:
839521CORRECÇÃO: O método Server.Transfer causa um estouro de pilha e faz com que o processo do operador ASP.NET pare de responder
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:
cscript adplus.vbs - travar - pn aspnet_wp.exe -o c:\aspnet_dump

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.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 892277 - Última Revisão: 05/18/2007 08:38:17 - Revisão: 2.4

Microsoft ASP.NET 1.1, Microsoft ASP.NET 1.0

  • kbmt kbhowto kbasp KB892277 KbMtpt
Comentários