DbgShell

Un front-end PowerShell per il motore di debug di Windows.

Pronto per tabulare verso la gloria? Per un'introduzione più rapida, dai un'occhiata a Primi passi.

Avvertenze

1. Questo progetto non è prodotto, approvato o monitorato dal team di debug di Windows. Mentre il team di debug accoglie con favore feedback sulla loro API e sui front-end (windbg, kd, et al.), non hanno alcuna connessione con questo progetto. Non segnalare bug o feedback al team di debug riguardanti questo progetto.

2. Questo non è un progetto finanziato: non ha risorse ufficiali allocate, e viene sviluppato solo da volontari. Non assumere alcuna dipendenza produttiva da questo progetto a meno che tu non sia disposto a supportarlo completamente da solo. Sentiti libero di segnalare problemi e inviare richieste di pull, ma tieni presente che con le risorse volontarie limitate, potrebbe passare del tempo prima che le tue segnalazioni vengano gestite.

3. Questo è un progetto sperimentale: non è completamente maturo, e ci si devono aspettare modifiche sostanziali spesso.

Corollario delle avvertenze sopra: eviterei di collegare DbgShell a target live di alto valore.

Binari

https://aka.ms/dbgshell-latest

Motivazione

Hai mai provato ad automatizzare qualcosa nel debugger? (cdb/ntsd/kd/windbg) Come è andata?

La principale motivazione per DbgShell è che è davvero troppo difficile automatizzare qualsiasi cosa nel debugger. Ci sono delle strutture oggi per assistere nell'automazione del debugger, ovviamente. Ma a mio parere non stanno soddisfacendo le esigenze delle persone.

• L'uso del linguaggio di scripting integrato è arcano, limitato, difficile da padroneggiare, e difficile da trovare aiuto.
• Scrivere una DLL di estensione del debugger completa è molto potente, ma è un investimento significativo—troppo costoso per risolvere rapidi problemi "una tantum" mentre si esegue il debug di problemi casuali del mondo reale. Nonostante il costo, esistono un gran numero di estensioni del debugger. Penso che non dovrebbero essercene così tante; credo che l'unica ragione per cui ce ne siano così tante è perché non ci sono alternative valide.
• I tentativi esistenti di fornire un'interfaccia migliore (come PowerDbg) si basano su "raschiatura" e parsing del testo, che è estremamente limitante (per non dire ideologicamente fastidioso) e quindi non sono in grado di soddisfare la promessa di un'interfaccia veramente migliore (sono al massimo marginalmente migliori).
• I tentativi esistenti di fornire un modo più semplice per scrivere un'estensione del debugger sono solo un tappabuchi che affronta il dolore di sviluppare un'estensione; non risolvono veramente il problema più grande. (ad esempio, due gravi carenze sono: sono ancora troppo di basso livello (devi gestire l'API COM di dbgeng), e non c'è REPL)
• Il team di debug ha recentemente introdotto lo scripting Javascript. Javascript è un linguaggio molto migliore (e più ben definito) del vecchio linguaggio di scripting di windbg, ma penso che PowerShell abbia alcuni vantaggi, il maggiore dei quali è che nessuno usa davvero una shell Javascript—PowerShell è molto meglio come shell combinata e linguaggio di scripting.

L'obiettivo del progetto DbgShell è portare la bontà del mondo PowerShell orientato agli oggetti nel mondo del debug. Quando fai 'dt' per scaricare un 'oggetto', dovresti ottenere un oggetto reale. Lo scripting dovrebbe essere facile come scrivere uno script PowerShell.

Il progetto DbgShell fornisce un front-end PowerShell per dbgeng.dll, includendo:

• un "modello a oggetti" gestito (usabile da C# se desiderato), che è di livello superiore rispetto all'API COM di dbgeng,
• un "provider di navigazione" PowerShell, che espone aspetti di un target di debug come namespace gerarchico (così puoi "cd" in un thread specifico, digitare "dir" per vedere lo stack, "cd" in un frame, fare un altro "dir" per vedere variabili locali/registri/ecc.),
• cmdlet per manipolare il target,
• un host PowerShell personalizzato che permette un miglior controllo dell'esperienza CLI del debugger, oltre a fornire funzionalità non disponibili nell'host standard powershell.exe (in particolare, supporto per la colorazione del testo usando codici di escape ANSI (come da ISO/IEC 6429))

L'host personalizzato è ancora un programma a riga di comando (basato su conhost.exe) (analogo a ntsd/cdb/kd), ma può essere invocato da windbg (!DbgShell).

Oltre a rendere l'automazione molto più semplice e potente, affronterà anche altre problematiche, come la facilità d'uso per le persone che non devono usare i debugger così spesso. (una lamentela che ho sentito è che "quando mi trovo a dover usare windbg, passo tutto il mio tempo nel .CHM")

Per gli utenti esperti di windbg, d'altra parte, un altro obiettivo è rendere la transizione il più fluida possibile. Quindi, ad esempio, il provider di namespace non è l'unico modo per accedere ai dati; puoi ancora usare comandi tradizionali come "~3 s", "k", ecc.

Cosa intendi per "automazione" e "scripting"?

Non sto solo parlando del tipo di cosa in cui apri un editor di testo e scrivi un grosso script per fare qualcosa di complesso—sto anche parlando della capacità di sfornare roba relativamente semplice direttamente sulla riga di comando. Ci sono molte situazioni in cui vorresti poter usare un po' di logica, ma nulla di così grande o riutilizzabile da volerlo persino salvare. Dovrebbe essere facile sfornare semplici "one-liner" come "interrompi su CreateFile se il file in apertura è sul desktop dell'utente e la funzione Blah è sullo stack."

Perché PowerShell?

Chiariamoci: mi ci sono voluti circa 4 anni per "scaldarmi" con PowerShell. Penso che abbia spigoli vivi, aspetti che sono semplicemente difficili, e molti bug, sia nella progettazione che nell'implementazione. A volte mi irrita molto. Tuttavia, i benefici di PowerShell sono convincenti, e mi hanno convinto che è la cosa migliore da usare per questo progetto: