Native Debugger-Objekte in JavaScript-Erweiterungen – Entwurfs- und Testüberlegungen

In diesem Thema werden Entwurfs- und Testüberlegungen für die Verwendung der systemeigenen Debuggerobjekte in JavaScript-Erweiterungen beschrieben.

Systemeigene Debuggerobjekte stellen verschiedene Konstrukte und Verhaltensweisen der Debuggerumgebung dar. Die Objekte können an JavaScript-Erweiterungen übergeben (oder erworben werden), um den Zustand des Debuggers zu bearbeiten.

Informationen zu JavaScript-Erweiterungen des Debuggerobjekts finden Sie unter Native Debugger Objects in JavaScript Extensions.

Allgemeine Informationen zum Arbeiten mit JavaScript finden Sie unter JavaScript Debugger Scripting.

Überlegungen zum Entwurf des Debuggerdatenmodells

Entwurfsprinzipien

Berücksichtigen Sie die folgenden Prinzipien, damit Ihre Debuggererweiterungen Informationen darstellen, die auffindbar, abfragbar und skriptfähig sind.

• Informationen sind nahe dem Ort, an dem sie benötigt werden. Beispielsweise sollten Informationen zu einem Registrierungsschlüssel als Teil einer lokalen Variablen angezeigt werden, die das Handle für einen Registrierungsschlüssel enthält.
• Informationen sind strukturiert. Beispielsweise werden Informationen zu einem Registrierungsschlüssel in separaten Feldern wie Schlüsseltyp, Schlüssel-ACL, Schlüsselname und Wert angezeigt. Dies bedeutet, dass auf die einzelnen Felder ohne Analyse von Text zugegriffen werden kann.
• Informationen sind konsistent. Informationen zu Registrierungsschlüsselhandles werden so ähnlich wie möglich mit Informationen zu Dateihandles dargestellt.

Vermeiden Sie diese Ansätze, die diese Prinzipien nicht unterstützen.

• Strukturieren Sie Ihre Gegenstände nicht in eine einzelne flache "Küchenspüle". Mit einer organisierten Hierarchie können Benutzer nach den gesuchten Informationen suchen, ohne vorher wissen zu müssen, wonach sie suchen und die Auffindbarkeit unterstützen.
• Konvertieren Sie keine klassische Dbgeng-Erweiterung, indem Sie sie einfach in das Modell verschieben und gleichzeitig Bildschirme mit Rohtext ausgeben. Dies kann nicht mit anderen Erweiterungen erstellt werden und kann nicht mit LINQ-Ausdrücken abgefragt werden. Trennen Sie die Daten stattdessen in separate, abfragbare Felder.

Benennungsrichtlinien

• Die Großschreibung von Feldern sollte PascalCase sein. Eine Ausnahme könnte für Namen gelten, die in einer anderen Schreibweise bekannt sind, z. B. jQuery.
• Vermeiden Sie die Verwendung von Sonderzeichen, die normalerweise nicht in einem C++-Bezeichner verwendet werden. Vermeiden Sie beispielsweise die Verwendung von Namen wie "Gesamtlänge" (die ein Leerzeichen enthält) oder "[Größe]" (die eckige Klammern enthält). Diese Konvention ermöglicht eine einfachere Verwendung von Skriptsprachen, bei denen diese Zeichen nicht als Teil von Bezeichnern zulässig sind, und ermöglicht auch den einfacheren Verbrauch aus dem Befehlsfenster.

Richtlinien für Organisation und Hierarchie

• Erweitern Sie nicht die oberste Ebene des Debuggernamespaces. Stattdessen sollten Sie einen vorhandenen Knoten im Debugger erweitern, damit die Informationen dort angezeigt werden, wo sie am relevantesten sind.
• Duplizieren Sie keine Konzepte. Wenn Sie eine Datenmodellerweiterung erstellen, die zusätzliche Informationen zu einem Konzept auflistet, das bereits im Debugger vorhanden ist, erweitern Sie die vorhandenen Informationen, anstatt sie durch neue Informationen zu ersetzen. Mit anderen Worten, eine Erweiterung, die Details zu einem Modul anzeigt, sollte das vorhandene Modulobjekt erweitern, anstatt eine neue Liste von Modulen zu erstellen.
• Freie unverankerte Hilfsprogrammbefehle müssen Teil des Debugger.Utility-Namespace sein. Sie sollten auch entsprechend unternamespaced sein (z. B. Debugger.Utility.Collections.FromListEntry)

Abwärtskompatibilität und Unterbrechung von Änderungen

Ein veröffentlichtes Skript sollte die Kompatibilität mit anderen Skripts, die davon abhängen, nicht unterbrechen. Wenn z. B. eine Funktion im Modell veröffentlicht wird, sollte sie sich an derselben Position und mit denselben Parametern befinden, wenn möglich.

Keine Verwendung externer Ressourcen

• Erweiterungen dürfen keine externen Prozesse enthalten. Externe Prozesse können das Verhalten des Debuggers beeinträchtigen und sich in verschiedenen Remotedebuggerszenarien falsch verhalten (z. B. dbgsrv-Remotes, ntsd-Remotes und "ntsd -d Remotes")
• Erweiterungen dürfen keine Benutzeroberfläche anzeigen. Das Anzeigen von Benutzeroberflächenelementen verhält sich in Remotedebuggingszenarien falsch und kann Konsolendebuggingszenarien unterbrechen.
• Erweiterungen dürfen das Debuggermodul oder die Debugger-UI nicht über nicht dokumentierte Methoden bearbeiten. Dies verursacht Kompatibilitätsprobleme und verhält sich auf Debuggerclients mit unterschiedlicher Benutzeroberfläche falsch.
• Erweiterungen müssen nur über die dokumentierten Debugger-APIs auf Zielinformationen zugreifen. Wenn Sie versuchen, über win32-APIs auf Informationen zu einem Ziel zuzugreifen, treten in vielen Remoteszenarien Fehler auf, und sogar in einigen lokalen Debugging-Szenarien können Probleme über Sicherheitsgrenzen hinweg auftreten.

Keine Verwendung von dbgeng spezifischen Features

Skripts, die als Erweiterungen verwendet werden sollen, dürfen nach Möglichkeit nicht auf dbgeng-spezifische Features (z. B. das Ausführen von klassischen Debuggererweiterungen) basieren. Skripts sollten über jedem Debugger verwendet werden können, der das Datenmodell hosten soll.

Testen von Debuggererweiterungen

Es wird erwartet, dass Erweiterungen in einer Vielzahl von Szenarien funktionieren. Während einige Erweiterungen für ein Szenario spezifisch sind (z. B. ein Kerneldebuggingszenario), sollten die meisten Erweiterungen in allen Szenarien funktionieren oder Metadaten enthalten, die die unterstützten Szenarien angeben.

Kernelmodus

• Live-Kerneldebugging
• Kernelabbilddebugging

Benutzermodus

• Debuggen des Live-Benutzermodus
• Fehlerbehebung bei Speicherabbildern im Benutzermodus

Berücksichtigen Sie außerdem diese Debuggerverwendungsszenarien.

• Multiprozessdebugging
• Multisitzungsdebugging (z. B. Dump + Live-Benutzer innerhalb einer einzigen Sitzung)

Remote-Debugger-Verwendung

Testen Sie den ordnungsgemäßen Betrieb mit den Remote-Debugger-Verwendungsszenarien.

• dbgsrv Fernbedienungen
• ntsd-Fernsteuerungen
• ntsd -d Remotes

Weitere Informationen finden Sie unter Debuggen mit CDB und NTSD undAktivieren eines Prozessservers.

Regressionstest

Untersuchen Sie die Verwendung der Testautomatisierung, die die Funktionalität Ihrer Erweiterungen überprüfen kann, wenn neue Versionen des Debuggers veröffentlicht werden.

Siehe auch

native Debuggerobjekte in JavaScript-Erweiterungen

Native Debugger-Objekte in JavaScript-Erweiterungen – Debugger-Objektdetails.

JavaScript-Debugging-Skripting

JavaScript-Debuggerbeispielskripts