Resolução de problemas ASP.NET utilizando o WinDbg e a extensão SOS

Olá novamente e bem-vindo à edição de Janeiro de 2005 da coluna de voz de suporte. Uma vez mais, Quero agradecer Cheshire Jaime, um engenheiro de suporte aqui no Microsoft ASP.NET, de suporte para as suas contribuições. Jaime tem grandes ideias para a coluna voz de suporte e pretende continuar a partilhá-los. Consulte para contribuições do Jaime último mês e o mês seguinte e e como sempre, envie-nas sugestões para colunas futuras. Jaime Obrigado!

Jaime tem estado a trabalhar com o Microsoft seis anos em equipas do FrontPage, VB e ASP.NET. Durante esse período, ele foi escrito para o Office Developer Center na MSDN e ele é o autor de um livro no FrontPage, Special Edition utilizando o Microsoft Office FrontPage 2003 . Jaime também tem um Web site onde ele fornece livres suplementos para o FrontPage permitem aos programadores Web tornar o máximo partido dos produtos Microsoft. Segue-se esse endereço de Web site: Por isso, por favor, solicitação de uma cadeira, kick desactivar sapatos, leia a nossa coluna tudo sobre resolução de problemas de ASP.NET e lembre-se, pode submeter as ideias-nos utilizando a hiperligação "ASK FOR TI" incluída no cada coluna que publicar.
Jeremy

Resolução de problemas ASP.NET utilizando o WinDbg e a extensão SOS

Um programador boa será Planear qualquer contingência. Naturalmente, parte do planeamento que está a desenvolver algumas excepções robustas rotinas de tratamento. Muitos programadores ASP.NET processará excepções apresentar ao utilizador com uma página Web agradável e, em seguida, iniciando as informações de excepção num ficheiro para posterior análise.

Cenário:

ter desenvolvido e testado uma nova aplicação do ASP.NET que inicia excepções num ficheiro de registo. Implementar as páginas ASPX e as assemblagens do servidor Web de produção. Quando as pessoas utilizam a aplicação, estão a ver uma página de erro, mas nenhum registo de excepção é escrito os ficheiros de registo. Também verificar que existem muitos eventos ASP.NET no registo Visualizador de eventos de aplicações do dizer aspnet_wp.exe parou inesperadamente.

Este é um tipo de problema que vemos no suporte de programação comuns e a maioria dos nossos clientes não realmente sabe abordar a resolução de problemas. É mesmo pior a mensagem de erro "Aplicação de servidor indisponível" dreaded. Este mês, mostra como pode resolver estes tipos de problemas com o Debugging Tools for Windows.

exclusão de responsabilidade: Se contactar o suporte para programadores da Microsoft, poderá pedir frequentemente-lhe para nos enviar um ficheiro de informação de falha ou um ficheiro de informação não reagir. A análise do ficheiro de informação neste artigo será muito mais fácil e rápida. Em muitos casos, a causa de um problema não é evidente e pode demorar várias horas de análise para ir para a causa. Não deixe que a facilidade e rectas-forwardness desta análise do ficheiro de informação enganar para pensar que são fáceis todos nesta. A maior parte, de facto, não é!

Obter preparado

Antes que começar, é necessário instalar as ferramentas de depuração para o Windows. Mesmo se já tiver uma cópia instalada, certifique-se apenas que ter a versão mais recente uma vez que é irá estar a utilizar uma extensão para geridos depuração que é incluído com a versão mais recente do Debugging Tools for Windows.

Pode transferir o Debugging Tools for Windows a partir do seguinte Web site da Microsoft: Quando instala o Debugging Tools for Windows, convém efectuar uma instalação personalizada para a pasta C:\Debuggers. É irá estar a executar ferramentas da linha de comandos, e se o caminho for uma mais pequena, irá facilitar ao fazê-lo assim. Depois de concluída a instalação, poderá transferir a página ASP.NET de exemplo que irá falhar o processo de trabalho. Note que para que a de poder gerar o ficheiro de informação utilizando esta página, é necessário ter o ASP.NET 1.1 com o Service Pack 1 (SP1) instalado. Sem o SP1, esta página será executada sem gerar uma falha.

Também poderá configurar o caminho de símbolos para WinDbg. Símbolos não são necessários para a função de resolução de nomes em assemblagens geridas, mas terá de símbolos para a resolução nativa função. Para definir o caminho de símbolos no WinDbg:

1. Abra o WinDbg. Clique em Iniciar , aponte para Todos os programas e, em seguida, clique em Ferramentas de depuração para o Windows .
2. No menu ficheiro , clique em Símbolo caminho do ficheiro .
3. Na caixa de diálogo Símbolo caminho , escreva o seguinte caminho de símbolos:
   SRV*c:\Symbols*http://MSDL.Microsoft.com/download/symbols
4. Feche o WinDbg e escreva Sim na linha de comandos para guardar informações base da área de trabalho.

Agora está pronto para criar o ficheiro de informação de falha.

Criar ficheiro de informação de falha

Neste guia passo a passo, clicando no botão na página de exemplo irá causar o trabalho ASP.NET do processo falha. Em muitos casos, não sabe passos precisos para gerar uma falha. Na realidade, a aplicação de produção poderá falhar algum momento aleatório. Como em breve poderá ver, não interessa se ocorre uma falha predictably ou aleatoriamente. Criar um ficheiro de informação é bastante fácil utilizar Adplus, o ficheiro de VBScript que automatiza todo o processo.

Para gerar o ficheiro de informações de estado, precisar de navegar primeiro para a página de exemplo. (Não clique no botão!) Depois da página tiver sido servida com êxito, sabe que o processo Aspnet_wp.exe (ou o processo W3wp.exe no Windows Server 2003) foi iniciado. Agora está pronto para anexar o depurador o processo de trabalho, de modo que pode capturar um ficheiro de informação quando-falha.

Para criar um ficheiro de informação:

1. Abra numa linha de comandos nova no servidor web e, em seguida, altere o directório onde o Debugging Tools for Windows estão instalado.
2. Execute o seguinte comando:
   cscript adplus.vbs - falha - pn aspnet_wp.exe -o c:\crashdump
   Se estiver a executar o Microsoft Windows Server 2003, execute o seguinte comando:
   cscript adplus.vbs - falha - pn w3wp.exe -o c:\crashdump

Não vou em grande detalhe no Adplus.vbs aqui, mas se pretender obter mais informações, pode rever o seguinte artigo base de dados de conhecimento da Microsoft:Depois de executar este comando, será apresentada com algumas caixas de diálogo. Clique em OK em cada caixa de diálogo. Deverá ver agora um botão da barra de tarefas para o depurador, CDB, o nome de aplicação para o depurador. No entanto, poderá ser diferente na janela do.

Note Tem de ser na consola no servidor web quando executa Adplus no modo de falha. Não pode executar remotamente Adplus no modo de falha.

Agora está pronto para gerar uma falha! Clique no botão na página falha o processo de trabalho. Se tiver a depuração JIT activado no Visual Studio. NET, aparece uma caixa de diálogo permitindo-lhe saber que ocorreu uma excepção mas não foi possível processar o depurador anexado. Se não tiver JIT depuração activada, será criado o ficheiro de informação sem quaisquer caixas de diálogo sejam apresentadas. Em qualquer dos casos, depois de ver o botão CDB desaparecer da barra de tarefas, o ficheiro de informações de estado terminou, e está pronto para avançar para o passo seguinte.

Dar saída do ficheiro de informações de estado

1. Inicie o WinDbg.
2. No menu ficheiro , clique em Abrir Crash Dump para abrir o ficheiro de informação. (Não clique em Abrir botão da barra de ferramentas.)
3. Navegue para a pasta C:\Crashdump. Nessa pasta, verá noutra pasta com um nome extenso que começa com Crash_Mode_Date. Adplus guardado os ficheiros de informações de estado dentro de nesta pasta. (Deverá ter mais do que um ficheiro de informação na pasta.) O ficheiro de informação que pretende abrir no WinDbg é o 2 º ficheiro de informação de excepção de oportunidade. Deve ser óbvio com o nome do ficheiro que ficheiro de informação é o ficheiro de 2ª informação de excepção de oportunidade.

Depois de ter aberto o ficheiro de informações de estado, WinDbg iniciará a transferir símbolos. Dependendo da velocidade da ligação à Internet, este processo pode demorar vários minutos. Quando é concluída, poderá ver a linha de comandos aparecem no WinDbg, tal como mostrado na figura seguinte.Figura 1: WinDbg - A "0: 000 >" no comando prompt indica o thread actual, thread 0.

Pode ver a pilha em escrevendo o comando kb na linha de comandos. Segue-se a saída do ficheiro de informação:


Note Se estiver a executar um sistema com múltiplos processadores (ou um sistema de hiper-threaded), verá função chama mscorsvr em vez de mscorwks.

Pode ver os nomes de função na mscorwks.dll porque WinDbg transferidos símbolos de mscorwks. No entanto, após as chamadas para mscorwks, vê não nomes de módulo e não nomes de função. É o código gerido (código que seja executado no Common Language Runtime) aspecto WinDbg por predefinição e é obviamente não saída úteis. Para ver o que aconteceu em código gerido, terá de utilizar a extensão SOS para WinDbg.

A extensão SOS

SOS é uma extensão para WinDbg permite-lhe depurar código gerido. SOS adiciona muitos comandos WinDbg, que são direccionadas para a depuração de aplicações geridas e muitos são específicos do ASP.NET. A extensão é um ficheiro DLL denominado sos.dll e está localizado na pasta Clr10 na pasta onde o Debugging Tools for Windows estão instalado.

Para carregar a extensão SOS, escreva o seguinte comando na linha de comandos em WinDbg:Não ignore o período no início do comando! Se todos os vai também, vai ser obtido novamente à linha de comandos. Se ocorrer um erro, certifique-se de que que a versão mais recente do Debugging Tools for Windows instalado.

Vamos abordar alguns dos comandos de SOS para o ficheiro de informação de falha de depuração, mas vontade explorar os comandos SOS no seu próprio tempo. Pode utilizar o ! ajudar comando para obter uma lista de comandos e uma breve descrição de cada um.

Digging into causa raiz

Agora que SOS foi carregado, vamos observe alguns dos comandos que são úteis na resolução de um ficheiro de informação de falha.

Observemos a pilha de gerido para o thread actual, o thread 0. Vai fizermos que utilizar o ! clrstack comandos. Tipo ! clrstack na linha de comandos. WinDbg começa a copiar a pilha. Uma pilha normal deve copiar completamente fora em apenas alguns segundos. Neste caso, a saída parece Ir para sempre. Avançar e prima CTRL-BREAK (ou clique em quebra no menu Debug em WinDbg) e observe vamos. Here's a portion of the stack: If you look closely, you'll see a pattern here. É iniciado desactivar processar o pedido e aumentar uma PostBack. Em seguida, o acontecimento AoFazerClique é desencadeado para um botão. Que resulta num Server.Transfer. O método Server.Transfer parece iniciar o processo completo tudo de novo. Neste caso, cada vez que este ciclo executa, objectos serão eliminados para a pilha. Eventualmente, o sistema fica sem espaço na pilha e ocorre uma StackOverflowException.

Para ter uma ideia melhor do que aconteceu aqui, pode obter resultados mais detalhado da pilha executando o ! clrstack -s comandos. Isto dá-lhe a pilha completa. Eis algumas dessa saída. Para a saída completa deste comando, crie um ficheiro de informação utilizando a página de exemplo e, em seguida, execute o comando. Editou-lo aqui porque o resultado é bastante verboso. pode indicar aqui que a chamada de Server.Transfer é passar crash.aspx como um parâmetro de saída. Como saber que? Uma indicação é que a página que é executado após a chamada crash.aspx. No entanto, pode também saber observando o objecto HttpRequest.

Pode ver o objecto HttpRequest nesta pilha, Vamos observar que consulte o que foi transmitido esse pedido. Vai fizermos esse utilizando comando de objecto dump, ! fazer . Este comando assume um parâmetro: o endereço do objecto a copiar. Na saída anterior, o endereço é o segundo número hexadecimal no resultado.

Aqui é o resultado do objecto HttpRequest. Editou este resultado para benefício da brevity. este resultado, pode ver o objecto _filePath. Se copiar esse utilizando o ! fazer comandos, verá que é uma cadeia que contém "/ crash.aspx". Isto confirma que a recursividade é causada por crash.aspx carregar recursivamente. Por que razão é que acontecer Embora? Vamos dig mais profunda.

Observe novamente o resultado do ! clrstack . Se parecer com cuidado, verá que o evento Click do botão é accionar sempre a página é carregada. Isto indica que estão num estado reposição cada vez as cargas de página. Pode também saber da pilha que Server.Transfer é designada por esse evento clicar . Por conseguinte, para impedir que o ASP.NET bloquear quando esta página é carregada, é necessário impedir que isto seja uma PostBack sempre que a página é carregada a de Server.Transfer.

Note Se o fizer um Server.Transfer no ASP.NET Framework 1.1 com o SP1 instalado e reter dados de formulário, é sempre fará com que este problema. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: O método Server.Transfer tem dois parâmetros; o primeiro é o URL para o qual deve transferir execução e o segundo é um valor boleano que especifica se os dados do formulário deverão ser mantidos. O que acontece se é manter os dados do formulário? Por um elemento, o ASP.NET vai considerar que uma PostBack. Pode, por conseguinte, deixar esta falha definindo o segundo parâmetro para a chamada de Server.Transfer para false.

Moldagem

Este artigo apresentado uma breve instruções de como pode utilizar o WinDbg e SOS para depurar as aplicações do ASP.NET. O objectivo deste artigo foi para lhe apresentar alguns dos conceitos e terminologia envolvida no modo de utilizador de depuração. É uma dificuldade diferente definir do código de depuração e bom-lo a obter requer um investimento de tempo significativo. É uma competência conhecida pela experiência.
Para experiência mais, recomenda a carregar a aplicação do ASP.NET num ambiente de teste ou de desenvolvimento e captura alguns ficheiros de informação não reagir em alturas diferentes. Poderá fazê-lo executando Adplus no modo não reagir utilizando o seguinte comando:
Este comando vai copiar imediatamente o processo aspnet_wp.exe e criar um ficheiro de informação na pasta C:\Aspnet_dump. Um ficheiro de informação não reagir tal como esta pode ser executado a partir de uma ligação remota.

Microsoft grupo de padrões e práticas (PAG) também escreveu alguns artigos excelentes e detalhados depuração de aplicações .NET utilizando WinDbg. Visite o seguinte Web site da Microsoft para visualizar estes artigos: Na verdade, um dos meus objectivos escrever neste artigo era fornecer-lhe a base necessária para tirar partido dos artigos excelentes que forneceu PAG. Vivamente incentivo-o a tirar partido-los.

Vejo aqui novamente quando eu ensinar-lhe como utilizar o WinDbg e a extensão SOS para analisar ficheiros de informação de falha de mês seguinte. Até Data próxima,

Jaime Cheshire
Engenheiro de suporte
Microsoft Developer suporte

Como sempre, vontade submeter ideias tópicos que pretende no futuro corrigida colunas ou na base de dados de conhecimento utilizando o formulário Ask For It (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) .