CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT
CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT diperkenalkan pada .NET Framework versi 2.0. .NET Framework 4 mengembalikan HRESULT ini dalam dua skenario:
Ketika profiler pembajakan secara paksa mengatur ulang konteks register utas pada waktu yang terus berubah sehingga utas mencoba mengakses struktur yang berada dalam keadaan tidak konsisten.
Ketika profiler mencoba memanggil metode informasi yang memicu pengumpulan sampah dari metode panggilan balik yang melarang pengumpulan sampah.
Kedua skenario ini dibahas di bagian berikut.
Membajak Profiler
(Skenario ini terutama merupakan masalah dengan pembajakan profiler, meskipun ada kasus yang mana profiler tanpa pembajakan dapat melihat HRESULT ini.)
Dalam skenario ini, profiler pembajakan secara paksa mengatur ulang konteks register utas pada waktu yang terus berubah sehingga utas dapat memasukkan kode profiler atau memasukkan kembali runtime bahasa umum (CLR) melalui metode ICorProfilerInfo.
Banyak ID yang disediakan oleh API pembuatan profil menunjuk ke struktur data di CLR. Banyak panggilan ICorProfilerInfo hanya membaca informasi dari struktur data ini dan meneruskannya kembali. Namun, CLR mungkin mengubah hal-hal dalam struktur tersebut saat berjalan dan mungkin menggunakan kunci untuk melakukannya. Misalkan CLR sudah menyimpan (atau mencoba untuk memperoleh) kunci pada saat profiler membajak utas. Jika utas masuk kembali ke CLR dan mencoba mengambil lebih banyak kunci atau memeriksa struktur yang sedang dalam proses modifikasi, struktur ini mungkin dalam keadaan tidak konsisten. Kebuntuan dan pelanggaran akses dapat dengan mudah terjadi dalam situasi seperti itu.
Secara umum, ketika profiler tanpa pembajakan menjalankan kode di dalam metode ICorProfilerCallback dan memanggil metode ICorProfilerInfo dengan parameter yang valid, seharusnya tidak menemui jalan buntu atau menerima pelanggaran akses. Misalnya, kode profiler yang berjalan di dalam metode ICorProfilerCallback::ClassLoadFinished mungkin meminta informasi tentang kelas dengan memanggil metode ICorProfilerInfo2::GetClassIDInfo2. Kode dapat menerima CORPROF_E_DATAINCOMPLETE HRESULT untuk menunjukkan bahwa informasi tidak tersedia. Namun, metode itu tidak akan menemui jalan buntu atau menerima pelanggaran akses. Panggilan ke ICorProfilerInfo ini dianggap sinkron, karena dibuat dari metode ICorProfilerCallback.
Namun, utas terkelola yang menjalankan kode yang tidak berada dalam metode ICorProfilerCallback dianggap melakukan panggilan asinkron. Dalam .NET Framework versi 1, sulit untuk menentukan apa yang mungkin terjadi dalam panggilan asinkron. Panggilan bisa mengalami kebuntuan, crash, atau memberikan jawaban yang tidak valid. .NET Framework versi 2.0 memperkenalkan beberapa pemeriksaan sederhana untuk membantu Anda menghindari masalah ini. Di .NET Framework 2.0, jika Anda memanggil fungsi ICorProfilerInfo yang tidak aman secara asinkron, fungsi tersebut gagal dengan CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Secara umum, panggilan asinkron tidak aman. Namun, metode berikut ini aman dan secara khusus mendukung panggilan asinkron:
Untuk informasi selengkapnya, lihat entri Mengapa kami memiliki CORPROF_E_UNSUPPORTED_CALL_SEQUENCE di blog CLR Pembuatan Profil API.
Memicu Pengumpulan Sampah
Skenario ini melibatkan profiler yang berjalan di dalam metode panggilan balik (misalnya, salah satu metode ICorProfilerCallback) yang melarang pengumpulan sampah. Jika profiler mencoba memanggil metode informasi (misalnya, metode pada antarmuka ICorProfilerInfo) yang mungkin memicu pengumpulan sampah, metode informasi gagal dengan CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Tabel berikut menampilkan metode panggilan balik yang melarang pengumpulan sampah dan metode informasi yang dapat memicu pengumpulan sampah. Jika profiler menjalankan di dalam salah satu metode panggilan balik yang terdaftar dan memanggil salah satu metode informasi yang terdaftar, metode informasi tersebut gagal dengan CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
