Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Aktualisiert: November 2007
In diesem Thema wird beschrieben, wie die Debug-API der Common Language Runtime (CLR) typische Debugszenarios behandelt. Beachten Sie, dass die CLR 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üfungsfeatures 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 Stapelsnapshot 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 hilfreich sein, wenn der Debugger und die zu debuggende Komponente auf dem gleichen Computer ausgeführt werden und aufgrund von eingeschränkten Ressourcen, Speicherortabhängigkeiten oder Fehlern, die das Betriebssystem stören, in Konflikt geraten.
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
Da verwalteter Code im gleichen Prozess wie nicht verwalteter Code vorhanden sein kann, kommt es häufig vor, dass Benutzer beide Arten von Code gleichzeitig debuggen möchten.
Die Debug-API der CLR bietet keine direkte Unterstützung zum Debuggen von nicht verwaltetem Code. Durch gemeinsame Verwendung der Win32-Debugfunktionen kann die Debug-API jedoch gleichzeitig mit einem Debugger für nicht verwalteten Code verwendet werden. Darüber hinaus werden Funktionen bereitgestellt, um die Grenzen zwischen verwaltetem und nicht verwaltetem Code schrittweise zu durchlaufen.
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 erkennen, wenn der Code aus einer anderen Sprache stammt, damit Daten im richtigen Format angezeigt werden, Ausdrücke mit der richtigen Syntax ausgewertet werden 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.