Criando Scripts para o DebugDiag



Criando Scripts para o DebugDiag


Por: Roberto Farah


 


Porque você gostaria de criar seus próprios scripts de DebugDiag?


 


DebugDiag  (http://www.debugdiag.com) é uma ferramenta para coleta de Hang  e Crash dumps. DebugDiag foi primeiramente projetada como uma ferramenta para IIS, entretanto, a ferramenta evoluiu (desde os tempos de DebugMonitor, DebugMatrix e, então DebugDiag) e hoje pode ser usada para coleta de dumps de praticamente qualquer aplicação.


DebugDiag pode rodar como um serviço, o que a torna útil em cenários onde o ADPlus não poderia ser usado. DebugDiag pode, de modo mais simples, coletar dumps para cenários de Memory Leak, pois a ferramenta incorpora o mecanismo usado no LeakDiag para trilhar as stacks alocando/desalocando memória.


Pois bem, o ponto forte do DebugDiag, a meu ver, é sua capacidade de fazer análise de dumps. Ok, análise de dump automatizada é algo como geração de código automatizada, ou seja, útil na maioria das vezes mas limitado quando precisamos mais.


Continuando a analogia, essa é a hora que você altera o código gerado automaticamente ou a hora que você precisa analisar o dump manualmente.


Entretanto, nesse artigo vou falar sobre análise automatizada de dumps. Voltando ao assunto, quando você coleta um dump com DebugDiag você pode usá-lo para analisar o dump.


Para fazer a análise, DebugDiag usa extensões. Extensões são dlls ou objetos COM que extendem a funcionalidade do depurador.


No PPT em anexo descrevo o relacionamento entre as partes, mas por ora basta saber do seguinte fluxo:


DebugDiag à carrega script à Script usa extensão e analisa dump.


 


Se você já usou DebugDiag esses termos não devem assustá-lo.


Ok, num cenário típico você coleta um dump, digamos um Hang dump do seu processo ASP_NET.EXE que está em hang. Em seguida você usa a feature de análise do DebugDiag e obtém um relatório.


Dependendo do resultado você pode abrir um chamado no Suporte da Microsoft ou talvez você mesmo descubra a causa do problema através do relatório e o arrume.


 


O ponto aqui é: DebugDiag usará nossos scripts para analisar as aplicações com foco nos nossos produtos/tecnologias. Com isso nós saberemos se poderemos ter um problema no nosso código (Microsoft) ou no seu código. Obviamente o conhecimento dos nossos produtos nos permite criar extensões e scripts que analisarão informações importantes dos dumps, relacionadas com nossos produtos.


 


A SACADA


 


DebugDiag sendo usado com nossos scripts e extensões é muito útil. Mas ele pode ser muito mais útil! E é isso que ensinarei. Você pode usar o engine do WinDbg como, faz o DebugDiag, a partir de um script criado por você para analisar suas próprias aplicações!!!


Em outras palavras, você coleta um dump, usa nossos scripts e o seu script para analisar os dumps. Com isso você terá muito mais informação para arrumar o problema por si só ou para escalar para nós o problema!


CENÁRIOS


 


Para ilustrar a idéia, imagine o seguinte:


– Um script que usa a SOS.DLL (extensão para análise de managed code) para trilhar problemas de memória sem que você tenha que abrir o dump com o depurador e fazer isso manualmente e coloque isso num relatório fácil de ler que você pode enviar para seu cliente ou sua equipe de desenvolvimento, com recomendações de potenciais problemas e como solucionar. (para sua felicidade esse script é um dos exemplos que forneço! J )


– Um script que analisa determinados campos de estruturas ou classes de componentes da sua solução (seja ela feita em native ou managed code) e reporta, de modo alto nível, se sua aplicação tinha o estado esperado e, se não, quais as potenciais causas do problema e ações a serem tomadas.


– Um script que analisa dumps de suas aplicações e efetua estatísticas de quais os componentes que geram maior número de exceções fatais.


 


Enfim, você pegou a idéia. Para fazer esse tipo de análise, onde você precisa de acessar informação interna da sua aplicação você, o desenvolvedor, é a pessoa que poderá fazer isso mais facilmente.


 


NOTE O SEGUINTE…


 


Analisando um dump manualmente é possível, mesmo sem símbolos, se saber detalhes internos da aplicação. Mas, a questão não é apenas se acessar a informação, é saber que conclusão tirar dela! Exemplo: Depurando um hang dump de aplicação com inúmeras classes a informação que m_bReportLevel = 3 será muito mais valioso para o desenvolvedor da aplicação do que para o engenheiro depurando o dump. Saber o estado dessa propriedade pode ser a pista decisiva para o desenvolvedor achar o problema rapidamente. Considere que análise de dumps é algo demorado e complicado, portanto, quanto mais você, o desenvolvedor, souber sobre sua aplicação no momento de algum problema mais chances você terá de localizar o problema (se isso já não tiver sido efetuado de modo automatizado J ) antes de nós!


 


OK, ENTÃO ME MOSTRE!


 


No link abaixo você poderá baixar um documento PowerPoint onde descrevo o relacionamento entre extensões normais, extensões COM, engine do WinDbg e scripts de DebugDiag.


Além disso, explico como você pode criar seus próprios scripts, juntamente com 3 exemplos de scripts.


O primeiro faz uma chamada de extensão de DebugDiag para efetuar uma operação e faz a mesma coisa sem a extensão, apenas usando comandos do WinDbg.


O segundo usa a SOS.DLL para verificar problemas comuns de memória com aplicações .NET.


O terceiro exemplo mostra como você acessaria informação exclusiva da sua aplicação via engine do WinDbg através dos scripts de DebugDiag.


 


Aliado a isso estou trabalhando num quarto exemplo que pretendo colocar futuramente. Esse será um exemplo de script que faz um troubleshooting básico inicial e recomenda ações e não depende de conhecimento interno de aplicações. Bom, isso é conteúdo para outro artigo! J


 


PARA SUMARIZAR


 


O que você precisa para fazer scripts para analisar dumps de suas aplicações é, acredito que nessa ordem de prioridade:


 


– Saber fazer scripts.


 


– Compilar suas aplicações SEMPRE para gerar arquivos PDB (símbolos). Cheque como fazer isso no ambiente que você usa: Visual C++, Visual Basic 6. No VS .NET símbolos são gerados por default.


Para mais informações:


http://support.microsoft.com


 


– Baixar os símbolos públicos do Windows: http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx


 


– Ter um conhecimento básico de WinDbg. Para isso instale e veja o help do WinDbg:


http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx


 


E os links abaixo que são uma ótima referência sobre depuração de código nativo e gerenciado:


 


http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/


http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/


http://mtaulty.com/blog/%28qpfuv145clrvlf5520rplrfo%29/archive/2004/08/03/608.aspx


http://mtaulty.com/blog/%28xvr5rffxvkzjgc55h5jocynf%29/archive/2004/08/03/609.aspx


http://www.eggheadcafe.com/articles/20060114.asp


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dbgch02.asp


http://www.codeproject.com/debug/windbg_part1.asp


http://www.codeproject.com/debug/windbg_part1.asp


http://www.codeproject.com/debug/cdbntsd7.asp


http://www.codeproject.com/debug/cdbntsd5.asp


 


– Baixe e leia o PPT e os 3 demos desse artigo. Altere-os, modifique-os, brinque com o código para se familiarizar. O PPT está aqui neste link.


 


Até o próximo artigo. 😉


 


Roberto Farah

Comments (2)

  1. marcio says:

    Muito bom!

    Minha sugestão para o próximo artigo é "iniciação dos administradores de sistema no mundo do Debugging". Acredito que isso faria a categoria dos admins se livrar do popular "é culpa do sistema operacional".

  2. Roberto Farah says:

    Oi Marcio! Há um artigo que vai ser publicado hoje que é sobre usar o DebugDiag rapidamente para coletar e analisar dumps.

    Na verdade eu deveria ter publicado esse novo artigo primeiro, por ser mais genérico…

    Acho que ele vai de encontro ao que você propôs.

    Obrigado!