Partager via


CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT

CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT a été introduit dans le .NET Framework version 2.0. Le .NET Framework version 4retourne ce HRESULT dans deux scénarios :

  • Lorsqu'un profileur de détournement réinitialise de force le contexte de registre d'un thread à un moment arbitraire afin que le thread essaie d'accéder aux structures qui sont dans un état incohérent.

  • Lorsqu'un profileur essaie d'appeler une méthode à caractère informatif qui déclenche le garbage collection à partir d'une méthode de rappel qui interdit le garbage collection.

Ces deux scénarios sont discutés dans les sections suivantes.

Profileurs d'attaques de sécurité

(Ce scénario est principalement un problème de détournement des profileurs bien qu'il existe des cas où des profileurs non détournés peuvent consulter ce HRESULT.)

Dans ce scénario, un profileur malveillant réinitialise de force le contexte de registre d'un thread à un moment arbitraire afin que le thread puisse entrer le code de profileur ou entrer de nouveau le common language runtime (CLR) via une méthode ICorProfilerInfo.

De nombreux ID fournis par l'API de profilage pointent vers des structures de données du CLR. De nombreux appels ICorProfilerInfo lisent simplement les informations de ces structures de données et les passent. Toutefois, lorsqu'il s'exécute, le CLR peut modifier des éléments dans ces structures et peut utiliser des verrous à cette fin. Supposez que le CLR contient déjà (ou essaie d'acquérir) un verrou au moment où le profileur a détourné le thread. Si le thread entre à nouveau le CLR et essaie de prendre plus de verrous ou d'inspecter des structures sur le point d'être modifiées, ces structures peuvent être dans un état cohérent. Des interblocages et des violations d'accès peuvent se produire facilement dans de telles situations.

En général, lorsqu'un profileur non malveillant exécute le code à l'intérieur d'une méthode ICorProfilerCallback et appelle depuis une méthode ICorProfilerInfo avec des paramètres valides, il ne doit pas entraîner d'interblocage ni recevoir de message de violation d'accès. Par exemple, le profileur de code qui s'exécute à l'intérieur de la méthode ICorProfilerCallback::ClassLoadFinished demande des informations sur la classe en appelant la méthode ICorProfilerInfo2::GetClassIDInfo2. Le code peut recevoir un résultat CORPROF_E_DATAINCOMPLETE HRESULT pour indiquer que les informations ne sont pas disponibles. Toutefois, il n'aboutira pas à un interblocage et ne recevra pas de violation d'accès. Cette classe d'appels dans ICorProfilerInfo est appelée synchrone, car ils sont réalisé à partir d'une méthode ICorProfilerCallback.

Toutefois, un thread managé qui exécute du code qui se trouve à l'extérieur d'une méthode ICorProfilerCallback est considéré comme passant un appel asynchrone. Dans la version du .NET Framework 1, il était difficile de déterminer ce qui pouvait arriver dans un appel asynchrone. L'appel pourrait aboutir à un interblocage, tomber en panne ou donner une réponse non valide. Le .NET Framework version 2.0 a introduit des contrôles simples pour vous aider à éviter ce problème. Dans le .NET Framework 2.0, si vous appelez une fonction ICorProfilerInfo potentiellement dangereuse de façon asynchrone, elle échoue avec un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.

En général, les appels asynchrones ne sont pas sécurisés. Toutefois, les méthodes suivantes sont sécurisées et prennent spécialement en charge les appels asynchrones :

Pour plus d'informations, consultez l'entrée Why we have CORPROF_E_UNSUPPORTED_CALL_SEQUENCE dans le blog CLR Profiling API.

Déclenchement de garbage collections

Ce scénario implique un profileur qui s'exécute à l'intérieur d'une méthode de rappel (par exemple, l'une des méthodes ICorProfilerCallback) qui défend le garbage collection. Si le profileur essaie d'appeler une méthode à caractère informatif (par exemple, une méthode sur l'interface ICorProfilerInfo) qui peut déclencher un garbage collection, la méthode à caractère informatif échoue avec un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.

Le tableau suivant affiche les méthodes de rappel qui interdisent les garbage collections et les méthodes à caractère informatif qui peuvent déclencher des garbage collections. Si le profileur s'exécute à l'intérieur de l'une des méthodes de rappel répertoriées et appelle l'une des méthodes à caractère informatif répertoriées, la méthode à caractère informatif échoue avec un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.

Méthodes de rappel qui interdisent les garbage collections.

Méthodes à caractère informatif qui déclenchent les garbage collection

ThreadAssignedToOSThread

ExceptionUnwindFunctionEnter

ExceptionUnwindFunctionLeave

ExceptionUnwindFinallyEnter

ExceptionUnwindFinallyLeave

ExceptionCatcherEnter

RuntimeSuspendStarted

RuntimeSuspendFinished

RuntimeSuspendAborted

RuntimeThreadSuspended

RuntimeThreadResumed

MovedReferences

ObjectReferences

ObjectsAllocatedByClass

RootReferences2

HandleCreated

HandleDestroyed

GarbageCollectionStarted

GarbageCollectionFinished

GetILFunctionBodyAllocator

SetILFunctionBody

SetILInstrumentedCodeMap

ForceGC

GetClassFromToken

GetClassFromTokenAndTypeArgs

GetFunctionFromTokenAndTypeArgs

GetAppDomainInfo

EnumModules

RequestProfilerDetach

GetAppDomainsContainingModule

Voir aussi

Référence

ICorProfilerCallback, interface

ICorProfilerCallback2, interface

ICorProfilerCallback3, interface

ICorProfilerInfo, interface

ICorProfilerInfo2, interface

ICorProfilerInfo3, interface

Autres ressources

Interfaces de profilage

Profilage (Référence des API non managées)