DbgShell

Um front-end PowerShell para o mecanismo de depuração do Windows.

Pronto para navegar com tab até a glória? Para uma introdução mais rápida, dê uma olhada em Começando.

Avisos

1. Este projeto não é produzido, endossado ou monitorado pela equipe do depurador do Windows. Embora a equipe do depurador receba bem feedback sobre sua API e front-ends (windbg, kd et al), eles não têm conexão com este projeto. Não relate bugs ou feedback à equipe do depurador referentes a este projeto.

2. Este não é um projeto financiado: não possui recursos oficiais alocados a ele, e é trabalhado apenas por voluntários. Não assuma nenhuma dependência de produção neste projeto a menos que você esteja disposto a mantê-lo completamente por conta própria. Sinta-se à vontade para abrir Issues e enviar Pull Requests, mas entenda que, com os recursos voluntários limitados, pode levar algum tempo até que suas submissões sejam tratadas.

3. Este é um projeto experimental: não está totalmente amadurecido, e você deve esperar mudanças significativas frequentemente.

Corolário dos avisos acima: eu evitaria anexar o DbgShell a alvos vivos de alto valor.

Binários

https://aka.ms/dbgshell-latest

Motivação

Você já tentou automatizar algo no depurador? (cdb/ntsd/kd/windbg) Como foi?

O principal ímpeto para o DbgShell é que é extremamente difícil automatizar qualquer coisa no depurador. Existem sim recursos hoje para ajudar na automatização do depurador, claro. Mas na minha opinião eles não estão atendendo às necessidades das pessoas.

• Usar a linguagem de script embutida é arcana, limitada, difícil de acertar e difícil de obter ajuda.
• Escrever uma DLL de extensão de depurador completa é muito poderosa, mas é um investimento significativo — muito custoso para resolver problemas rápidos e "pontuais" enquanto você depura problemas aleatórios do mundo real. Apesar do custo, existe um grande número de extensões de depurador em existência. Acho que não deveria haver tantas; acho que a única razão de existirem tantas é porque não há alternativas viáveis.
• Tentativas existentes de fornecer uma interface melhor (como PowerDbg) são baseadas em "raspagem" e análise de texto, o que é extremamente limitante (para não dizer ideologicamente irritante) e, portanto, não são capazes de cumprir a promessa de uma interface verdadeiramente melhor (são apenas marginalmente melhores, na melhor das hipóteses).
• Tentativas existentes de fornecer uma maneira mais fácil de escrever uma extensão de depurador são meramente uma solução temporária para a dor de desenvolver uma extensão de depurador; elas não resolvem realmente o problema maior. (por exemplo, duas grandes falhas são: ainda são muito de baixo nível (você tem que lidar com a API COM dbgeng), e não há REPL)
• A equipe do depurador introduziu recentemente scripting em Javascript. Javascript é uma linguagem muito melhor (e mais bem definida) do que a antiga linguagem de script do windbg, mas acho que o PowerShell tem algumas vantagens, a maior das quais é que ninguém realmente usa um shell Javascript — o PowerShell é muito melhor como um shell e linguagem de script combinados.

O objetivo do projeto DbgShell é trazer a bondade do mundo orientado a objetos do PowerShell para o mundo da depuração. Quando você faz 'dt' para despejar um 'objeto', você deve obter um objeto real. Scripting deve ser tão fácil quanto escrever um script PowerShell.

O projeto DbgShell fornece um front-end PowerShell para dbgeng.dll, incluindo:

• um "modelo de objeto" gerenciado (utilizável em C# se desejado), que é de nível mais alto do que a API COM dbgeng,
• um "provedor de navegação" PowerShell, que expõe aspectos de um alvo de depuração como um namespace hierárquico (para que você possa "cd" para uma thread específica, digitar "dir" para ver a pilha, "cd" para um quadro, fazer outro "dir" para ver variáveis locais/registradores/etc.),
• cmdlets para manipular o alvo,
• um host PowerShell personalizado que permite melhor controle da experiência CLI do depurador, bem como fornece recursos não disponíveis no host powershell.exe padrão (a saber, suporte para coloração de texto usando códigos de escape ANSI (a la ISO/IEC 6429))

O host personalizado ainda é um programa baseado em linha de comando (conhost.exe) (análogo ao ntsd/cdb/kd), mas pode ser invocado a partir do windbg (!DbgShell).

Além de tornar a automação muito mais fácil e poderosa, também abordará outras preocupações, como facilidade de uso para pessoas que não precisam usar os depuradores com tanta frequência. (uma reclamação que ouvi é que "quando acabo precisando usar windbg, passo todo o meu tempo no .CHM")

Para usuários experientes de windbg, por outro lado, outro objetivo é tornar a transição o mais suave possível. Assim, por exemplo, o provedor de namespace não é a única maneira de acessar dados; você ainda pode usar comandos tradicionais como "~3 s", "k", etc.

O que você quer dizer com "automação" e "scripting"?

Não estou falando apenas do tipo de coisa em que você abre um editor de texto e escreve um grande script para fazer algo complexo — estou também falando de poder criar coisas relativamente simples diretamente na linha de comando. Há muitas situações em que você gostaria de poder usar um pouco de lógica, mas nada tão grande ou reutilizável que você queira sequer salvar. Deveria ser fácil criar "one-liners" como "parar em CreateFile se o arquivo que está sendo aberto estiver na área de trabalho do usuário e a função Blah estiver na pilha."

Por que PowerShell?

Deixe-me ser claro: levou aproximadamente 4 anos para eu "aquecer" o PowerShell. Acho que ele tem arestas, aspectos que são simplesmente difíceis e muitos bugs, tanto no design quanto na implementação. Às vezes ele realmente me irrita. No entanto, os benefícios do PowerShell são convincentes e me convenceram de que é a melhor coisa a usar para este projeto: