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 (https://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:
- Baixar os símbolos públicos do Windows: https://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx
- Ter um conhecimento básico de WinDbg. Para isso instale e veja o help do WinDbg:
https://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:
https://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/
https://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/
https://mtaulty.com/blog/%28qpfuv145clrvlf5520rplrfo%29/archive/2004/08/03/608.aspx
https://mtaulty.com/blog/%28xvr5rffxvkzjgc55h5jocynf%29/archive/2004/08/03/609.aspx
https://www.eggheadcafe.com/articles/20060114.asp
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dbgch02.asp
https://www.codeproject.com/debug/windbg_part1.asp
https://www.codeproject.com/debug/windbg_part1.asp
https://www.codeproject.com/debug/cdbntsd7.asp
https://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