Ini rumit. ;)
Tidak, sungguh.
IRQL singkatan dari "Interrupt Request Level". Ini adalah angka, mulai dari 0 hingga 31 pada sistem Windows x86 dan 0 hingga 15 pada sistem x64. Ini mewakili "pentingnya" tugas mode kernel relatif terhadap tugas mode kernel lainnya.
IRQL adalah keadaan prosesor yang ditentukan Windows - bukan dari proses atau utas - yang menunjukkan ke Windows apakah atau tidak apa pun yang dilakukan prosesor dapat terganggu oleh tugas lain. Jika tugas baru (seperti rutinitas layanan interupsi) memiliki IRQL lebih tinggi daripada IRQL prosesor saat ini, maka ya, itu dapat mengganggu tugas saat ini; jika tidak, tidak. Pada sistem multiprosesor, setiap prosesor memiliki IRQL sendiri. Ini termasuk "Prosesor Logis" yang dibuat oleh hyperthreading.
(Saya menggunakan kata "pentingnya" daripada "prioritas" karena "prioritas" di Windows mengacu pada prioritas utas, dan IRQL adalah sesuatu yang berbeda. Tidak seperti prioritas utas, tugas kernel pada IRQL yang sama tidak diiris waktu, dan IRQL tidak t tunduk pada dorongan dan pembusukan otomatis.)
(Saya juga harus menyebutkan bahwa istilah "tugas kernel" di sini tidak resmi. Windows tidak benar-benar menyebut hal-hal ini "tugas kernel", mereka bukan objek yang dikelola seperti misalnya proses dan utas, dan tidak ada hubungan dengan x86 "tugas gerbang "atau ke apa pun yang ditampilkan dalam" Task Manager ". Karena saya (dan yang lain) menggunakan istilah di sini," tugas mode kernel "benar-benar mencakup" apa pun dengan awal dan akhir yang ditentukan yang perlu dilakukan dalam mode kernel di IRQL 2 atau di atas. "Rutin layanan interupsi adalah salah satu contoh dari" tugas mode kernel "; demikian juga rutin DPC. Tetapi contoh lain dapat berupa kode dalam mode kernel. Utas tersebut dimulai pada IRQL 0, tetapi jika bagian dari kode menimbulkanke IRQL 2 atau lebih tinggi, melakukan sesuatu, dan kemudian kembali ke IRQL sebelumnya, bagian IRQL tinggi dari kode adalah salah satu contoh dari apa yang saya sebut "tugas kernel" di sini. )
Monitor Kinerja menunjukkan waktu yang dihabiskan di IRQL 2 sebagai "% DPC waktu" dan waktu di IRQL> 2 sebagai "% waktu interupsi", terlepas dari apakah waktu sebenarnya dihabiskan dalam rutin DPC atau ISR atau merupakan hasil dari meningkatkan IRQL dari nilai yang lebih rendah. Masing-masing adalah bagian dari apa yang PerfMon tunjukkan sebagai "% waktu istimewa" - yang seharusnya diberi label "waktu mode kernel".
Setelah tugas kernel dimulai pada IRQL 2 atau di atasnya, ia berjalan sampai selesai sebelum hal lain di IRQL yang sama akan dimulai pada prosesor yang sama. Ini mungkin terganggu oleh tugas-IRQL yang lebih tinggi (yang pada gilirannya dapat terganggu oleh tugas-IRQL yang lebih tinggi, dll.), Tetapi ketika tugas-tugas yang lebih tinggi-IRQL selesai, kontrol kembali ke tugas yang diinterupsi.
IRQL terutama merupakan mekanisme serialisasi . (Banyak yang mengatakan "sinkronisasi", tapi saya lebih suka kata ini karena lebih tepatnya menggambarkan hasilnya.) Tujuannya adalah untuk membantu menjamin bahwa banyak tugas pada CPU yang sama yang mengakses sumber daya bersama tertentu - sebagian besar struktur data bersama di ruang kernel OS - tidak diperbolehkan saling mengganggu dengan cara yang dapat merusak struktur tersebut.
Sebagai contoh, banyak data dalam kernel Windows, khususnya data manajemen memori dan data yang digunakan oleh penjadwal ulir, "serial" di IRQL 2. Itu berarti bahwa setiap tugas yang ingin memodifikasi data tersebut harus dijalankan di IRQL 2 saat melakukannya. Jika tugas yang lebih tinggi-IRQL mencoba untuk menulis data seperti itu, itu dapat menyebabkan korupsi, karena mungkin telah mengganggu tugas IRQL 2 yang mungkin berada di tengah siklus baca-modifikasi-tulis pada data yang sama. Jadi tugas-tugas yang lebih tinggi-IRQL tidak diizinkan untuk melakukan itu.
Tugas-tugas yang lebih tinggi-IRQL sebagian besar merupakan rutinitas layanan interupsi driver perangkat, karena semua interupsi perangkat terjadi di IRQL> 2. Ini termasuk interupsi dari chip timer pada motherboard yang menggerakkan ketepatan waktu dan aktivitas berbasis waktu di OS. IRQL-nya berada di atas semua perangkat perangkat keras "biasa".
IRQL 2 dan di atasnya digunakan untuk tugas-tugas kernel yang tidak dipicu oleh gangguan hardware tetapi selama penjadwalan thread normal - termasuk menunggu - tidak dapat terjadi. Jadi begitu sebuah prosesor berada di IRQL 2 atau di atas, tidak ada saklar konteks konteks dapat terjadi pada prosesor itu sampai IRQL turun di bawah 2.
Kode mode pengguna selalu di IRQL 0. Kode mode kernel dapat dijalankan di IRQL apa pun mulai 0 hingga apa pun maks. IRQL 1 adalah kasus khusus; itu adalah mode kernel saja tetapi tidak memiliki dampak pada penjadwalan, dan benar-benar lebih merupakan keadaan thread daripada prosesor - itu disimpan dan dipulihkan selama switch konteks thread, misalnya.
Untuk mempertahankan berbagai jaminan serialisasi, sebagian besar pengecualian (hal-hal seperti pembagian dengan nol, atau pelanggaran akses memori seperti kesalahan halaman) sama sekali tidak dapat ditangani di IRQL 2 atau di atasnya. (IRQL 2 btw umumnya disebut "level pengiriman" atau "tingkat DPC".)
Dan sekarang kita akhirnya dapat menjelaskan kode cek bug ini!
Kasus IRQL_NOT_LESS_OR_EQUAL yang paling umum adalah karena kesalahan halaman (upaya untuk mengakses alamat virtual "bukan penduduk"), atau pelanggaran akses memori (upaya menulis ke halaman hanya-baca, atau untuk mengakses halaman yang tidak ditentukan sama sekali), yang terjadi di IRQL 2 atau lebih tinggi.
Jika pengecualian tersebut dinaikkan pada IRQL 0 atau 1, mereka dapat "ditangani" baik dengan kode yang disediakan sistem (seperti penangan kesalahan halaman) atau oleh penangan pengecualian yang disediakan oleh pengembang. Namun, sebagian besar pengecualian tidak dapat ditangani sama sekali jika terjadi di IRQL 2 atau lebih tinggi.
Jadi ... kode bugcheck berarti "pengecualian tipe yang hanya dapat ditangani di IRQL 0 atau 1 terjadi ketika IRQL berada di 2 atau lebih tinggi." yaitu "tidak kurang dari atau sama dengan 1". Kata-kata aneh, tapi itu dia.
Ada beberapa hal lain yang dapat memicu bugcheck ini, dan nilai bahwa IRQL tidak kurang atau sama dengan tidak selalu 1, tetapi jarang terjadi. Dokumentasi WinDBG mencantumkannya.