CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT
CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT introducerades i .NET Framework version 2.0. .NET Framework 4 returnerar denna HRESULT i två scenarier:
När en kapningsprofiler med två skäl återställer en tråds registerkontext vid en godtycklig tidpunkt så att tråden försöker komma åt strukturer som är i ett inkonsekvent tillstånd.
När en profilerare försöker anropa en informationsmetod som utlöser skräpinsamling från en återanropsmetod som förbjuder skräpinsamling.
Dessa två scenarier beskrivs i följande avsnitt.
Kapning profilerare
(Det här scenariot är främst ett problem med kapning av profilerare, även om det finns fall där icke-kapande profilerare kan se denna HRESULT.)
I det här scenariot återställer en kapningsprofiler med två två skäl en tråds registerkontext vid en godtycklig tidpunkt så att tråden kan ange profileringskod eller ange CLR (Common Language Runtime) igen via en ICorProfilerInfo-metod .
Många av de ID:n som profilerings-API:et tillhandahåller pekar på datastrukturer i CLR. Många ICorProfilerInfo anrop läser bara information från dessa datastrukturer och skickar tillbaka dem. CLR kan dock ändra saker i dessa strukturer när den körs, och den kan använda lås för att göra det. Anta att CLR redan höll (eller försökte skaffa) ett lås när profileraren kapade tråden. Om tråden reenters CLR och försöker ta fler lås eller inspektera strukturer som håller på att ändras, dessa strukturer kan vara i ett inkonsekvent tillstånd. Dödlägen och åtkomstöverträdelser kan enkelt inträffa i sådana situationer.
När en profilerare som inte kapar kör kod i en ICorProfilerCallback-metod och anropar en ICorProfilerInfo metod med giltiga parametrar bör den i allmänhet inte låsas upp eller få ett åtkomstfel. Profilerkod som körs i metoden ICorProfilerCallback::ClassLoadFinished kan till exempel be om information om klassen genom att anropa metoden ICorProfilerInfo2::GetClassIDInfo2 . Koden kan få en CORPROF_E_DATAINCOMPLETE HRESULT som anger att informationen inte är tillgänglig. Det kommer dock inte att blockeras eller ta emot ett åtkomstfel. Dessa anrop till ICorProfilerInfo betraktas som synkrona eftersom de görs från en ICorProfilerCallback metod.
En hanterad tråd som kör kod som inte finns i en ICorProfilerCallback metod anses dock göra ett asynkront anrop. I .NET Framework version 1 var det svårt att avgöra vad som kan hända i ett asynkront anrop. Samtalet kan vara låst, krascha eller ge ett ogiltigt svar. .NET Framework version 2.0 introducerade några enkla kontroller som hjälper dig att undvika det här problemet. Om du anropar en osäker ICorProfilerInfo funktion asynkront i .NET Framework 2.0 misslyckas den med en CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
I allmänhet är asynkrona anrop inte säkra. Följande metoder är dock säkra och stöder särskilt asynkrona anrop:
Mer information finns i artikeln Varför vi har CORPROF_E_UNSUPPORTED_CALL_SEQUENCE i CLR Profiling API-bloggen.
Utlösa skräpsamlingar
I det här scenariot ingår en profilerare som körs i en återanropsmetod (till exempel en av ICorProfilerCallback metoderna) som förbjuder skräpinsamling. Om profileraren försöker anropa en informationsmetod (till exempel en metod i ICorProfilerInfo gränssnittet) som kan utlösa en skräpinsamling misslyckas informationsmetoden med en CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
I följande tabell visas återanropsmetoder som förbjuder skräpsamlingar och informationsmetoder som kan utlösa skräpsamlingar. Om profileraren körs i någon av de angivna motringningsmetoderna och anropar någon av de angivna informationsmetoderna misslyckas den informationsmetoden med en CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Se även
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för