CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT
Il CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT è stato introdotto in .NET Framework versione 2.0. .NET Framework 4 restituisce questo HRESULT in due scenari:
Quando un profiler di hijacking reimposta il contesto di registrazione di un thread in un momento arbitrario in modo che il thread tenti di accedere alle strutture in uno stato incoerente.
Quando un profiler tenta di chiamare un metodo informativo che attiva Garbage Collection da un metodo di callback che impedisce la Garbage Collection.
Questi due scenari vengono illustrati nelle sezioni seguenti.
Hijacking Profilers
Questo scenario è principalmente un problema con i profiler di hijacking, anche se esistono casi in cui i profiler non di hijacking possono vedere questo HRESULT.
In questo scenario, un profiler di hijacking reimposta in modo forcibly il contesto di registrazione di un thread in un momento arbitrario in modo che il thread possa immettere il codice profiler o entrare nuovamente in Common Language Runtime (CLR) tramite un metodo ICorProfilerInfo .
Molti degli ID forniti dall'API di profilatura puntano alle strutture di dati in CLR. Molte ICorProfilerInfo chiamate ggono semplicemente informazioni da queste strutture di dati e passarle di nuovo. Tuttavia, CLR potrebbe cambiare le cose in tali strutture durante l'esecuzione e potrebbe usare blocchi per farlo. Si supponga che CLR sia già in possesso (o tentativo di acquisizione) di un blocco al momento in cui il profiler ha eseguito il hijacking del thread. Se il thread reentera CLR e tenta di accettare più blocchi o controllare strutture che erano nel processo di modifica, queste strutture potrebbero essere in uno stato incoerente. I deadlock e le violazioni di accesso possono verificarsi facilmente in tali situazioni.
In generale, quando un profiler non hijacking esegue codice all'interno di un metodo ICorProfilerCallback e chiama in un ICorProfilerInfo metodo con parametri validi, non deve essere deadlock o ricevere una violazione di accesso. Ad esempio, il codice profiler eseguito all'interno del metodo ICorProfilerCallback::ClassLoadFinished può richiedere informazioni sulla classe chiamando il metodo ICorProfilerInfo2::GetClassIDInfo2 . Il codice potrebbe ricevere un CORPROF_E_DATAINCOMPLETE HRESULT per indicare che le informazioni non sono disponibili. Tuttavia, non riceverà un deadlock o riceverà una violazione di accesso. Queste chiamate in ICorProfilerInfo sono considerate sincrone, perché vengono eseguite da un ICorProfilerCallback metodo.
Tuttavia, un thread gestito che esegue il codice che non è all'interno di un ICorProfilerCallback metodo viene considerato come eseguire una chiamata asincrona. In .NET Framework versione 1 è stato difficile determinare cosa potrebbe accadere in una chiamata asincrona. La chiamata potrebbe deadlock, arresto anomalo o dare una risposta non valida. .NET Framework versione 2.0 ha introdotto alcuni semplici controlli per evitare questo problema. In .NET Framework 2.0, se si chiama una funzione non sicura ICorProfilerInfo in modo asincrono, si verifica un errore con un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
In generale, le chiamate asincrone non sono sicure. Tuttavia, i metodi seguenti sono sicuri e supportano in modo specifico le chiamate asincrone:
Per altre informazioni, vedere la voce Perché è CORPROF_E_UNSUPPORTED_CALL_SEQUENCE nel blog dell'API di profilatura CLR.
Attivazione di Garbage Collections
Questo scenario implica un profiler in esecuzione all'interno di un metodo di callback (ad esempio uno dei ICorProfilerCallback metodi) che impedisce la Garbage Collection. Se il profiler tenta di chiamare un metodo informativo ,ad esempio un metodo sull'interfaccia ICorProfilerInfo , che potrebbe attivare una Garbage Collection, il metodo informativo ha esito negativo con un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Nella tabella seguente vengono visualizzati i metodi di callback che vietano le garbage collections e i metodi informativi che possono attivare garbage collections. Se il profiler viene eseguito all'interno di uno dei metodi di callback elencati e chiama uno dei metodi informativi elencati, tale metodo informativo ha esito negativo con un CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Vedi anche
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per