Prozessinterne parallele Profilerstellung
Ab .NET Framework 4 können mehrere Versionen von .NET Framework im gleichen Prozess parallel ausgeführt werden. Profiler müssen die parallele Ausführung ermöglichen, um in dieser Umgebung ausgeführt werden zu können. Profiler, die mit .NET Framework, Version 2.0, .NET Framework 2.0 SP1, .NET Framework 3.0, .NET Framework 3.5 oder .NET Framework 3.5 SP1 kompatibel sind, können in .NET Framework, Version 4 verwendet werden, wenn vom Prozess, für den ein Profil erstellt werden soll, nicht mehrere Versionen von .NET Framework gehostet werden. Weitere Informationen zum Verwenden von prozessinterner paralleler Profilerstellung finden Sie unter Einstellungen für die Profilerkompatibilität.
Unterstützung für parallele Ausführung
Ein Profiler bietet Unterstützung für parallele Ausführung, wenn er sicherstellt, dass Anwendungen, die mehrere Laufzeiten laden, nicht bewirken, dass der Profiler auf unerwartete Konflikte stößt, z. B. Zugriffsverletzungen. Unterstützung für parallele Ausführung schließt die folgenden Ebenen der Unterstützung ein:
Profil zuerst. Für die erste Common Language Runtime (CLR)-Version, die in einen Prozess geladen wird, wird ein Profil erstellt, für nachfolgende CLR hingegen nicht. Der Profiler muss darauf vorbereitet sein, dass mehrere CreateInstance-Aufrufe des COM-Klassenfactoryobjekts stattfinden. Die gleichzeitige, aktive Verwendung von Rückrufen in mehreren Instanzen des COM-Objekts muss jedoch nicht unterstützt werden. Der Profiler akzeptiert einfach den ersten CreateInstance-Aufruf der Klassenfactory und den Initialize-Rückrufaufruf. Die restlichen Aufrufe schlagen dagegen fehl.
Profil eins. Ähnlich wie "Profil zuerst", mit der Ausnahme, dass der Profiler dem Benutzer die Wahl lässt, für welche CLR-Version ein Profil erstellt wird, anstatt nur für die erste CLR-Version, die geladen wird, ein Profil zu erstellen.
Profil zahlreich. Der Benutzer wählt mindestens eine (möglicherweise alle) CLR-Versionen aus, für die ein Profil erstellt werden soll. Der Profiler verwendet Rückrufe von diesen CLR-Versionen und ruft Info-Funktionen in die entsprechende Version zurück. Der Profiler muss hier verfolgen, welche Laufzeitelemente (Funktionen, Anwendungsdomänen, Klassen, Objekte usw.) zu welcher CLR gehören.
Hinweis |
---|
Ein Profiler, der für den .NET Framework 4 entwickelt wurde, muss Unterstützung für parallele Ausführung bieten.Das heißt, wenn ein Profiler die ICorProfilerCallback3-Schnittstelle implementiert, muss eines dieser Schemas ("Profil zuerst", "Profil eins" oder "Profil zahlreich") implementiert werden, um sicherzustellen, dass mehrere Laufzeiten nicht dazu führen, dass der Profiler auf unerwartete Konflikte stößt. |
Anforderungen für die Unterstützung von "Profil zahlreich"
Zur Unterstützung der Option "Profil zahlreich" muss ein Profiler folgende Möglichkeiten bieten:
Zuordnen von Aufrufen zu globalen Funktionen mit der richtigen Laufzeit.
Zuordnen der verschieden IDs (z. B. ObjectID, FunctionID, ClassID, ModuleID, AssemblyID, AppDomainID usw.) zur richtigen Laufzeit und Sicherstellen, dass eine ID von einer Laufzeit nie an die ICorProfilerCallback(2,3)-Schnittstelle einer anderen Laufzeit übergeben wird. Es ist jedoch akzeptabel, einen beliebigen Anweisungszeiger von einer beliebigen Laufzeit oder von beliebigem systemeigenen Code in die Implementierung der ICorProfilerInfo::GetFunctionFromIP-Methode einer beliebigen Laufzeit zu übergeben.
Behandeln von Interaktionen zwischen Laufzeiten, z. B. Aufruflisten, die von einer Laufzeit an eine andere übergeben werden.
Behandeln von mehreren Instanzen der Klasse, die das ICorProfilerCallback(2,3)-Objekt implementiert, das im gleichen Prozess aktiv ist.
Der Profiler sollte in der Regel ein einzelnes Profiler-Manager-Objekt bereitstellen, das für das Behandeln globaler Funktionsimplementierungen und von Daten, die mehrere Laufzeiten umfassen, verwendet wird. Beispiel:
Enter/Leave/Tailcall-/FunctionIDMapperFunctionIDMapper-Funktion- Rückrufe von allen Laufzeiten. Das Profiler-Manager-Objekt bestimmt in der Regel die entsprechende Laufzeit mithilfe des clientData-Parameters von FunctionIDMapper2 oder ICorProfilerInfo3::SetFunctionIDMapper2.
Stackwalks und Schattenstapel über Laufzeiten.
Koordinierte Protokollierung unter den Laufzeiten.
Der Profiler muss auch ein Profilerobjekt bereitstellen, das die ICorProfilerCallback-Schnittstellen implementiert. Die CLR instanziiert dieses Profilerobjekt jeweils einmal für jede aktive Laufzeit. Das einzige globale Objekt, auf das der Profiler zugreifen sollte, ist der Profiler-Manager. Der Profiler sollte keinen globalen Verweis auf die ICorProfilerCallback-Implementierung verwalten, da viele Instanzen der ICorProfilerCallback-Implementierung möglicherweise aktiv sind, wenn der Prozess mehrere Laufzeiten enthält.
Aktivieren von Profilern
Die primäre Aktivierungsaufgabe ist die Zuordnung von Profilern mit Laufzeitversionen.
Starten von Profilern
Wenn Sie in allen Laufzeiten in einem angegebenen Prozess einen Profiler starten möchten, legen Sie die COR_PROFILER-Umgebungsvariable und die COR_ENABLE_PROFILING-Umgebungsvariable fest. (Dies ist die gleiche Prozedur wie in .NET Framework 3.5 und früheren Versionen.)
Wenn Sie nur in bestimmten Laufzeiten einen Profiler starten möchten, legen Sie die COR_PROFILER-Umgebungsvariable und die COR_ENABLE_PROFILING-Umgebungsvariable fest, und führen Sie einen der folgenden Schritte aus:
Sorgen Sie dafür, dass alle Aufrufe mit Ausnahme des ersten CreateInstance-Aufrufs des Klassenfactoryobjekts fehlschlagen (Profil zuerst).
- oder -
Lassen Sie alle CreateInstance-Aufrufe zum Klassenfactoryobjekt zu, und bestimmen Sie im Initialize-Aufruf die Version der aufrufenden Laufzeit. Hierzu müssen Sie die folgenden beiden Aktionen ausführen:
Führen Sie die QueryInterface-Methode in der CLR für die ICorProfilerInfo3-Schnittstelle aus. Wenn dies fehlschlägt, ist die Laufzeitversion 1 oder 2.0. Die Ausführung von QueryInterface für die ICorProfilerInfo2-Schnittstelle zeigt, ob die Laufzeit eine Laufzeit der Version 2.0 oder der Version 1 ist.
Wenn ICorProfilerInfo3 unterstützt wird, rufen Sie die GetRuntimeInformation-Methode auf, um weitere Informationen zur Laufzeit abzurufen, für die ein Profil erstellt wird.
Wenn die Version der Laufzeit bestimmt wurde, kann der Profiler entscheiden, ob für die Laufzeit ein Profil erstellt werden soll. Fahren Sie in diesem Fall wie gewohnt mit der Initialisierung fort. Wenn nicht, geben Sie einen Fehler von Initialize zurück. Ab .NET Framework 4 gibt der Profiler möglicherweise ein CORPROF_E_PROFILER_CANCEL_ACTIVATION HRESULT zurück, damit ein Fehler nicht im Windows-Anwendungsereignisprotokoll erfasst wird.
Anfügen von Profilern
In einem Prozess zum Anfügen von Triggern geschieht Folgendes:
Verwendet die ICLRMetaHost::EnumerateLoadedRuntimes-Methode, um Laufzeiten aufzulisten, die in den Zielprozess geladen werden, und um die gewünschte Laufzeit zu suchen.
Ruft eine ICLRRuntimeInfo-Schnittstelle aus der IEnumUnknown-Schnittstelle ab, die von der ICLRMetaHost::EnumerateLoadedRuntimes-Methode zurückgegeben wird.
Ruft eine ICLRProfiling-Schnittstelle durch Aufrufen von GetInterface auf der ICLRRuntimeInfo-Schnittstelle mit CLSID_CLRProfiling und IID_ICLRProfiling ab.
Ruft die AttachProfiler-Methode durch die ICLRProfiling-Schnittstelle auf.
Weitere Informationen über das Anfügen von Profilern finden Sie unter Anfügen und Trennen des Profilers.
Siehe auch
Konzepte
Übersicht über die Profilerstellung