Freigeben über


CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT

Das CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT wurde in .NET Framework, Version 2.0, eingeführt. .NET Framework, Version 4 gibt dieses HRESULT in zwei Szenarien zurück:

  • Wenn ein Profiler mit Fremdsteuerung den Registerkontext eines Threads zwangsweise auf einen beliebigen Zeitpunkt zurücksetzt, sodass der Thread versucht, auf Strukturen zuzugreifen, die in einem inkonsistenten Zustand sind.

  • Wenn ein Profiler versucht, eine Informationsmethode aufzurufen, die von einer Rückrufmethode, die Garbage Collection verbietet, die Garbage Collection auslöst.

Diese beiden Szenarios werden in den folgenden Abschnitten beschrieben.

Profiler mit Fremdsteuerung

(Dieses Szenario ist hauptsächlich ein Problem bei Profilern mit Fremdsteuerung, obwohl es Fälle gibt, in den Profiler ohne Fremdsteuerung dieses HRESULT sehen können.)

In diesem Szenario erzwingt ein Profiler mit Fremdsteuerung zu einem beliebigen Zeitpunkt das Zurücksetzen des Registerkontexts eines Threads, damit der Thread Profilercode ausführen oder durch eine ICorProfilerInfo-Methode wieder in die Common Language Runtime (CLR) zurückkehren kann.

Viele der IDs, die die Profilerstellungs-API bereitstellt, zeigen auf Datenstrukturen in der CLR. Viele ICorProfilerInfo-Aufrufe lesen nur Informationen aus diesen Datenstrukturen und geben sie zurück. Die CLR könnte bei der Ausführung jedoch Elemente in diesen Strukturen ändern und hierfür Sperren verwenden. Angenommen, die CLR hielt bereits eine Sperre (oder versuchte, diese abzurufen), als der Profiler den Thread übernommen hat. Wenn der Thread erneut in die CLR eintritt und versucht, weitere Sperren abzurufen oder Strukturen zu überprüfen, die gerade geändert wurden, dann können sich diese Strukturen in einem inkonsistenten Zustand befinden. Deadlocks und Zugriffsverletzungen können in solchen Situationen leicht auftreten.

Wenn ein Profiler ohne Fremdsteuerung Code in einer ICorProfilerCallback-Methode ausführt und eine ICorProfilerInfo-Methode mit gültigen Parametern aufruft, sollten im Allgemeinen kein Deadlock und keine Zugriffsverletzung auftreten. Beispielsweise fragt Profilercode, der in der ICorProfilerCallback::ClassLoadFinished-Methode ausgeführt wird, möglicherweise Informationen zur Klasse ab, indem er die ICorProfilerInfo2::GetClassIDInfo2-Methode aufruft. Im Code könnte ein CORPROF_E_DATAINCOMPLETE HRESULT empfangen werden, um anzugeben, dass Informationen nicht verfügbar sind. Es tritt jedoch kein Deadlock und keine Zugriffsverletzung auf. Diese Klasse von Aufrufen von ICorProfilerInfo wird synchron genannt, da sie von einer ICorProfilerCallback-Methode gemacht werden.

Bei einem verwalteten Thread, der Code ausführt, der nicht innerhalb einer ICorProfilerCallback-Methode ist, wird angenommen, dass er einen asynchronen Aufruf ausführt. In .NET Framework, Version 1, war es schwierig zu bestimmen, was in einem asynchronen Aufruf geschehen könnte. Der Aufruf könnte zu einem Deadlock, einem Absturz oder einer ungültigen Antwort führen. .NET Framework, Version 2.0, hat einige einfache Überprüfungen eingeführt, um Ihnen dieses Problem vermeiden zu helfen. Wenn Sie in .NET Framework 2.0 eine unsichere ICorProfilerInfo-Funktion asynchron aufrufen, schlägt sie mit dem HRESULT CORPROF_E_UNSUPPORTED_CALL_SEQUENCE fehl.

Im Allgemeinen sind asynchrone Aufrufe nicht sicher. Die folgenden Methoden sind jedoch sicher und unterstützen ausdrücklich asynchrone Aufrufe:

Weitere Informationen finden Sie im Eintrag Why we have CORPROF_E_UNSUPPORTED_CALL_SEQUENCE im Blog zur Profilerstellungs-API der CLR.

Auslösen von Garbage Collections

Dieses Szenario betrifft einen Profiler, der in einer Rückrufmethode (z. B. einer der ICorProfilerCallback-Methoden) ausgeführt wird, die die Garbage Collection verbietet. Wenn der Profiler versucht, eine Informationsmethode aufzurufen (z. B. eine Methode der ICorProfilerInfo-Schnittstelle), die eine Garbage Collection auslösen könnte, schlägt die Informationsmethode mit einem CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT fehl.

In der folgenden Tabelle werden die Rückrufmethoden aufgeführt, die Garbage Collections und Informationsmethoden verbieten, die möglicherweise Garbage Collections auslösen. Wenn der Profiler in einer der aufgeführten Rückrufmethoden ausgeführt wird und eine der aufgeführten Informationsmethoden aufruft, schlägt diese Informationsmethode mit einem CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT fehl.

Rückrufmethoden, die Garbage Collections verbieten

Informationsmethoden, die Garbage Collections auslösen

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

Siehe auch

Referenz

ICorProfilerCallback-Schnittstelle

ICorProfilerCallback2-Schnittstelle

ICorProfilerCallback3-Schnittstelle

ICorProfilerInfo-Schnittstelle

ICorProfilerInfo2-Schnittstelle

ICorProfilerInfo3-Schnittstelle

Weitere Ressourcen

Profilerstellungsschnittstellen

Profilerstellung (Referenz zur nicht verwalteten API)