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 vorherigen Themen wurde beschrieben, was geschieht, wenn die Anwendung und der Profiler ausgeführt werden. Aber wie werden diese beiden verbunden, wenn eine Anwendung gestartet wird? Die Common Language Runtime (CLR) stellt die Verbindung während ihrer Initialisierung in jedem Prozess her. Sie entscheidet, ob eine Verbindung mit einem Profiler hergestellt wird. Wenn sie entscheidet, eine Verbindung herzustellen, sucht sie den Profiler, indem sie den Wert der zwei Umgebungsvariablen in der folgenden Reihenfolge überprüft:
COR_ENABLE_PROFILING: Die CLR stellt nur dann eine Verbindung zu einem Profiler her, wenn diese Umgebungsvariable vorhanden und auf 1 gesetzt ist.
COR_PROFILER: Wenn die Prüfung auf die Variable COR_ENABLE_PROFILING erfolgreich abgeschlossen wurde, stellt die CLR eine Verbindung mit dem Profiler mit dieser CLSID oder ProgID her, die zuvor in der Registrierung abgelegt worden sein muss. Die COR_PROFILER-Umgebungsvariable ist als Zeichenfolge definiert, wie in den beiden folgenden Beispielen gezeigt.
set COR_PROFILER={32E2F4DA-1BEA-47ea-88F9-C5DAF691C94A} set COR_PROFILER="MyProfiler"
Daher müssen Sie zur Profilerstellung für eine CLR-Anwendung die Umgebungsvariablen COR_ENABLE_PROFILING und COR_PROFILER setzen, bevor Sie die Anwendung ausführen. Außerdem müssen Sie sicherstellen, dass die Profiler-DLL registriert ist.
Umgebungsvariablenbereich
Die Werte, die Sie für die Umgebungsvariablen COR_ENABLE_PROFILING und COR_PROFILER festlegen, bestimmen den Einflussbereich dieser Variablen. Sie haben folgende Möglichkeiten, diese Variablen festzulegen:
Wenn Sie die Variablen in einem ICorDebug::CreateProcess-Aufruf festlegen, gelten sie nur für die Anwendung, die Sie zu diesem Zeitpunkt ausführen. (Sie gelten auch für andere Anwendungen, die von dieser Anwendung gestartet werden und die die Umgebung erben.)
Wenn Sie die Variablen in einer Eingabeaufforderung festlegen, gelten sie für alle Anwendungen, die von diesem Fenster aus gestartet werden.
Wenn Sie die Variablen auf Benutzerebene festlegen, gelten sie für alle Anwendungen, die Sie mit Windows-Explorer starten. Eine Eingabeaufforderung, die Sie nach dem Festlegen dieser Variablen öffnen, hat diese Umgebungseinstellungen, ebenso wie jede Anwendung, die Sie aus diesem Fenster starten. Um die Umgebungsvariablen auf Benutzerebene festzulegen, klicken Sie mit der rechten Maustaste auf Arbeitsplatz, klicken dann auf Eigenschaften, klicken dann auf die Registerkarte Erweitert, klicken dann auf die Schaltfläche Umgebungsvariablen und fügen die Variablen der Liste Benutzervariablen hinzu.
Wenn Sie die Variablen auf Computerebene festlegen, gelten sie für alle Anwendungen, die auf diesem Computer gestartet werden. Eine Eingabeaufforderung, die Sie auf diesem Computer öffnen, hat diese Umgebungseinstellungen, ebenso wie jede Anwendung, die Sie aus diesem Fenster starten. Dies bedeutet, dass jeder verwaltete Prozess auf diesem Computer mit Ihrem Profiler startet. Um die Umgebungsvariablen auf Computerebene festzulegen, klicken Sie mit der rechten Maustaste auf Arbeitsplatz, klicken dann auf Eigenschaften, klicken dann auf die Registerkarte Erweitert, klicken dann auf die Schaltfläche Umgebungsvariablen, fügen die Variablen der Liste Systemvariablen hinzu und starten anschließend den Computer neu. Nach dem Neustart sind die Variablen systemweit verfügbar.
Wenn Sie ein Profil für einen Windows-Dienst erstellen, müssen Sie nach dem Festlegen der Umgebungsvariablen und dem Registrieren der Profiler-DLL den Computer neu starten. Weitere Informationen zu diesen Überlegungen finden Sie unter Profilerstellung für einen Windows-Dienst.
Weitere Überlegungen
Die Profilerklasse implementiert die ICorProfilerCallback-Schnittstelle und die ICorProfilerCallback2-Schnittstelle. In .NET Framework, Version 2.0, muss ein Profiler ICorProfilerCallback2 implementieren. Wenn dies nicht geschieht, wird ICorProfilerCallback2 nicht geladen.
Nur ein einzelner Profiler kann ein Profil für einen Prozess zu einem gegebenen Zeitpunkt in einer gegebenen Umgebung erstellen. Sie können zwei verschiedene Profiler in verschiedenen Umgebungen registrieren, aber jeder Profiler muss ein Profil für separate Prozesse erstellen. Der Profiler muss als prozessinterne COM-Server-DLL implementiert werden, die demselben Adressenbereich wie der Prozess zugeordnet ist, für den das Profil erstellt wird. Dies bedeutet, dass der Profiler prozessintern ausgeführt wird. .NET Framework unterstützt keinen anderen Typ von COM-Server. Wenn beispielsweise ein Profiler Anwendungen von einem Remotecomputer aus überwachen möchte, muss er Collector-Agents auf jedem Computer implementieren. Diese Agents fassen die Ergebnisse in Stapeln zusammen und melden diese dem zentralen Datenerfassungscomputer.
Da der Profiler ein COM-Objekt ist, das prozessintern instanziiert wird, verfügt jede Anwendung mit Profil über eine eigene Kopie des Profilers. Daher muss eine einzelne Profilerinstanz nicht Daten von mehreren Anwendungen behandeln. Sie müssen jedoch eine Logik zum Protokollierungscode des Profilers hinzufügen, um zu verhindern, dass die Protokolldatei durch andere Anwendungen mit Profil überschrieben wird.
Initialisieren des Profilers
Wenn die Prüfung auf beide Umgebungsvariablen erfolgreich ist, erstellt die CLR eine Instanz des Profilers in ähnlicher Weise wie für die COM-CoCreateInstance-Funktion. Der Profiler wird nicht durch einen direkten Aufruf von CoCreateInstance geladen. Deshalb wird ein Aufruf von CoInitialize, der das Festlegen des Threadingmodells erfordert, vermieden. Die CLR ruft dann die ICorProfilerCallback::Initialize-Methode im Profiler auf. Die Signatur dieser Methode wird im Folgenden beschrieben.
HRESULT Initialize(IUnknown *pICorProfilerInfoUnk)
Der Profiler muss pICorProfilerInfoUnk nach einem ICorProfilerInfo-Schnittstellenzeiger oder einem ICorProfilerInfo2-Schnittstellenzeiger abfragen und diesen speichern, sodass er später während der Profilerstellung weitere Informationen abfragen kann.
Festlegen von Ereignisbenachrichtigungen
Der Profiler ruft dann die ICorProfilerInfo::SetEventMask-Methode auf, um anzugeben, an welchen Benachrichtigungskategorien er interessiert ist. Wenn der Profiler beispielsweise nur an Benachrichtigungen über das Starten und Verlassen von Funktionen sowie an Garbage Collection-Benachrichtigungen interessiert ist, wird Folgendes angegeben.
ICorProfilerInfo* pInfo;
pICorProfilerInfoUnk->QueryInterface(IID_ICorProfilerInfo, (void**)&pInfo);
pInfo->SetEventMask(COR_PRF_MONITOR_ENTERLEAVE | COR_PRF_MONITOR_GC)
Durch das Festlegen der Benachrichtigungsmaske in dieser Weise kann der Profiler die Benachrichtigungen einschränken, die er empfängt. Dieser Ansatz hilft dem Benutzer dabei, einen einfachen oder zweckgebundenen Profiler zu erstellen. Er reduziert auch die CPU-Zeit, die durch das Senden von Benachrichtigungen verschwendet würde, die vom Profiler einfach ignoriert werden.
Bestimmte Profilerereignisse sind unveränderlich. Das bedeutet, dass diese Ereignisse unmittelbar nach ihrem Festlegen im ICorProfilerCallback::Initialize-Rückruf nicht deaktiviert und neue Ereignisse nicht aktiviert werden können. Versuche, ein unveränderliches Ereignis zu ändern, führen dazu, dass ICorProfilerInfo::SetEventMask ein fehlgeschlagenes HRESULT zurückgibt.