Apa itu IRQL (Interrupt Request Level) di Windows dan bagaimana kaitannya dengan BSOD?

Jika Anda pernah melihat layar biru dengan pesan seperti IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_TIDAK_KURANG_ATAU_SAMA, Anda mungkin pernah menemukan konsep yang kurang dikenal di luar dunia pengemudi: IRQL (Interrupt Request Level). Dalam Windows, tingkat prioritas interupsi ini diutamakan daripada prioritas thread ketika sistem berada di atas ambang batas tertentu, dan ini memiliki konsekuensi langsung pada stabilitas.

Pada baris berikutnya Anda akan menemukan sebuah panduan lengkap dan dalam bahasa Spanyol dari Spanyol tentang apa itu IRQL, cara kerjanya, mengapa hal ini memicu layar biru, cara mendiagnosis masalah dengan WinDbg, dan apa yang harus dilakukan, baik Anda pengguna yang mengalami kesalahan maupun yang sedang mengembangkan driver mode kernel. Mari kita mulai.

Apa itu IRQL (Interrupt Request Level) di Windows?

Di Windows, IRQL mendefinisikan prioritas perangkat keras di mana prosesor beroperasi kapan saja. Dalam Windows Driver Model (WDM), kode yang berjalan pada IRQL rendah dapat terganggu oleh kode yang berjalan pada IRQL yang lebih tinggi. Faktanya, pada satu komputer multi-inti, setiap CPU dapat berada pada IRQL yang berbeda, yang mempersulit sinkronisasi.

Ada satu aturan utama: Ketika sebuah CPU berjalan pada IRQL di atas PASSIVE_LEVEL, ia hanya dapat didahului oleh aktivitas pada IRQL yang lebih tinggi.Ini mengatur koeksistensi antara kode pengguna, fungsi kernel, pemanggil tertunda (DPC), dan rutin layanan interupsi perangkat (ISR).

Level dan prioritas: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL dan DIRQL

Secara umum, Pada x86, nilai IRQL antara 0 dan 31 digunakan; pada x64, antara 0 dan 15Arti praktisnya sama: IRQL 0 (PASSIVE_LEVEL) adalah tempat kode pengguna normal dan banyak fungsi driver dieksekusi; APC dan kesalahan halaman Biasanya dipetakan ke IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) mencakup penjadwal thread dan DPC. Di atas DISPATCH_LEVEL terdapat level yang dicadangkan untuk interupsi perangkat (dikenal sebagai DIRQL) dan penggunaan internal lainnya seperti HIGH_LEVEL.

Dalam ekosistem pengemudi, Banyak rutinitas umum yang berjalan pada DISPATCH_LEVELMisalnya, DPC dan StartIo. Desain ini memastikan bahwa ketika salah satu dari keduanya menyentuh antrean internal atau sumber daya bersama lainnya, rutin lain pada tingkat yang sama tidak akan mendahuluinya pada CPU tersebut, karena aturan pendahuluan hanya mengizinkan interupsi pada tingkat yang lebih tinggi.

Antara DISPATCH_LEVEL dan profil/level tinggi ada ruang untuk interupsi perangkat keras setiap perangkat (DIRQL)IRQL suatu perangkat menentukan prioritasnya dibandingkan perangkat lain. Driver WDM memperoleh IRQL ini selama IRP_MJ_PNP dengan IRP_MN_START_DEVICE. IRQL perangkat ini bukanlah nilai global yang tetap, melainkan nilai yang terkait dengan jalur interupsi tertentu.

IRQL vs. Prioritas Thread

Sebaiknya jangan sampai membingungkan konsep: Prioritas thread menentukan kapan penjadwal melakukan preempt dan thread mana yang dieksekusi; IRQL mengontrol jenis aktivitas yang dapat dieksekusi dan interupsi mana yang disamarkan. Di atas DISPATCH_LEVEL, tidak ada peralihan utas: IRQL-lah yang mengontrol, bukan prioritas utas.

IRQL dan Paging: Apa yang Tidak Boleh Anda Lakukan

Efek langsung dari peningkatan IRQL adalah sistem tidak dapat menangani kesalahan halamanAturan emas: kode yang berjalan pada atau di atas DISPATCH_LEVEL tidak dapat menyebabkan kesalahan halaman. Dalam praktiknya, ini berarti bahwa rutin tersebut dan data yang disentuhnya harus berada di memori non-pagedSelain itu, beberapa pembantu kernel membatasi penggunaannya berdasarkan IRQL: misalnya, KeWaitForSingleObject DISPATCH_LEVEL hanya dapat dipanggil jika Anda tidak memblokir (batas waktu nol), dan untuk batas waktu selain nol, Anda harus berada di bawah DISPATCH_LEVEL.

Kontrol IRQL implisit dan eksplisit

Sebagian besar waktu, sistem itu sendiri memanggil rutinitas Anda pada IRQL yang benar Rutinitas pengiriman untuk IRP berjalan pada PASSIVE_LEVEL (dapat memblokir atau memanggil helper apa pun), StartIo dan DPC berjalan pada DISPATCH_LEVEL untuk melindungi antrean bersama, dan ISR berjalan pada DIRQL.

Jika Anda perlu mengontrolnya secara eksplisit, Anda dapat menaikkan dan menurunkan IRQL dengan KeRaiseIrql y KeLowerIrqlAda jalan pintas yang sering digunakan: KeRaiseIrqlToDpcLevel() mengembalikan IRQL sebelumnya dan meninggalkan Anda pada DISPATCH_LEVEL. Penting: Jangan pernah menurunkan IRQL di bawah nilai saat sistem memanggil Anda; mengganggu sinkronisasi tersebut dapat membuka jendela persaingan yang sangat serius.

Kesalahan layar biru terkait IRQL: IRQL_NOT_LESS_OR_EQUAL dan DRIVER_IRQL_NOT_LESS_OR_EQUAL

Dua pemeriksaan bug klasik yang terkait dengan masalah ini adalah IRQL_TIDAK_KURANG_ATAU_SAMA (0xA) y DRIVER_IRQL_TIDAK_KURANG_ATAU_SAMA (0xD1)Keduanya menunjukkan upaya untuk mengakses alamat yang dapat di-page (atau tidak valid) pada IRQL yang terlalu tinggi. Hal ini biasanya disebabkan oleh pengemudi yang menggunakan alamat yang salah, melakukan dereferensi pointer yang buruk, atau mengeksekusi kode yang dapat di-page pada tingkat yang tidak tepat.

Dalam kasus khusus DRIVER_IRQL_TIDAK_KURANG_ATAU_SAMA (0x000000D1)Parameternya sangat informatif: 1) alamat memori yang direferensikan; 2) IRQL pada saat itu; 3) jenis akses (0 baca, 1 tulis, 2/8 eksekusi); 4) alamat instruksi yang mereferensikan memori. Dengan debugger, Anda dapat menggunakan ln pada parameter 4 untuk daftar simbol terdekat dan ketahui fungsi apa yang sedang berjalan.

Penyebab umum yang perlu diingat

Di luar kode spesifik, ada pola yang berulang. Menghapus referensi pointer yang tidak valid ke DISPATCH_LEVEL atau yang lebih tinggi Ini adalah resep pasti untuk bencana. Mengakses data yang dapat di-page pada tingkat tersebut, atau mengeksekusi kode yang dapat di-page (misalnya, fungsi yang ditandai sebagai dapat di-page), juga memicu pemeriksaan bug.

Kasus umum lainnya termasuk memanggil fungsi di driver lain yang telah diunduh (penunjuk fungsi yang menggantung), atau dipanggil secara tidak langsung melalui penunjuk fungsi yang tidak valid. Seringkali, jika sistem dapat mengidentifikasi suatu modul, Anda akan melihat namanya di layar biru itu sendiri, dan namanya juga tersimpan di KiBugCheckDriver, dapat diakses dengan dx KiBugCheckDriver dari WinDbg.

Detail praktis: Pada sebagian besar D1/A, masalah sebenarnya bukanlah IRQL itu sendiri, melainkan alamat memori yang direferensikan. Itulah sebabnya parameter 1, 3, dan 4 sangat penting untuk memfokuskan diagnosis.

Diagnostik dengan WinDbg: Perintah yang berguna dan pembacaan parameter

Untuk menangani kasus-kasus ini, WinDbg adalah alat utama, dan jika BSOD menyebutkan ntoskrnl.exe Informasi ini memberikan banyak petunjuk mengenai apakah kesalahannya ada pada subsistem kernel. Mulailah dengan !analyze -v untuk mendapatkan ringkasan pemeriksaan bug, tumpukan, dan, jika Anda beruntung, modul yang terlibat. Jika dump menyertakan bingkai tangkapan, .trap menempatkan Anda dalam konteks CPU yang gagal.

Los perintah dari tumpukan sebagai k, kb, kc, kd, kp, kP, kv Mereka menunjukkan kepada Anda berbagai tingkat detail backtrace. Dengan ln pada parameter 4 Anda dapat melewatinya ke instruksi yang merujuk ke memori dan dapatkan simbol terdekat. Dan jika Anda mencurigai level prioritas berjalan sebelum interupsi, !irql menunjukkan IRQL yang disimpan untuk prosesor target (misalnya DISPATCH_LEVEL).

Untuk menganalisis arah parameter 1, !pool Ini akan memberi tahu Anda apakah itu termasuk dalam pool berhalaman; !address y !pte mendalami pemetaan memori area tersebut. Anda dapat menggunakan perintah tampilan memori untuk memeriksa konten yang coba diakses. Akhirnya, u, ub, uu memungkinkan Anda membongkar sekitar alamat parameter 4.

Jangan lupa lm t n untuk mencantumkan modul yang dimuat y !memusage untuk keadaan umum memori. Jika KiBugCheckDriver memiliki sesuatu, dx KiBugCheckDriver Ini akan mengembalikan nama modul Unicode: dalam contoh umum, “Wdf01000.sys” terlihat sebagai driver yang terlibat selama pemeriksaan bug.

Alat Sistem: Verifikasi Driver, Penampil Peristiwa, dan Diagnostik

El Verifikator Pengemudi Memeriksa perilaku pengemudi secara real-time dan menerapkan kesalahan ketika mendeteksi penggunaan sumber daya yang salah (seperti pool), memunculkan pengecualian untuk mengisolasi area kode yang bermasalah. Diluncurkan dengan verifier dari command prompt dan disarankan untuk memilih set driver sekecil mungkin untuk menghindari penambahan terlalu banyak overhead.

Jika Anda tidak melihat diri Anda dengan WinDbg, menerapkan langkah-langkah dasarPeriksa log sistem di Event Viewer untuk kesalahan yang mengarah ke perangkat/driver tertentu; perbarui atau nonaktifkan driver yang muncul di layar biru; verifikasi kompatibilitas perangkat keras dengan versi Windows Anda; dan gunakan Windows Memory Diagnostic jika Anda mencurigai RAM bermasalah. Tindakan-tindakan ini, meskipun sederhana, mereka memecahkan sejumlah besar kasus.

Kasus kehidupan nyata: Ketika BSOD tampak acak

Pengguna dengan Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA Papan GeForce GTX 1660 Ti dan Gigabyte B450 AORUS PRO WIFI(RAM 16 GB) mengalami layar "IRQL_LESS_OR_NOT_EQUAL" yang terputus-putus. Saya sudah memperbarui driver penting (jaringan, grafis), menginstal semua pembaruan Windows, dan menjalankan alat memori, semuanya tanpa masalah.

Dalam skenario seperti ini, Langkah selanjutnya adalah menganalisis dump dengan WinDbg dan mencari pola: proses yang terlibat saat jatuh (misalnya, explorer.exe), modul antarmuka grafis (win32kfull.sys) dan fungsi seperti xxxProcessNotifyWinEvent muncul di tumpukan. Meskipun modul ini adalah Windows, pemicunya seringkali merupakan driver pihak ketiga (grafik, input, overlay, capture card) yang menggunakan memori pada IRQL yang tidak sesuai dan kesalahan muncul di dalam win32k.

Rekomendasi praktis di sini adalah nonaktifkan sementara perangkat lunak overlay (capture, GPU OSD), driver periferal perangkat lunak agresif (mouse/keyboard dengan makro), dan versi beta driver grafis, lalu persempit. Menggunakan Driver Verifier pada tersangka dapat membantu mempersempit masalah dengan tumpukan yang lebih jelas.

Pola jaringan yang sangat umum: ndis.sys tidak selalu menjadi penyebabnya

Kasus tipikal lainnya: tangkapan layar dengan ndis.sys (lapisan jaringan Windows). Pada komputer sungguhan, sistem akan langsung crash saat startup. Solusi praktisnya adalah dengan melakukan booting ke Mode aman tanpa fungsi jaringan, buka Pengelola Perangkat dan nonaktifkan adaptor di bawah “Adaptor Jaringan” untuk mengisolasi masalahnya.

Di tim itu ada Pengontrol Keluarga Realtek PCIe GBE dan Atheros AR5007GDengan menonaktifkan keduanya, terdeteksi bahwa penyebab sebenarnya adalah athrx.sys (Atheros), meskipun layar biru yang disebutkan ndis.sysDump tersebut mengonfirmasi hal ini: tumpukan tersebut melewati ndis!NdisFreeTimerObject tapi modul yang bersalah adalah athrx.sysKoreksi terakhir adalah hapus instalan perangkat dan instal driver resmi yang diperbarui Dari situs web produsen Atheros. Moral: Modul yang disebutkan dalam BSOD mungkin merupakan bagian dari subsistem yang terdampak, bukan sumbernya.

Respons dukungan yang khas dan langkah cepat bagi pengguna

Dalam pertukaran dukungan yang tulus, seorang teknisi menjawab: Mohon maaf atas ketidaknyamanannya. Kemungkinan masalahnya ada pada driver, memori, atau antivirus. Harap perbarui driver Anda dan, jika masih bermasalah, jalankan diagnostik memori.Ini adalah saran dasar tetapi valid; namun, jika kesalahan masih berlanjut, sebaiknya lanjutkan dengan analisis Verifier dan dump.

Bagi pengguna non-teknis, protokol yang masuk akal adalah: 1) Periksa peristiwa sistem, 2) Perbarui driver utama (chipset/jaringan/grafik), 3) Periksa RAM dengan alat terintegrasi, 4) uji boot bersihkan tanpa perangkat lunak pihak ketiga yang memasukkan kaitan ke kernel/GUI, dan 5) gunakan Verifier pada driver pihak ketiga jika tidak ada yang jelas.

Praktik terbaik untuk pengembang driver

Jika Anda sedang mengembangkan dan Anda menemukan D1/A, periksa apakah rutinitas yang berjalan tidak ditandai sebagai dapat dihalaman Jangan panggil fungsi yang dapat di-page saat berjalan pada DISPATCH_LEVEL atau lebih tinggi. Ini termasuk menghindari referensi ke data di bagian yang di-page dan mematuhi batasan IRQL untuk kernel helper yang dijelaskan dalam DDK.

Untuk menyinkronkan data yang dibagikan, terapkan aturan "selalu akses data bersama pada IRQL tinggi yang sama" dan gunakan spin lock jika diperlukan. Pada multiprosesor, IRQL saja tidak menjamin pengecualian antar CPU yang berbeda; spin lock menaikkan IRQL (ke DISPATCH_LEVEL) dan mengoordinasikan akses antar inti. Jika Anda perlu beroperasi pada register perangkat keras yang sensitif, KeSynchronizeExecution membantu Anda mengeksekusi bagian penting pada DIRQL yang benar.

Ketika rencana tersebut memerlukan peningkatan IRQL, Amerika Serikat KeRaiseIrqlToDpcLevel untuk DISPATCH_LEVEL atau KeRaiseIrql hati-hati, menyimpan IRQL sebelumnya dan memulihkannya persis dengan KeLowerIrql. Turun di bawah input IRQL, bahkan hanya sesaat, Ini adalah kesalahan sinkronisasi yang serius.

Hubungan dengan interupsi dan perangkat keras

IRQL adalah mekanisme yang digunakan Windows perintah mengganggu prioritas dan tugas internal tertentuPada tingkat arsitektur, hal ini terkait dengan konsep seperti "Interrupt", "Interrupt handler" atau "Interrupt priority level" dan, pada platform klasik, dengan Pengontrol Interupsi Terprogram (PIC)Pada sistem lain, kontrol prioritas diungkapkan melalui mekanisme seperti sp en Unix; ide umumnya sama: siapa yang dapat menyela siapa.

Tips Debugging Lanjutan

Dalam dump di mana tumpukan menunjuk ke win32kfull!xxxProcessNotifyWinEvent dengan pemeriksaan bug 0xA/0xD1, periksa konteks dengan .process y .thread (jika tersedia), lihat proses seperti explorer.exe en !process 0 1 dan periksa overlay dan driver interaksi GUI. Sering kali masalahnya Ini adalah memori yang rusak oleh pihak ketiga yang muncul di rute itu.

Jangan lupa untuk memeriksa IRQL dengan !irql, dan kontras: jika Anda berada di DISPATCH_LEVEL (2) dan parameter 3 menunjukkan baca/tulis/eksekusi Pada halaman yang bisa diberi halaman, Anda sudah punya petunjuk mengapa halaman itu jatuh. Coret petunjuk itu dengan ln pada parameter 4 untuk mendapatkan fungsi spesifik.

memahami Apa itu IRQL? dan bagaimana hal itu sesuai dengan eksekusi kernel membantu memisahkan noise dari sinyal. Jika Anda seorang pengguna, fokuslah pada driver dan perangkat keras (dengan Verifier, event, dan pengujian sebagai default). Jika Anda mengembangkan, ikuti aturan IRQL, memori non-paged, dan sinkronisasi dengan spin lock secara ketat. Dengan alat yang tepat (WinDbg, Verifier) ​​dan pembacaan parameter yang cermat (1, 3, dan 4), Pemeriksaan bug ini bukan lagi misteri. dan menjadi masalah yang dapat ditangani secara metodis.