Configuration d'un environnement de profilage
.gif "Remarque") Remarque |
|---|
D'importants changements ont été apportés au profilage dans le .NET Framework version 4.Consultez Profilage dans le .NET Framework 4 pour connaître les changements qui affectent la configuration des environnements de profilage. |
Lorsqu'un processus managé (application ou service) démarre, il charge le Common Language Runtime (CLR). Lorsque le CLR est initialisé, il évalue les deux variables d'environnement suivantes pour décider si le processus doit être lié à un profileur :
COR_ENABLE_PROFILING : le CLR ne se connecte à un profileur que si cette variable d'environnement existe et a la valeur 1.
COR_PROFILER : en cas de réussite de la vérification de COR_ENABLE_PROFILING, le CLR se connecte au profileur qui a ce CLSID ou ce ProgID qui a dû être préalablement stocké dans le Registre. La variable d'environnement COR_PROFILER est définie en tant que chaîne, comme indiqué dans les deux exemples suivants.
set COR_PROFILER={32E2F4DA-1BEA-47ea-88F9-C5DAF691C94A} set COR_PROFILER="MyProfiler"
Pour profiler une application du CLR, vous devez définir les variables d'environnement COR_ENABLE_PROFILING et COR_PROFILER avant de lancer l'application. Vous devez également vous assurer que la DLL du profileur est inscrite.
| Remarque |
|---|
À partir du .NET Framework 4, les profileurs n'ont plus besoin d'être inscrits.Pour plus d'informations sur la façon de démarrer des profileurs sans les inscrire en tant que composants COM, consultez Démarrage et attachement de profileurs non basés sur le Registre. |
| Remarque |
|---|
Pour utiliser des profileurs du .NET Framework version 2.0, 3.0 et 3.5 dans le .NET Framework 4 et versions ultérieures, vous devez définir la variable d'environnement COMPLUS_ProfAPI_ProfilerCompatibilitySetting.Pour plus d'informations sur cette variable, consultez Paramètres de compatibilité des profileurs. |
Portée des variables d'environnement
La façon dont vous définissez les variables d'environnement COR_ENABLE_PROFILING et COR_PROFILER déterminent leur champ d'influence. Vous pouvez définir ces variables de l'une des manières suivantes :
Si vous définissez les variables dans un appel ICorDebug::CreateProcess, elles ne s'appliquent alors qu'à l'application en cours d'exécution. (Elles s'appliquent également aux autres applications démarrées par cette application qui héritent de l'environnement.).
Si vous définissez les variables dans une fenêtre d'invite de commandes, elles s'appliquent à toutes les applications qui sont démarrées à partir de cette fenêtre.
Si vous définissez les variables au niveau de l'utilisateur, elles s'appliquent à toutes les applications que vous démarrez avec l'Explorateur Windows. Lorsque vous ouvrez une fenêtre d'invite de commandes après avoir défini les variables, cette fenêtre possède ces paramètres d'environnement, tout comme les applications que vous démarrez à partir de cette fenêtre. Pour définir des variables d'environnement au niveau de l'utilisateur, cliquez avec le bouton droit sur Poste de travail, cliquez sur Propriétés, sur l'onglet Avancé, sur Variables d'environnement et ajoutez les variables à la liste Variables utilisateur.
Si vous définissez les variables au niveau de l'ordinateur, elles s'appliquent à toutes les applications qui sont démarrées sur cet ordinateur. Lorsque vous ouvrez une fenêtre d'invite de commandes sur cet ordinateur, cette fenêtre possède ces paramètres d'environnement, tout comme les applications que vous démarrez à partir de cette fenêtre. En d'autres termes, chaque processus managé sur cet ordinateur va démarrer avec votre profileur. Pour définir des variables d'environnement au niveau de l'ordinateur, cliquez avec le bouton droit sur Poste de travail, cliquez sur Propriétés, sur l'onglet Avancé, sur Variables d'environnement, ajoutez les variables à la liste Variables système et redémarrez l'ordinateur. Une fois redémarré, les variables sont disponibles à l'échelle du système.
Lorsque vous profilez un service Windows, vous devez redémarrer l'ordinateur après avoir défini les variables d'environnement et vous devez enregistrer la DLL du profileur. Pour plus d'informations sur ces considérations, consultez la section Profilage d'un service Windows.
Considérations supplémentaires
La classe du profileur implémente les interfaces ICorProfilerCallback et ICorProfilerCallback2. Dans la version 2.0 du .NET Framework, un profileur doit implémenter ICorProfilerCallback2. Dans le cas contraire, ICorProfilerCallback2 n'est pas chargé.
Un seul profileur peut profiler un processus à un moment donné dans un environnement donné. Vous pouvez inscrire deux profileurs différents dans des environnements différents, mais chacun doit profiler des processus séparés. Le profileur doit être implémenté en tant que DLL de serveur COM in-process, mappée au même espace d'adressage que le processus profilé. En d'autres termes, le profileur s'exécute in-process. Le .NET Framework ne prend pas en charge tout autre type de serveur COM. Par exemple, si un profileur souhaite surveiller des applications à partir d'un ordinateur distant, il doit implémenter des agents de collecteur sur chaque ordinateur. Ces agents traitent les résultats et les communiquent à l'ordinateur de collecte de données central.
Comme le profileur est un objet COM qui est instancié in-process, chaque application profilée possède sa propre copie du profileur. Une seule instance de profileur n'a par conséquent pas à gérer des données issues de plusieurs applications. Vous devez toutefois ajouter une logique au code d'enregistrement du profileur pour empêcher le remplacement du fichier journal par d'autres applications profilées.
Initialisation du profileur
En cas de réussite de la vérification des deux variables d'environnement, le CLR crée une instance du profileur un peu à la manière de la fonction CoCreateInstance COM. Le profileur ne se charge pas via un appel direct à CoCreateInstance. Un appel à CoInitialize, qui requiert la définition du modèle de thread, est ainsi évité. Le CLR appelle ensuite la méthode ICorProfilerCallback::Initialize dans le profileur. La signature de cette méthode est la suivante.
HRESULT Initialize(IUnknown *pICorProfilerInfoUnk)
Le profileur doit interroger pICorProfilerInfoUnk pour un pointeur d'interface ICorProfilerInfo ou ICorProfilerInfo2 et l'enregistrer afin qu'il puisse demander par la suite plus d'informations pendant le profilage.
Définition des notifications d'événements
Le profileur appelle ensuite la méthode ICorProfilerInfo::SetEventMask pour indiquer quelles catégories de notifications l'intéressent. Par exemple, si le profileur s'intéresse uniquement aux notifications d'entrée et de sortie de fonction et aux notifications de garbage collection, il spécifie les éléments suivants.
ICorProfilerInfo* pInfo;
pICorProfilerInfoUnk->QueryInterface(IID_ICorProfilerInfo, (void**)&pInfo);
pInfo->SetEventMask(COR_PRF_MONITOR_ENTERLEAVE | COR_PRF_MONITOR_GC)
En définissant de cette manière le masque de notifications, le profileur peut limiter les notifications qu'il reçoit. Cela permet à l'utilisateur de générer un profileur simple ou à but spécifique. Cela réduit également le temps processeur qui serait gaspillé par l'envoi de notifications qui seraient ignorées par le profileur.
Certains événements de profileur sont immuables. En d'autres termes, dès que ces événements sont définis dans le rappel ICorProfilerCallback::Initialize, ils ne peuvent pas être désactivés et de nouveaux événements ne peuvent pas être activés. Toute tentative de modification d'un événement immuable provoque un ICorProfilerInfo::SetEventMask qui retourne un HRESULT d'échec.
Profilage d'un service Windows
Le profilage d'un service Windows s'apparente au profilage d'une application du Common Language Runtime. Ces deux opérations de profilage sont activées par des variables d'environnement. Étant donné qu'un service Windows est démarré lorsque le système d'exploitation démarre, les variables d'environnement discutées précédemment dans cette rubrique doivent déjà être présentes et définies sur les valeurs requises avant le démarrage du système. De plus, la DLL de profilage doit déjà être enregistrée sur le système.
Une fois les variables d'environnement COR_ENABLE_PROFILING et COR_PROFILER définies et la DLL de profileur enregistrée, vous devez redémarrer l'ordinateur cible pour que le service Windows puisse détecter ces modifications.
Notez que ces modifications activent le profilage à l'échelle du système. Pour empêcher que chaque application managée qui s'exécute par la suite ne soit profilée, vous devez supprimer les variables d'environnement système après avoir redémarré l'ordinateur cible.
Cette technique assure également le profilage de chaque processus du CLR. Le profileur doit ajouter la logique à son rappel ICorProfilerCallback::Initialize pour déterminer si le processus actuel présente un intérêt. Si tel n'est pas le cas, le profileur peut faire échouer le rappel sans exécuter l'initialisation.