DbgShell

Un front-end de PowerShell para el motor de depuración de Windows.

¿Listo para tabular tu camino hacia la gloria? Para una introducción más rápida, echa un vistazo a Introducción.

Descargos de responsabilidad

1. Este proyecto no es producido, respaldado ni supervisado por el equipo de depuradores de Windows. Si bien el equipo de depuradores agradece los comentarios sobre su API y front-ends (windbg, kd, etc.), no tienen ninguna conexión con este proyecto. No reporte errores ni envíe comentarios al equipo de depuradores sobre este proyecto.

2. Este no es un proyecto financiado: no tiene recursos oficiales asignados y solo lo trabajan voluntarios. No adquiera ninguna dependencia de producción de este proyecto a menos que esté dispuesto a soportarlo completamente por su cuenta. Siéntase libre de crear Issues y enviar Pull Requests, pero comprenda que con los limitados recursos de voluntarios, puede pasar un tiempo antes de que sus envíos sean procesados.

3. Este es un proyecto experimental: no está completamente maduro, y debe esperar que se realicen cambios disruptivos a menudo.

Corolario de los descargos anteriores: Evitaría adjuntar DbgShell a objetivos en vivo de alto valor.

Binarios

https://aka.ms/dbgshell-latest

Motivación

¿Alguna vez has intentado automatizar algo en el depurador? (cdb/ntsd/kd/windbg) ¿Cómo te fue?

El principal impulso para DbgShell es que es demasiado difícil automatizar cualquier cosa en el depurador. Por supuesto, existen facilidades hoy en día para ayudar a automatizar el depurador. Pero en mi opinión no están satisfaciendo las necesidades de la gente.

• Usar el lenguaje de scripting incorporado es arcano, limitado, difícil de hacer bien y difícil de obtener ayuda.
• Escribir un DLL de extensión de depurador completo es muy potente, pero requiere una inversión significativa, demasiado costosa para resolver problemas rápidos y 'puntuales' mientras se depuran problemas aleatorios del mundo real.
• Los intentos existentes de proporcionar una mejor interfaz (como PowerDbg) se basan en 'scraping' y análisis de texto, lo que es enormemente limitante (por no mencionar ideológicamente molesto) y por lo tanto no pueden cumplir la promesa de una interfaz realmente mejor (son solo marginalmente mejores, en el mejor de los casos).
• Los intentos existentes de proporcionar una forma más fácil de escribir una extensión de depurador son solo una solución temporal que aborda el dolor de desarrollar una extensión de depurador; realmente no resuelven el problema mayor. (por ejemplo, dos grandes deficiencias son: siguen siendo demasiado de bajo nivel (tienes que lidiar con la API COM de dbgeng), y no hay REPL)
• El equipo de depuradores ha introducido recientemente scripting en Javascript. Javascript es un lenguaje mucho mejor (y más definido) que el antiguo lenguaje de scripting de windbg, pero creo que PowerShell tiene algunas ventajas, la mayor de las cuales es que nadie realmente usa un shell de Javascript: PowerShell es mucho mejor como shell combinado y lenguaje de scripting.

El objetivo del proyecto DbgShell es traer la bondad del mundo de PowerShell basado en objetos al mundo de la depuración. Cuando haces 'dt' para volcar un 'objeto', deberías obtener un objeto real. El scripting debería ser tan fácil como escribir un script de PowerShell.

El proyecto DbgShell proporciona un front-end de PowerShell para dbgeng.dll, incluyendo:

• un "modelo de objetos" administrado (utilizable desde C# si se desea), que es de más alto nivel que la API COM de dbgeng,
• un "proveedor de navegación" de PowerShell, que expone aspectos de un objetivo de depuración como un espacio de nombres jerárquico (para que puedas hacer 'cd' a un hilo particular, escribir 'dir' para ver la pila, 'cd' a un marco, hacer otro 'dir' para ver locales/registros/etc.),
• cmdlets para manipular el objetivo,
• un host de PowerShell personalizado que permite un mejor control de la experiencia CLI del depurador, así como proporcionar características no disponibles en el host estándar de powershell.exe (a saber, soporte para colorización de texto usando códigos de escape ANSI (al estilo de ISO/IEC 6429))

El host personalizado sigue siendo un programa de línea de comandos (basado en conhost.exe) (análogo a ntsd/cdb/kd), pero se puede invocar desde windbg (!DbgShell).

Además de hacer la automatización mucho más fácil y potente, también abordará otras preocupaciones, como la facilidad de uso para personas que no tienen que usar los depuradores tan a menudo. (una queja que he escuchado es que 'cuando termino necesitando usar windbg, paso todo mi tiempo en el .CHM')

Para los usuarios experimentados de windbg, por otro lado, otro objetivo es hacer la transición lo más fluida posible. Así, por ejemplo, el proveedor de espacio de nombres no es la única forma de acceder a los datos; todavía puedes usar comandos tradicionales como '~3 s', 'k', etc.

¿Qué quieres decir con 'automatización' y 'scripting'?

No me refiero solo a ese tipo de cosas donde abres un editor de texto y escribes un gran script para hacer algo complejo; también me refiero a poder crear cosas relativamente simples directamente en la línea de comandos. Hay muchas situaciones en las que te gustaría poder usar un poco de lógica, pero nada tan grande o reutilizable que incluso quisieras guardarlo. Debería ser fácil crear 'one-liners' como 'detener en CreateFile si el archivo que se abre está en el escritorio del usuario y la función Blah está en la pila'.

¿Por qué PowerShell?

Déjame ser claro: me tomó aproximadamente 4 años 'calentarme' con PowerShell. Siento que tiene bordes afilados, aspectos que son simplemente difíciles, y muchos errores, tanto en diseño como en implementación. A veces realmente me irrita. Sin embargo, los beneficios de PowerShell son convincentes, y me han convencido de que es lo mejor para usar en este proyecto: