Freigeben über


CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT

CORPROF_E_UNSUPPORTED_CALL_SEQUENCE-HRESULT wurde in der .NET Framework-Version 2.0 eingeführt. Von .NET Framework 4 wird dieses HRESULT in zwei Szenarien zurückgegeben:

  • Wenn ein Hijacking-Profiler zu einem beliebigen Zeitpunkt die Zurücksetzung des Registrierungskontexts eines Threads erzwingt, sodass der Thread versucht, auf Strukturen zuzugreifen, die sich in einem inkonsistenten Zustand befinden

  • Wenn ein Profiler versucht, über eine Rückrufmethode, die keine Garbage Collection zulässt, eine Informationsmethode aufzurufen, die die Garbage Collection auslöst

Diese beiden Szenarien werden in den folgenden Abschnitten erläutert.

Hijacking-Profiler

(Dieses Szenario ist in erster Linie ein Problem mit Hijacking-Profilern. Es gibt aber auch Fälle, in denen dieses HRESULT für Nicht-Highjacking-Profiler auftritt.)

In diesem Szenario erzwingt ein Hijacking-Profiler zu einem beliebigen Zeitpunkt die Zurücksetzung des Registrierungskontexts eines Threads, sodass der Thread über eine ICorProfilerInfo-Methode Zugang zu Profilercode oder erneut Zugang zur Common Language Runtime (CLR) erhält.

Viele der von der Profilerstellungs-API bereitgestellten IDs zeigen auf Datenstrukturen in der CLR. Viele ICorProfilerInfo-Aufrufe lesen lediglich Informationen aus diesen Datenstrukturen und geben sie zurück. Die CLR kann während der Ausführung aber auch Dinge in diesen Strukturen ändern und dazu ggf. Sperren verwenden. Angenommen, die CLR verfügte bereits über eine Sperre (oder hat versucht, eine Sperre zu erhalten), als der Profiler den Thread übernommen hat. Wenn der Thread erneut auf die CLR zugreift und versucht, weitere Sperren zu erhalten oder Strukturen zu überprüfen, die gerade geändert wurden, befinden sich diese Strukturen möglicherweise in einem inkonsistenten Zustand. In solchen Situationen kann es zu Deadlocks und Zugriffsverletzungen kommen.

Wenn ein Nicht-Hijacking-Profiler Code innerhalb einer ICorProfilerCallback-Methode ausführt und eine ICorProfilerInfo-Methode mit gültigen Parametern aufruft, sollten im Allgemeinen kein Deadlock und keine Zugriffsverletzung auftreten. Beispielsweise kann Profilercode, der innerhalb der ICorProfilerCallback::ClassLoadFinished-Methode ausgeführt wird, durch Aufrufen der ICorProfilerInfo2::GetClassIDInfo2-Methode Informationen zur Klasse anfordern. Daraufhin wird möglicherweise durch Rückgabe des CORPROF_E_DATAINCOMPLETE-HRESULT angegeben, dass keine Informationen verfügbar sind. Es treten jedoch kein Deadlock und keine Zugriffsverletzung auf. Diese Aufrufe von ICorProfilerInfo gelten als synchron, da über eine ICorProfilerCallback-Methode erfolgen.

Ein verwalteter Thread, der Code ausführt, der sich nicht innerhalb einer ICorProfilerCallback-Methode befindet, wird dagegen als asynchroner Aufruf betrachtet. In der .NET Framework-Version 1 war es schwierig zu bestimmen, was ggf. in einem asynchronen Aufruf passiert. Mögliche Ergebnisse waren ein Deadlock, ein Absturz oder eine ungültige Antwort. In .NET Framework 2.0 wurden einige einfache Überprüfungen eingeführt, mit denen Sie dieses Problem vermeiden können. Wenn Sie in .NET Framework 2.0 asynchron eine unsichere ICorProfilerInfo-Funktion aufrufen, tritt ein Fehler mit CORPROF_E_UNSUPPORTED_CALL_SEQUENCE-HRESULT auf.

Asynchrone Aufrufe sind im Allgemeinen nicht sicher. Die folgenden Methoden sind jedoch sicher und unterstützen speziell asynchrone Aufrufe:

Weitere Informationen finden Sie im Blog zur CLR-Profilerstellungs-API im Eintrag Why we have CORPROF_E_UNSUPPORTED_CALL_SEQUENCE (Zweck von CORPROF_E_UNSUPPORTED_CALL_SEQUENCE).

Auslösen von Garbage Collections

Dieses Szenario beinhaltet einen Profiler, der innerhalb einer Rückrufmethode (z. B. einer der ICorProfilerCallback-Methoden) ausgeführt wird, die keine Garbage Collection zulässt. Wenn der Profiler versucht, eine Informationsmethode aufzurufen (z. B. eine Methode in der ICorProfilerInfo-Schnittstelle), die möglicherweise eine Garbage Collection auslöst, tritt für die Informationsmethode ein Fehler mit CORPROF_E_UNSUPPORTED_CALL_SEQUENCE-HRESULT auf.

Die folgende Tabelle enthält die Rückrufmethoden, bei denen keine Garbage Collection zulässig ist, sowie Informationsmethoden, die ggf. eine Garbage Collection auslösen. Wenn der Profiler in einer der aufgeführten Rückrufmethoden ausgeführt und eine der aufgeführten Informationsmethoden aufruft, tritt für diese Informationsmethode ein Fehler mit CORPROF_E_UNSUPPORTED_CALL_SEQUENCE-HRESULT auf.

Rückrufmethoden, die Garbage Collection verbieten Informationsmethoden, die Garbage Collection 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