DbgShell

Un frontal PowerShell pour le moteur de débogage Windows.

Prêt à tabuler votre chemin vers la gloire ? Pour une introduction rapide, jetez un œil à Pour commencer.

Avertissements

1. Ce projet n'est pas produit, approuvé ni surveillé par l'équipe de débogage Windows. Bien que l'équipe de débogage accueille les commentaires concernant leur API et leurs interfaces (windbg, kd, etc.), elle n'a aucun lien avec ce projet. Ne signalez pas de bogues ou de retours à l'équipe de débogage concernant ce projet.

2. Ce projet n'est pas financé : aucune ressource officielle ne lui est allouée, et il n'est travaillé que par des bénévoles. Ne prenez aucune dépendance de production sur ce projet à moins d'être prêt à le supporter entièrement vous-même. N'hésitez pas à signaler des problèmes et à soumettre des Pull Requests, mais sachez qu'avec des ressources bénévoles limitées, il faudra peut-être un certain temps avant que vos soumissions soient traitées.

3. Ce projet est expérimental : il n'est pas complètement abouti, et vous devez vous attendre à des changements cassants souvent.

Corollaire des avertissements ci-dessus : j'éviterais d'attacher DbgShell à des cibles en direct de grande valeur.

Binaires

https://aka.ms/dbgshell-latest

Motivation

Avez-vous déjà essayé d'automatiser quelque chose dans le débogueur ? (cdb/ntsd/kd/windbg) Comment cela s'est-il passé pour vous ?

La principale impulsion pour DbgShell est qu'il est tout simplement beaucoup trop difficile d'automatiser quoi que ce soit dans le débogueur. Il existe certes des outils aujourd'hui pour aider à automatiser le débogueur, bien sûr. Mais à mon avis, ils ne répondent pas aux besoins des gens.

• L'utilisation du langage de script intégré est archaïque, limité, difficile à maîtriser, et difficile d'obtenir de l'aide.
• Écrire une DLL d'extension de débogueur complète est très puissant, mais c'est un investissement important—beaucoup trop coûteux pour résoudre des problèmes rapides et « uniques » lors du débogage de problèmes réels aléatoires. Malgré le coût, il existe un grand nombre d'extensions de débogueur dans l'existence. Je pense qu'il ne devrait pas y en avoir autant ; je pense que la seule raison pour laquelle il y en a autant est qu'il n'existe pas d'alternatives viables.
• Les tentatives existantes pour fournir une meilleure interface (comme PowerDbg) sont basées sur le « scraping » et l'analyse de texte, ce qui est extrêmement limitant (sans parler d'être idéologiquement ennuyeux) et ne peut donc pas tenir la promesse d'une interface vraiment meilleure (elles ne sont tout au plus que marginalement meilleures).
• Les tentatives existantes pour fournir un moyen plus simple d'écrire une extension de débogueur ne sont qu'un palliatif pour atténuer la douleur de développer une extension de débogueur ; elles ne résolvent pas vraiment le problème plus large. (par exemple, deux lacunes majeures sont : elles sont encore trop bas niveau (vous devez traiter avec l'API COM dbgeng), et il n'y a pas de REPL)
• L'équipe de débogage a récemment introduit Javascript scripting. Javascript est un langage bien meilleur (et mieux défini) que l'ancien langage de script windbg, mais je pense que PowerShell a certains avantages, dont le plus grand est que personne n'utilise vraiment un shell Javascript—PowerShell est bien meilleur en tant que shell et langage de script combinés.

L'objectif du projet DbgShell est d'apporter la bonté du monde objet de PowerShell au monde du débogage. Lorsque vous faites 'dt' pour vider un 'objet', vous devriez obtenir un objet réel. Le script devrait être aussi simple que d'écrire un script PowerShell.

Le projet DbgShell fournit une interface PowerShell pour dbgeng.dll, comprenant :

• un « modèle objet » géré (utilisable depuis C# si vous le souhaitez), qui est de plus haut niveau que l'API COM dbgeng,
• un « fournisseur de navigation » PowerShell, qui expose les aspects d'une cible de débogage sous forme d'un espace de noms hiérarchique (afin que vous puissiez « cd » vers un thread particulier, taper « dir » pour voir la pile, « cd » dans un frame, faire un autre « dir » pour voir les variables locales/registres/etc.),
• des cmdlets pour manipuler la cible,
• un hôte PowerShell personnalisé qui permet un meilleur contrôle de l'expérience CLI du débogueur, ainsi que la fourniture de fonctionnalités non disponibles dans l'hôte powershell.exe standard (à savoir, la prise en charge de la colorisation du texte à l'aide de codes d'échappement ANSI (à la ISO/IEC 6429))

L'hôte personnalisé est toujours un programme en ligne de commande (basé sur conhost.exe) (analogue à ntsd/cdb/kd), mais il peut être invoqué depuis windbg (!DbgShell).

En plus de rendre l'automatisation beaucoup plus facile et plus puissante, il répondra également à d'autres préoccupations, telles que la facilité d'utilisation pour les personnes qui n'ont pas à utiliser les débogueurs si souvent. (une plainte que j'ai entendue est que « quand je finis par devoir utiliser windbg, je passe tout mon temps dans le .CHM »)

Pour les utilisateurs expérimentés de windbg, d'autre part, un autre objectif est de rendre la transition aussi transparente que possible. Ainsi, par exemple, le fournisseur d'espace de noms n'est pas le seul moyen d'accéder aux données ; vous pouvez toujours utiliser des commandes traditionnelles comme « ~3 s », « k », etc.

Que voulez-vous dire par « automatisation » et « script » ?

Je ne parle pas uniquement de ce genre de choses où vous ouvrez un éditeur de texte et écrivez un gros script pour faire quelque chose de complexe—je parle aussi de pouvoir sortir des choses relativement simples directement en ligne de commande. Il existe de nombreuses situations où vous aimeriez pouvoir utiliser un peu de logique, mais rien d'assez gros ou réutilisable pour que vous vouliez même le sauvegarder. Il devrait être facile de sortir des « one-liners » comme « break sur CreateFile si le fichier en cours d'ouverture est sur le bureau de l'utilisateur et que la fonction Blah est dans la pile. »

Pourquoi PowerShell ?

Soyons clairs : il m'a fallu environ 4 ans pour « apprivoiser » PowerShell. Je ressens qu'il a des angles vifs, des aspects qui sont simplement difficiles, et plein de bugs, tant dans la conception que dans l'implémentation. Parfois, cela m'irrite vraiment. Cependant, les avantages de PowerShell sont convaincants et m'ont convaincu que c'est la meilleure chose à utiliser pour ce projet :