DbgShell

Ein PowerShell-Frontend für die Windows-Debugger-Engine.

Bereit, sich per Tab durch die Glorie zu navigieren? Für eine schnellere Einführung werfen Sie einen Blick auf Getting Started.

Haftungsausschlüsse

1. Dieses Projekt wird nicht vom Windows-Debugger-Team erstellt, unterstützt oder überwacht. Das Debugger-Team freut sich über Feedback zu seiner API und den Frontends (windbg, kd usw.), hat jedoch keine Verbindung zu diesem Projekt. Reichen Sie keine Fehler oder Rückmeldungen zu diesem Projekt beim Debugger-Team ein.

2. Dies ist kein finanziertes Projekt: Es stehen keine offiziellen Ressourcen zur Verfügung, und es wird nur von Freiwilligen bearbeitet. Gehen Sie keine Produktionsabhängigkeit von diesem Projekt ein, es sei denn, Sie sind bereit, es vollständig selbst zu unterstützen. Sie können gerne Issues melden und Pull Requests einreichen, aber bedenken Sie, dass es aufgrund der begrenzten Freiwilligenressourcen eine Weile dauern kann, bis Ihre Einreichungen bearbeitet werden.

3. Dies ist ein experimentelles Projekt: Es ist nicht ausgereift, und Sie sollten mit häufigen bahnbrechenden Änderungen rechnen.

Konsequenz aus den obigen Haftungsausschlüssen: Ich würde davon abraten, DbgShell an live Ziele von hohem Wert anzuhängen.

Binärdateien

https://aka.ms/dbgshell-latest

Motivation

Haben Sie jemals versucht, etwas im Debugger zu automatisieren? (cdb/ntsd/kd/windbg) Wie ist das gelaufen?

Der Hauptantrieb für DbgShell ist, dass es einfach viel zu schwer ist, irgendetwas im Debugger zu automatisieren. Es gibt heute natürlich Einrichtungen, die bei der Automatisierung des Debuggers helfen. Aber meiner Meinung nach erfüllen sie die Bedürfnisse der Menschen nicht.

• Die Verwendung der integrierten Skriptsprache ist obskur, eingeschränkt, schwer richtig umzusetzen und schwer Hilfe zu bekommen.
• Das Schreiben einer vollwertigen Debugger-Erweiterungs-DLL ist sehr leistungsfähig, aber eine erhebliche Investition – viel zu teuer für die Lösung schneller, einmaliger Probleme beim Debuggen von zufälligen, realen Problemen. Trotz der Kosten gibt es eine große Anzahl von Debugger-Erweiterungen. Ich denke, es sollte nicht annähernd so viele geben; ich denke, der einzige Grund, warum es so viele gibt, ist, dass es keine brauchbaren Alternativen gibt.
• Bestehende Versuche, eine bessere Schnittstelle bereitzustellen (wie PowerDbg), basieren auf 'Scraping' und Textparsing, was enorm einschränkend ist (ganz zu schweigen von ideologisch ärgerlich) und daher nicht in der Lage ist, das Versprechen einer wirklich besseren Schnittstelle zu erfüllen (sie sind bestenfalls marginal besser).
• Bestehende Versuche, einen einfacheren Weg zum Schreiben einer Debugger-Erweiterung zu bieten, sind lediglich ein Notbehelf, der den Schmerz der Entwicklung einer Debugger-Erweiterung angeht; sie lösen nicht wirklich das größere Problem. (zwei Hauptmängel sind zum Beispiel: Sie sind immer noch zu niedrigstufig (man muss sich mit der dbgeng COM-API auseinandersetzen), und es gibt kein REPL)
• Das Debugger-Team hat kürzlich Javascript-Scripting eingeführt. Javascript ist eine viel bessere (und besser definierte) Sprache als die alte Windbg-Skriptsprache, aber ich denke, dass PowerShell einige Vorteile hat, der größte davon ist, dass niemand wirklich eine Javascript-Shell verwendet – PowerShell ist viel besser als kombinierte Shell- und Skriptsprache.

Das Ziel des DbgShell-Projekts ist es, die Vorzüge der objektbasierten PowerShell-Welt in die Debugging-Welt zu bringen. Wenn Sie 'dt' verwenden, um ein 'Objekt' auszugeben, sollten Sie ein tatsächliches Objekt erhalten. Scripting sollte so einfach sein wie das Schreiben eines PowerShell-Skripts.

Das DbgShell-Projekt bietet ein PowerShell-Frontend für dbgeng.dll, einschließlich:

• ein verwaltetes 'Objektmodell' (auf Wunsch auch von C# aus nutzbar), das eine höhere Abstraktionsebene als die dbgeng COM-API bietet,
• einen PowerShell-'Navigation Provider', der Aspekte eines Debugging-Ziels als hierarchischen Namespace darstellt (so können Sie 'cd' zu einem bestimmten Thread machen, 'dir' eingeben, um den Stack zu sehen, 'cd' in einen Frame, und nochmal 'dir' um Locals/Register usw. zu sehen),
• Cmdlets zur Manipulation des Ziels,
• einen benutzerdefinierten PowerShell-Host, der eine bessere Kontrolle über die Debugger-CLI-Erfahrung ermöglicht und Funktionen bereitstellt, die im standardmäßigen powershell.exe-Host nicht verfügbar sind (nämlich Unterstützung für Textfarben mittels ANSI-Escape-Sequenzen (à la ISO/IEC 6429))

Der benutzerdefinierte Host ist immer noch ein kommandozeilenbasiertes Programm (basierend auf conhost.exe) (analog zu ntsd/cdb/kd), kann aber von windbg aus aufgerufen werden (!DbgShell).

Neben der erheblichen Vereinfachung und Leistungssteigerung der Automatisierung wird es auch andere Anliegen angehen, wie die Benutzerfreundlichkeit für Personen, die die Debugger nicht so oft verwenden müssen. (eine Beschwerde, die ich gehört habe, ist: 'Wenn ich windbg verwenden muss, verbringe ich meine ganze Zeit in der .CHM')

Für erfahrene windbg-Benutzer ist ein weiteres Ziel, den Übergang so nahtlos wie möglich zu gestalten. So ist zum Beispiel der Namespace-Provider nicht der einzige Weg, auf Daten zuzugreifen; Sie können weiterhin traditionelle Befehle wie '~3 s', 'k' usw. verwenden.

Was meinen Sie mit "Automation" und "Scripting"?

Ich spreche nicht nur von der Art, wo man einen Texteditor öffnet und ein großes Skript schreibt, um etwas Komplexes zu tun – ich spreche auch davon, relativ einfache Dinge direkt auf der Kommandozeile aus dem Ärmel zu schütteln. Es gibt viele Situationen, in denen man ein bisschen Logik verwenden möchte, aber nichts so Großes oder Wiederverwendbares, dass man es speichern möchte. Es sollte einfach sein, 'Einzeiler' wie 'Halte bei CreateFile an, wenn die geöffnete Datei auf dem Desktop des Benutzers liegt und die Funktion Blah auf dem Stack ist', aus dem Handgelenk zu schütteln.

Warum PowerShell?

Lassen Sie mich klarstellen: Es hat ungefähr 4 Jahre gedauert, bis ich mich mit PowerShell 'angefreundet' habe. Ich finde, es hat Kanten, Aspekte, die einfach schwer sind, und viele Fehler, sowohl im Design als auch in der Implementierung. Manchmal nervt es mich wirklich. Trotzdem, die Vorteile von PowerShell sind überzeugend und haben mich davon überzeugt, dass es das Beste für dieses Projekt ist: