2010-08-21 2 views
3

J'ai écrit un petit profileur pour les applications .NET. Il utilise l'interface ICorProfilerCallback2.Pourquoi le profiler ne peut-il pas se fixer?

Le profileur se connecte et fonctionne bien pour l'application .NET 2.0 mais ne fonctionne pas pour .NET> 2.0 (3.0, 3.5, 4.0). Quand je démarre un exe compilé avec .NET 4.0 rien ne se passe, cependant pour .NET 2.0 le profileur démarre. J'installe les variables suivantes avant d'exécuter un exe géré

@Echo off 
set Cor_Enable_Profiling=0x1 
set COR_PROFILER={67D8965A-8686-2639-9C24-E1F7D13EE105} 
set COR_PROFILER_DLL=e:\Debug\Profiler.dll 
set COR_PROFILER_PATH=e:\Debug\Profiler.dll 

Toute idée pourquoi cela pourrait se produire? Il n'a même pas entrer en DllMain

Répondre

4

Timotei,

Le problème que vous parlez est probablement couvert dans le poste de David Broman: http://blogs.msdn.com/b/davbr/archive/2009/05/26/run-your-v2-profiler-binary-on-clr-v4.aspx

Pour l'exécution V4 CLR vous devriez voir des informations utiles en cas Log (voir avec Event Viewer) décrivant pourquoi le profileur n'a pas pu être chargé.

Si vous ne souhaitez pas utiliser le paramètre COMPLUS_ProfAPI_ProfilerCompatibilitySetting décrit dans le blog, vous pouvez également prendre en charge l'interface ICorProfilerCallback3 pour ajouter la prise en charge de l'environnement d'exécution V4. Avec CLR V4, vous devrez peut-être également envisager des scénarios côte à côte, dans lesquels les temps d'exécution V2 et V4 sont chargés dans un seul exécutable. Pour plus d'informations, reportez-vous à l'autre article de David intitulé 'Profileurs, instances CLR côte à côte en cours de traitement, et un faisceau de test gratuit' (malheureusement, je ne peux pas poster un lien à cause de la prévention du spam).

Questions connexes