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!

Skip to main content