Übersicht über das Debugging in der CLR
Die Debug-API der Common Language Runtime (CLR) ermöglicht Anbietern von Tools das Schreiben von Debuggern zum Debuggen von Anwendungen, die in einer CLR-Umgebung ausgeführt werden. Der Code, der gedebuggt werden sollte, kann eine beliebige Art von Code sein, die von der CLR unterstützt wird.
Die Debug-API der CLR wird hauptsächlich mit nicht verwaltetem Code implementiert. Deshalb liegt die Debug-API als Satz von COM-Schnittstellen vor. Die API besteht aus folgenden Elementen:
Eine Auflistung von COM-Objekten und Schnittstellen, die von der CLR implementiert werden.
Eine Auflistung von COM-Rückrufschnittstellen, die vom Debugger implementiert werden müssen.
Diese Übersicht enthält folgende Abschnitte:
CLR-Debugszenarios
API-Kategorien
Anfügen an ein Programm oder Starten eines Programms
Steuern der Programmausführung
Untersuchen des Programmzustands
Ändern des Programmzustands
Verwenden von "Bearbeiten und Fortfahren"
Auswerten von Funktionen
Dynamisches Einfügen von Code
Unterstützte Umgebungen
Verwandte Themen
CLR-Debugszenarios
In den folgenden Abschnitten wird beschrieben, wie die Debug-API der Common Language Runtime (CLR) typische Debugszenarios behandelt. Beachten Sie, dass die Laufzeit einige Szenarios direkt unterstützt und mit aktuellen Methoden interagiert, um weitere zu unterstützen.
Prozessexternes Debuggen
Beim prozessexternen Debuggen befindet sich der Debugger nicht in dem Prozess, der gedebuggt wird, sondern in einem separaten Prozess (d. h. außerhalb der zu debuggenden Komponente). In diesem Szenario werden die Interaktionen zwischen dem Debugger und der zu debuggenden Komponente reduziert. Dadurch ermöglicht es ein genaueres Bild des Prozesses.
Die Debug-API der CLR bietet direkte Unterstützung für prozessexternes Debuggen. Zum Debuggen von verwaltetem Code behandelt die API die gesamte Kommunikation zwischen dem Debugger und den verwalteten Teilen der zu debuggenden Komponente.
Die Debug-API der CLR wird zwar prozessextern verwendet, ein Teil der Debuglogik (z. B. die Threadsynchronisierung) erfolgt jedoch prozessintern, also innerhalb der zu debuggenden Komponente. In den meisten Fällen ist dies ein Implementierungsdetail, das für den Debugger transparent sein sollte. Weitere Informationen zur Threadsynchronisierung finden Sie unter CLR-Debugarchitektur. Ein Nachteil der prozessexternen Verwendung der Debug-API besteht darin, dass sie sich nicht zur Überprüfung von Absturzabbildern eignet.
Prozessinternes Debuggen
In .NET Framework, Version 1.0 und 1.1, bot die Debug-API der CLR eingeschränkte Unterstützung für prozessinternes Debuggen, bei dem ein Profiler die Überprüfungsfunktionen der Debug-API verwenden konnte. In .NET Framework 2.0 wurde das prozessinterne Debuggen durch eine Gruppe von Funktionen ersetzt, die mehr Konsistenz gegenüber der Profilerstellungs-API aufweisen. Weitere Informationen über diese Änderungen finden Sie im Abschnitt mit den Erläuterungen zu den Features für Stapelmomentaufnahme und Objektüberprüfung in der Übersicht über die Profilerstellung.
Remoteprozessdebuggen
Beim Remoteprozessdebuggen befindet sich die Benutzeroberfläche des Debuggers nicht in dem Prozess, der gedebuggt wird, sondern auf einem separaten Computer. Dieses Szenario kann nützlich sein, wenn der Debugger beim Ausführen auf dem gleichen Computer die zu debuggende Komponente beeinträchtigt. Die Beeinträchtigung kann folgende Ursachen haben:
Begrenzte Ressourcen.
Standortabhängigkeiten.
Fehler, die das Betriebssystem beeinträchtigen.
Die Debug-API der CLR bietet keine direkte Unterstützung für Remoteprozessdebuggen. Ein Debugger, der auf der Debug-API der CLR basiert, muss dennoch prozessextern sein, sich also außerhalb der zu debuggenden Komponente befinden. Daher erfordert diese Lösung einen Proxyprozess auf dem Computer, auf dem sich auch die zu debuggende Komponente befindet.
Debuggen von nicht verwaltetem Code
Verwalteter Code und nicht verwalteter Code sind oft nebeneinander im selben Prozess enthalten. Daher müssen häufig beide Codetypen gleichzeitig gedebuggt werden.
Die Debug-API der CLR unterstützt das Überschreiten von Begrenzungen zwischen verwaltetem und nicht verwaltetem Code bei der schrittweisen Ausführung. Ein direktes Debugging von nicht verwaltetem Code wird jedoch nicht unterstützt. Durch gemeinsame Verwendung der Win32-Debugfunktionen kann die Debug-API der CLR jedoch gleichzeitig mit einem Debugger für nicht verwalteten Code verwendet werden.
Die Debug-API der CLR bietet zudem zwei Optionen zum Debuggen eines Prozesses:
Eine Option für weiches Anfügen, mit der nur die verwalteten Teile des Prozesses gedebuggt werden. Ein Debugger, der einem Prozess weich angefügt wurde, kann anschließend vom Prozess getrennt werden.
Eine Option für hartes Anfügen, mit der sowohl die verwalteten als auch die nicht verwalteten Teile eines Prozesses gedebuggt und alle Win32-Debugereignisse durch die Debug-API verfügbar gemacht werden.
Gemischte Sprachumgebungen
In Komponentensoftware können verschiedene Komponenten mit verschiedenen Sprachen erstellt werden. Ein Debugger muss in der Lage sein, Unterschiede in den Sprachen zu erkennen, sodass Daten im richtigen Format angezeigt werden, Ausdrücke mit der richtigen Syntax ausgewertet werden können usw.
Die Debug-API der CLR bietet keine direkte Unterstützung für gemischte Sprachumgebungen, da die CLR keine Quellsprache kennt. Ein Debugger sollte mit den vorhandenen Zuordnungsfunktionen in der Lage sein, eine bestimmte Funktion der Sprache zuzuordnen, in der die Funktion implementiert wurde.
Mehrere Prozesse und verteilte Programme
Ein Komponentenprogramm kann kooperierende Komponenten beinhalten, die in verschiedenen Prozessen oder sogar auf verschiedenen Computern in einem Netzwerk ausgeführt werden. Ein Debugger sollte in der Lage sein, die Ausführungslogik zwischen Prozessen und Computern zu verfolgen, um eine logische Ansicht des gegenwärtigen Zustands bereitzustellen.
Die Debug-API der CLR bietet keine direkte Unterstützung zum Debuggen mehrerer Prozesse. Ein Debugger, der die API verwendet, sollte jedoch direkte Unterstützung hierfür bieten, und vorhandene Methoden sollten weiter ausgeführt werden.
Zurück nach oben
API-Kategorien
Die Debug-API umfasst die folgenden drei Schnittstellengruppen, die in der Regel alle von einem CLR-Debugger verwendet und als nicht verwalteter Code implementiert werden.
Schnittstellen, die das Debuggen von CLR-Anwendungen unterstützen.
Schnittstellen, die Zugriff auf symbolische Debuginformationen bereitstellen, die normalerweise in Programmdatenbankdateien (PDB) gespeichert werden.
Schnittstellen, die das Abfragen der Prozess- und Anwendungsdomänen auf einem Computer unterstützen.
Die Debug-API hängt von zwei weiteren Schnittstellensätzen ab:
Metadaten-API zum Verarbeiten der Überprüfung von statischen Programminformationen, z. B. Klassen und Methodentypinformationen.
Symbolspeicher-API für die Unterstützung des Debuggens auf Quellcodeebene für Debugger von verwaltetem Code.
Die Debugschnittstellen können auch in Funktionskategorien unterteilt werden, die in der folgenden Tabelle aufgeführt sind.
API-Kategorie |
Beschreibung |
|---|---|
Registrierung |
Schnittstellen, die der Debugger zum Registrieren bei der CLR und zum Anfordern von Benachrichtigungen beim Auftreten bestimmter Ereignisse aufruft. |
Benachrichtigung |
Rückrufschnittstellen, die von der CLR zum Benachrichtigen des Debuggers über verschiedene Ereignisse und zum Zurückgeben der angeforderten Informationen verwendet werden. Diese Schnittstellen müssen vom Debugger implementiert werden. |
Haltepunkt |
Schnittstellen, die der Debugger aufruft, um Informationen über Haltepunkte abzurufen. |
Ausführung |
Schnittstellen, die der Debugger zum Steuern der Ausführung der zu debuggenden Komponente und zum Zugreifen auf Aufruflisten aufruft. |
Information |
Schnittstellen, die der Debugger aufruft, um Informationen über die zu debuggende Komponente abzurufen. |
Enumeration |
Schnittstellen, die der Debugger aufruft, um Objekte aufzulisten. |
Änderung |
Schnittstellen, die der Debugger aufruft, um den Code zu ändern, der gedebuggt wird. |
In den folgenden Abschnitten wird die von den Debugdiensten der Common Language Runtime bereitgestellte Funktionalität beschrieben.
Zurück nach oben
Anfügen an ein Programm oder Starten eines Programms
Die CLR ermöglicht Ihnen, den Debugger an ein laufendes Programm anzufügen oder einen Prozess zu starten. Die CLR-Debugdienste unterstützen ein Just-In-Time (JIT)-Debuggen, indem sie Ihnen das Anfügen des Debuggers an ein Programm ermöglichen, das eine nicht behandelte Ausnahme auslöst. Für ein Programm, das nicht im debugfähigen Modus ausgeführt wird, sind jedoch möglicherweise weniger Debuginformationen verfügbar. Ein Programm kann sich immer selbst im debugfähigen Modus ausführen, um dieses Problem zu vermeiden. Weitere Informationen über den debugfähigen Modus finden Sie in folgenden Themen:
Zurück nach oben
Steuern der Programmausführung
Die CLR-Debugdienste bieten mehrere Möglichkeiten, die Ausführung eines Programms zu steuern. Dazu gehören Haltepunkte, Einzelschrittausführung, Ausnahmebenachrichtigung, Funktionsauswertung und andere Ereignisse in Verbindung mit dem Starten und Beenden eines Programms.
Die CLR-Debug-API stellt nur für verwalteten Code eine Ablaufsteuerung bereit. Wenn Sie die Ablaufsteuerung für nicht verwalteten Code ausführen möchten, müssen Sie diese Funktion gesondert im Debugger implementieren.
Haltepunkte
Sie können Haltepunkte erstellen, indem Sie den Code und die Microsoft Intermediate Language (MSIL) oder den systemeigenen Offset der Stelle angeben, an der die Unterbrechung stattfinden soll. Der Debugger wird dann benachrichtigt, wenn der Haltepunkt erreicht wird. Die Debug-API der CLR bietet keine direkte Unterstützung für bedingte Haltepunkte. Ein Debugger kann diese jedoch implementieren, indem er als Reaktion auf einen Haltepunkt einen Ausdruck auswertet und so entscheidet, ob der Benutzer über den Haltepunkt informiert wird oder nicht.
Schrittweises Ausführen
Die CLR-Debugdienste stellen eine Vielzahl von Möglichkeiten zur schrittweisen Ausführung bereit. Ein Programm kann einen Code Anweisung für Anweisung (Einzelschrittausführung) oder Anweisungsbereich für Anweisungsbereich (Bereichsschrittausführung) durchlaufen. Das Programm kann eine Funktion überspringen, schrittweise ausführen oder die schrittweise Ausführung der Funktion beenden. Die CLR-Debugdienste können auch den Debugger benachrichtigen, wenn eine Ausnahme eintritt, die den Prozess der schrittweisen Ausführung unterbricht.
Auch wenn die Debugdienste die schrittweise Ausführung von nicht verwaltetem Code nicht direkt unterstützen, liefern sie Rückrufe, wenn ein Schrittvorgang auf nicht verwalteten Code trifft, um die Steuerung an den Debugger zu übergeben. Sie stellen auch Funktionen bereit, mit denen der Debugger ermitteln kann, wann von nicht verwaltetem Code aus in verwalteten Code übergegangen wird.
Die CLR stellt nicht direkt ein schrittweises Ausführen auf Quellcodeebene bereit. Ein Debugger kann diese Funktionalität bereitstellen, indem er die Bereichsschrittausführung zusammen mit seinen eigenen Quellzuordnungsinformationen verwendet. Sie können die Symbolspeicherschnittstellen verwenden, um Informationen auf Quellcodeebene zu erhalten. Weitere Informationen zu diesen Schnittstellen finden Sie unter Diagnosesymbolspeicher (Referenz zur nicht verwalteten API).
Ausnahmen
Die CLR-Debugdienste ermöglichen einem Debugger, über Ausnahmen der ersten Chance und der zweiten Chance in verwaltetem Code informiert zu werden. Das ausgelöste Objekt ist für die Überprüfung an jedem Punkt verfügbar.
Die CLR behandelt keine systemeigenen Ausnahmen von nicht verwaltetem Code, außer wenn sie aufwärts zu verwaltetem Code weitergeleitet werden. Sie können jedoch weiterhin die Win32-Debugdienste verwenden, die gemeinsam mit den CRL-Debugdiensten verwendet werden, um nicht verwaltete Ausnahmen zu behandeln.
Programmereignisse
Die CLR-Debugdienste benachrichtigen einen Debugger, wenn viele Programmereignisse auftreten. Zu diesen Ereignissen gehören Prozesserstellung und Prozessende, Threaderstellung und Threadende, Anwendungsdomänenerstellung und -beendung, Laden und Entladen von Assemblys, Laden und Entladen von Modulen sowie Laden und Entladen von Klassen. Um eine gute Leistung zu garantieren, können Sie das Laden von Klassen und das Entladen von Ereignissen für ein Modul deaktivieren. Standardmäßig sind die Ereignisse für das Laden und Entladen von Klassen deaktiviert.
Threadsteuerung
Die CLR-Debugdienste stellen Schnittstellen für das Unterbrechen und Fortsetzen von einzelnen (verwalteten) Threads bereit.
Zurück nach oben
Untersuchen des Programmzustands
Die CLR-Debugdienste stellen eine detaillierte Möglichkeit zum Untersuchen der Teile eines Prozesses bereit, die in verwaltetem Code ausgeführt werden, wenn der Prozess im angehaltenen Zustand ist. Ein Prozess kann überprüft werden, um eine Liste physischer Threads zu erhalten.
Ein Thread kann untersucht werden, um seine Aufrufliste zu überprüfen. Die Aufrufliste eines Threads kann auf zwei Ebenen aufgelöst werden: auf Kettenebene und auf Stapelrahmenebene. Die Aufrufliste wird zunächst in Ketten untergliedert. Eine Kette ist ein zusammenhängendes logisches Aufruflistensegment. Sie enthält entweder verwaltete oder nicht verwaltete Stapelrahmen, aber nicht beide. Außerdem nutzen alle verwalteten Aufrufframes in einer einzelnen Kettenfreigabe denselben CLR-Kontext. Eine Kette kann entweder verwaltet oder nicht verwaltet sein.
Jede verwaltete Kette kann darüber hinaus in einzelne Stapelrahmen untergliedert sein. Jeder Stapelrahmen stellt einen Methodenaufruf dar. Sie können einen Stapelrahmen abfragen, um den Code zu erhalten, den er ausführt, oder um seine Argumente, lokalen Variablen und systemeigenen Register zu erhalten.
Eine nicht verwaltete Kette enthält keine Stapelrahmen. Stattdessen stellt sie den Bereich von Stapeladressen bereit, der nicht verwaltetem Code zugeteilt ist. Ein Debugger für nicht verwalteten Code muss eingesetzt werden, um den nicht verwalteten Teil des Stapels zu decodieren und eine Stapelüberwachung zu ermöglichen.
.gif "Hinweis") Hinweis |
|---|
Die CLR-Debugdienste bieten keine Unterstützung für das Konzept lokaler Variablen, die im Quellcode verwendet werden.Der Debugger ist zuständig dafür, lokale Variablen ihren Reservierungen zuzuordnen. |
Die CLR-Debugdienste stellen auch einen Zugriff auf globale, klassenstatische und lokale Threadvariablen bereit.
Zurück nach oben
Ändern des Programmzustands
Die CLR-Debugdienste ermöglichen einem Debugger, die physische Position des Anweisungszeigers während der Ausführung zu ändern, auch wenn ein solches Vorgehen nicht ohne Risiko ist. Der Anweisungszeiger kann erfolgreich geändert werden, wenn die folgenden Bedingungen den Wert true haben:
Der aktuelle Anweisungszeiger und der Zielanweisungszeiger sind beide an Sequenzpunkten. Sequenzpunkte stellen näherungsweise Anweisungsbegrenzungen dar.
Der Zielanweisungszeiger befindet sich nicht in einem Ausnahmefilter, einem catch-Block oder einem finally-Block.
Der aktuelle Anweisungszeiger befindet sich in einem catch-Block, und der Zielanweisungszeiger befindet sich nicht außerhalb des catch-Blocks.
Der Zielanweisungszeiger ist im gleichen Frame wie der aktuelle Anweisungszeiger.
Wenn sich die physische Position des Anweisungszeigers ändert, werden die Variablen an der aktuellen Anweisungszeigerposition den Variablen der Zielposition des Anweisungszeigers zugeordnet. Garbage Collection-Verweise auf die Position des Zielanweisungszeigers werden ordnungsgemäß initialisiert.
Nachdem der Anweisungszeiger geändert wurde, markieren die CLR-Debugdienste alle zwischengespeicherten Stapelinformationen als ungültig und aktualisieren die Informationen, sobald diese das nächste Mal benötigt werden. Debugger, die Zeiger auf Stapelinformationen, z. B. Frames und Ketten, zwischenspeichern, sollten diese Informationen nach dem Ändern des Anweisungszeigers aktualisieren.
Der Debugger kann auch die Daten eines Programms ändern, wenn das Programm beendet wird. Der Debugger kann die lokalen Variablen und Argumente einer Funktion ändern, wenn die Funktion ausgeführt wird, ähnlich wie bei einer Überprüfung. Der Debugger kann auch Felder von Arrays und Objekten aktualisieren, ebenso wie statische Felder und globale Variablen.
Zurück nach oben
Verwenden von "Bearbeiten und Fortfahren"
Während einer Debugsitzung können Sie mit der Funktion "Bearbeiten und Fortfahren" folgende Aufgaben durchführen:
Bearbeiten des Quellcodes.
Erneutes Kompilieren der geänderten Quelle.
Beibehalten des Rests des Laufzeitzustands der ausführbaren Datei, die gedebuggt wird.
Fortsetzen der Debugsitzung, ohne dass die Ausführung der Datei neu gestartet werden muss.
Zurück nach oben
Auswerten von Funktionen
Um Benutzerausdrücke und dynamische Eigenschaften von Objekten auszuwerten, benötigt ein Debugger eine Möglichkeit, den Code des Prozesses auszuführen, der gedebuggt wird. Die CLR-Debugdienste ermöglichen dem Debugger, einen Funktions- oder Methodenaufruf zu machen und diesen im Prozess auszuführen, der gedebuggt werden soll.
Die CLR sorgt dafür, dass der Debugger einen solchen Vorgang beendet, wenn er gefährlich sein kann (z. B. wenn dadurch ein Deadlock mit vorhandenem Code ausgelöst werden kann). Nach erfolgreichem Beenden der Auswertung wird der Thread so behandelt, als hätte keinerlei Auswertung stattgefunden, mit Ausnahme möglicher Nebeneffekte auf lokale Variablen durch die teilweise Auswertung. Wenn die Funktion nicht verwalteten Code aufruft oder in irgendeiner Weise blockiert, kann das Beenden der Auswertung unmöglich werden.
Nachdem die Funktionsauswertung abgeschlossen ist, verwendet die CLR einen Rückruf, um den Debugger darüber zu benachrichtigen, ob die Auswertung korrekt abgeschlossen wurde oder ob die Funktion eine Ausnahme ausgelöst hat. Sie können die ICorDebugValue-Methode und die ICorDebugValue2-Methode verwenden, um die Ergebnisse einer Auswertung zu überprüfen.
Der Thread, für den die Funktionsauswertung ausgeführt werden soll, muss im verwalteten Code beendet werden, und zwar an einem Punkt, der für die Garbage Collection sicher ist. (Die Funktionsauswertung ist auch für nicht behandelte Ausnahmen zulässig.) In nicht optimiertem Code sind diese sicheren Punkte sehr häufig vorhanden. Die meisten schrittweisen Vorgänge auf Haltepunkt- oder MSIL-Ebene werden bei einem dieser Punkte abgeschlossen. Diese Punkte können jedoch in optimiertem Code selten sein. Manchmal verfügt eine ganze Funktion möglicherweise über keine sicheren Punkte. Die Häufigkeit von Punkten, die für die Garbage Collection sicher sind, ändert sich von Funktion zu Funktion. Sogar in nicht optimiertem Code kann es vorkommen, dass kein sicherer Punkt für das Beenden gefunden wird. In optimiertem oder nicht optimiertem Code kommt die ICorDebugController::Stop-Methode selten bei einem sicheren Punkt an.
Die CLR-Debugdienste richten eine neue Kette an dem Thread ein, um eine Funktionsauswertung zu starten und die angeforderte Funktion aufzurufen. Sobald die Auswertung gestartet wird, sind alle Aspekte der Debug-API verfügbar: Ablaufsteuerung, Funktionsauswertung und so weiter. Geschachtelte Auswertungen werden unterstützt, und Haltepunkte werden wie üblich behandelt.
Zurück nach oben
Dynamisches Einfügen von Code
Einige Debugger ermöglichen einem Benutzer, beliebige Anweisungen in das Direktfenster einzugeben, und führen die Anweisungen aus. Die CLR-Debugdienste unterstützen dieses Szenario. Innerhalb bestimmter Grenzen gibt es keine Beschränkungen dafür, welchen Code Sie dynamisch einfügen können. (Zum Beispiel sind nicht lokale goto-Anweisungen nicht zulässig.)
Dynamische Codeeinfügung wird implementiert, indem eine Kombination aus Bearbeiten und Fortfahren-Operationen und der Funktionsauswertung verwendet wird. Der einzufügende Code wird mit einer Funktion umschlossen und wird durch Verwenden von Bearbeiten und Fortfahren eingefügt. Die eingefügte Funktion wird dann ausgewertet. Wenn Sie möchten, können Sie ByRef-Argumente an die Wrapperfunktion übergeben, damit die Nebeneffekte unmittelbar und dauerhaft sind.
Zurück nach oben
Unterstützte Umgebungen
CLR-Debugfunktionen sind für alle Prozessoren und Betriebssysteme verfügbar, die die CLR unterstützt, mit den folgenden Ausnahmen:
Die Debugmodi Bearbeiten und Fortfahren sowie gemischte Debugmodi werden von 64-Bit-Betriebssystemen nicht unterstützt. Für die SetIP-Methoden (ICorDebugILFrame::SetIP und ICorDebugNativeFrame::SetIP) gelten auf 64-Bit-Betriebssystemen weitere Einschränkungen. Die übrigen Funktionen sind für alle Prozessoren gleich. (Allerdings sind prozessorspezifische Darstellungen der Daten zu beachten, z. B. bei der Zeigergröße, dem Registerkontext usw.)
Die Debugmodi Bearbeiten und Fortfahren sowie gemischte Debugmodi werden von Win9x-basierten Betriebssystemen nicht unterstützt. Alle anderen Funktionen sollten unter allen Betriebssystemen äquivalent sein. Es gibt jedoch einige spezifische Ausnahmen, auf die in der Dokumentation der einzelnen Funktionen hingewiesen wird.
Zurück nach oben
Verwandte Themen
Titel |
Beschreibung |
|---|---|
Beschreibt, wie die verschiedenen Komponenten der Debug-API der CLR mit der CLR und dem Debugger interagieren. |
|
Beschreibt die Änderungen und Verbesserungen beim Debuggen in .NET Framework 2.0. |
|
Erläutert, dass manche CLR-Debugschnittstellen voraussetzen, dass sich der zu debuggende Prozess in einem bestimmten Zustand befindet. |
|
Stellt eine schrittweise Beschreibung bereit, wie ein Laufzeitprozess gedebuggt wird. |
|
Beschreibt, wie ein Debugger mit der Debug-API der CLR Haltepunkte festlegt, verwalteten und nicht verwalteten Code durchläuft und Ausnahmen behandelt. |
|
Beschreibt, wie ein Debugger die Debug-API der CLR verwendet, um auf verwaltete Stapelrahmen zuzugreifen und Ausdrücke auszuwerten. |
|
Beschreibt das dynamische Einfügen von Code, wobei die CLR einen aktiven Thread übernimmt, um Code auszuführen, der in der ursprünglichen Portable Executable-Datei (PE-Datei) nicht vorhanden war. |
|
Fasst die Veröffentlichungsschnittstellen des CLR-Prozesses zusammen, mit denen Prozesse und Anwendungsdomänen auf einem Computer aufgelistet und Informationen dazu bereitgestellt werden. |
|
Erläutert Sicherheitsaspekte bei der Verwendung der Debug-API der CLR. |
|
Beschreibt die nicht verwalteten Co-Klassen, die die Debug-API verwendet. |
|
Beschreibt die unverwalteten Schnittstellen, die das Debuggen eines Programms behandeln, das in der Common Language Runtime (CLR) ausgeführt wird. |
|
Beschreibt die nicht verwalteten globalen statischen Funktionen, die die Debug-API verwendet. |
|
Beschreibt die nicht verwalteten Enumerationen, die die Debug-API verwendet. |
|
Beschreibt die nicht verwalteten Strukturen, die die Debug-API verwendet. |
Zurück nach oben