Apakah IRQL (Tahap Permintaan Interupsi) dalam Windows dan bagaimana ia berkaitan dengan BSOD?

Jika anda pernah melihat skrin biru dengan mesej seperti IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, anda mungkin menjumpai konsep yang kurang diketahui di luar dunia pemandu: IRQL (Tahap Permintaan Interupsi). Dalam Windows, tahap keutamaan gangguan ini lebih diutamakan daripada keutamaan utas apabila sistem berada di atas ambang tertentu, dan ini mempunyai akibat langsung ke atas kestabilan.

Dalam baris seterusnya anda akan dapati yang panduan lengkap dan dalam bahasa Sepanyol dari Sepanyol tentang apa itu IRQL, cara ia berfungsi, sebab ia mencetuskan skrin biru, cara mendiagnosis masalah dengan WinDbg, dan perkara yang perlu dilakukan sama ada anda pengguna yang mengalami ralat atau membangunkan pemacu mod kernel. Mari berniaga.

Apakah IRQL (Tahap Permintaan Interupsi) dalam Windows?

Di Windows, yang IRQL mentakrifkan keutamaan bagi perkakasan di mana pemproses beroperasi pada bila-bila masa. Dalam Model Pemacu Windows (WDM), kod yang berjalan pada IRQL rendah boleh diganggu oleh kod berjalan pada IRQL yang lebih tinggi. Malah, pada komputer berbilang teras tunggal, setiap CPU boleh berada pada IRQL yang berbeza, yang menyukarkan penyegerakan.

Terdapat satu peraturan utama: Apabila CPU berjalan pada IRQL di atas PASSIVE_LEVEL, ia hanya boleh didahulukan oleh aktiviti pada IRQL yang lebih tinggi.Ini mengatur kewujudan bersama antara kod pengguna, fungsi kernel, pemanggil tertunda (DPC) dan rutin perkhidmatan gangguan peranti (ISR).

Tahap dan keutamaan: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL dan DIRQL

Secara umum, Pada x86, nilai IRQL antara 0 dan 31 digunakan; pada x64, antara 0 dan 15Maksud praktikal adalah sama: IRQL 0 (PASSIVE_LEVEL) ialah tempat kod pengguna biasa dan banyak fungsi pemacu dilaksanakan; APC dan kerosakan halaman Mereka biasanya dipetakan ke IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) merangkumi penjadual benang dan DPC. Di atas DISPATCH_LEVEL adalah tahap yang dikhaskan untuk gangguan peranti (dikenali sebagai DIRQL) dan kegunaan dalaman lain seperti HIGH_LEVEL.

Dalam ekosistem pemandu, Banyak rutin biasa dijalankan di DISPATCH_LEVEL: contohnya, DPC dan StartIo. Reka bentuk ini memastikan bahawa semasa salah satu daripadanya menyentuh baris gilir dalaman atau sumber kongsi lain, rutin lain pada tahap yang sama tidak mendahuluinya pada CPU itu, kerana peraturan preemption hanya membenarkan gangguan pada tahap yang lebih tinggi.

Di antara DISPATCH_LEVEL dan pemprofilan/peringkat tinggi terdapat ruang untuk gangguan perkakasan setiap peranti (DIRQL)IRQL peranti mentakrifkan keutamaannya berbanding peranti lain. Pemacu WDM memperoleh IRQL ini semasa IRP_MJ_PNP dengan IRP_MN_START_DEVICE. IRQL peranti ini bukan nilai tetap global, sebaliknya nilai yang dikaitkan dengan talian gangguan tertentu.

IRQL lwn. Keutamaan Benang

Adalah dinasihatkan untuk tidak mengelirukan konsep: Keutamaan utas menentukan bila penjadual mendahului dan urutan mana yang dilaksanakan; IRQL mengawal jenis aktiviti yang boleh dilaksanakan dan gangguan yang bertopeng. Di atas DISPATCH_LEVEL, tiada penukaran benang: IRQL yang mengawal, bukan keutamaan benang.

IRQL dan Paging: Perkara yang Anda Tidak Patut Lakukan

Kesan segera daripada meningkatkan IRQL ialah sistem tidak boleh menangani kerosakan halaman. Peraturan emas: kod yang dijalankan pada atau di atas DISPATCH_LEVEL tidak boleh menyebabkan kerosakan halaman. Dalam amalan, ini bermakna bahawa rutin dan data yang mereka sentuh mesti berada dalam ingatan bukan halaman. Di samping itu, pembantu kernel tertentu mengehadkan penggunaannya berdasarkan IRQL: contohnya, KeWaitForSingleObject DISPATCH_LEVEL hanya boleh dipanggil jika anda tidak menyekat (sifar masa tamat), dan untuk bukan sifar tamat masa, anda perlu berada di bawah DISPATCH_LEVEL.

Kawalan tersirat dan eksplisit IRQL

Selalunya, sistem itu sendiri memanggil rutin anda pada IRQL yang betul untuk apa yang mereka patut lakukan. Rutin penghantaran untuk IRP dijalankan di PASSIVE_LEVEL (mereka boleh menyekat atau memanggil mana-mana pembantu), StartIo dan DPC dijalankan di DISPATCH_LEVEL untuk melindungi baris gilir dikongsi dan ISR dijalankan di DIRQL.

Jika anda perlu mengawalnya secara eksplisit, Anda boleh menaikkan dan menurunkan IRQL dengan KeRaiseIrql y KeLowerIrqlTerdapat pintasan yang sangat digunakan: KeRaiseIrqlToDpcLevel() mengembalikan IRQL sebelumnya dan meninggalkan anda di DISPATCH_LEVEL. Penting: Jangan sekali-kali menurunkan IRQL di bawah nilai semasa sistem memanggil anda; melanggar penyegerakan itu boleh membuka tingkap perlumbaan yang sangat serius.

Ralat skrin biru berkaitan IRQL: IRQL_NOT_LESS_OR_EQUAL dan DRIVER_IRQL_NOT_LESS_OR_EQUAL

Dua semakan pepijat klasik yang dikaitkan dengan isu ini ialah IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Kedua-duanya menunjukkan percubaan untuk mengakses alamat boleh halaman (atau tidak sah) pada IRQL yang terlalu tinggi. Ini biasanya disebabkan oleh pemandu yang menggunakan alamat yang salah, membatalkan rujukan yang tidak baik atau melaksanakan kod boleh halaman pada tahap yang tidak sesuai.

Dalam kes tertentu DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parameternya sangat bermaklumat: 1) alamat memori yang dirujuk; 2) IRQL pada masa itu; 3) jenis akses (0 baca, 1 tulis, 2/8 laksana); 4) alamat arahan yang merujuk memori. Dengan penyahpepijat yang anda boleh gunakan ln pada parameter 4 untuk senaraikan simbol terdekat dan ketahui fungsi yang sedang dijalankan.

Sebab biasa perlu diingat

Di sebalik kod tertentu, terdapat corak yang diulang. Menyahrujuk penuding tidak sah kepada DISPATCH_LEVEL atau lebih tinggi Ini adalah resipi yang pasti untuk bencana. Mengakses data boleh halaman pada tahap itu, atau melaksanakan kod boleh halaman (cth., fungsi yang ditandakan sebagai boleh halaman), juga mencetuskan semakan pepijat.

Kes biasa lain termasuk panggil fungsi dalam pemacu lain yang telah dimuat turun (penunjuk fungsi berjuntai), atau dipanggil secara tidak langsung melalui penuding fungsi yang tidak sah. Selalunya, jika sistem dapat mengenal pasti modul, anda akan melihat namanya pada skrin biru itu sendiri, dan ia juga disimpan dalam KiBugCheckDriver, boleh diakses dengan dx KiBugCheckDriver daripada WinDbg.

Butiran praktikal: Dalam kebanyakan D1/A, masalah sebenar bukanlah IRQL itu sendiri, tetapi sebaliknya alamat memori yang dirujuk. Itulah sebabnya parameter 1, 3, dan 4 adalah penting untuk memfokuskan diagnosis.

Diagnostik dengan WinDbg: Perintah berguna dan bacaan parameter

Untuk menangani kes-kes ini, WinDbg ialah alat utama, dan jika BSOD menyebut ntoskrnl.exe Maklumat ini memberikan banyak panduan sama ada kesalahan itu berada dalam subsistem kernel. Mulakan dengan !analyze -v untuk mendapatkan ringkasan semakan pepijat, timbunan dan, jika anda bernasib baik, modul yang terlibat. Jika tempat pembuangan itu termasuk bingkai tangkapan, .trap meletakkan anda dalam konteks CPU yang gagal.

The arahan daripada longgokan sebagai k, kb, kc, kd, kp, kP, kv Mereka menunjukkan kepada anda tahap perincian jejak belakang yang berbeza. Dengan ln pada parameter 4 anda boleh langkau kepada arahan yang merujuk ingatan dan dapatkan simbol berdekatan. Dan jika anda mengesyaki tahap keutamaan berjalan sebelum gangguan, !irql menunjukkan kepada anda IRQL yang disimpan untuk pemproses sasaran (mis. DISPATCH_LEVEL).

Untuk menganalisis arah parameter 1, !pool Ia akan memberitahu anda jika ia tergolong dalam kolam halaman; !address y !pte mendalami pemetaan ingatan kawasan itu. Anda boleh gunakan arahan paparan memori untuk memeriksa kandungan yang cuba diakses. Akhirnya, u, ub, uu membolehkan anda membuka sekitar alamat parameter 4.

Jangan lupa lm t n untuk menyenaraikan modul yang dimuatkan y !memusage untuk keadaan umum ingatan. Jika KiBugCheckDriver mempunyai sesuatu, dx KiBugCheckDriver Ia akan mengembalikan nama modul Unicode: dalam contoh biasa, "Wdf01000.sys" dilihat sebagai pemandu yang terlibat semasa pemeriksaan pepijat.

Alat Sistem: Pengesah Pemandu, Pemapar Acara dan Diagnostik

El Pengesah Pemandu Memeriksa tingkah laku pemandu dalam masa nyata dan memaksa ralat apabila ia mengesan penggunaan sumber yang salah (seperti kumpulan), menimbulkan pengecualian untuk mengasingkan kawasan bermasalah kod. Ia dilancarkan dengan verifier daripada arahan segera dan adalah dinasihatkan untuk memilih set pemandu terkecil yang mungkin untuk mengelakkan penambahan overhed terlalu banyak.

Jika anda tidak melihat diri anda dengan WinDbg, menggunakan langkah-langkah asas: Semak log sistem dalam Pemapar Peristiwa untuk melihat ralat yang menunjuk ke peranti/pemandu tertentu; kemas kini atau lumpuhkan pemandu yang dipetik oleh skrin biru; sahkan keserasian perkakasan dengan versi Windows anda; dan gunakan Windows Memory Diagnostic jika anda mengesyaki RAM. Tindakan ini, walaupun mudah, mereka menyelesaikan sejumlah besar kes.

Kes kehidupan sebenar: Apabila BSOD kelihatan rawak

Pengguna dengan Windows 10 Pro (CPU AMD Ryzen 5 3400G, GPU NVIDIA Papan GeForce GTX 1660 Ti dan Gigabyte B450 AORUS PRO WIFI, 16 GB RAM) mengalami skrin "IRQL_LESS_OR_NOT_EQUAL" sekejap-sekejap. Saya telah mengemas kini pemacu penting (rangkaian, grafik), memasang semua kemas kini Windows, dan menjalankan alat memori, semuanya tanpa mengesan sebarang masalah.

Dalam senario seperti ini, Langkah seterusnya ialah menganalisis pembuangan dengan WinDbg dan cari corak: proses yang terlibat apabila ia jatuh (contohnya, explorer.exe), modul antara muka grafik (win32kfull.sys) dan fungsi seperti xxxProcessNotifyWinEvent muncul dalam timbunan. Walaupun modul ini ialah Windows, pencetus selalunya adalah pemacu pihak ketiga (grafik, input, tindanan, kad tangkapan) yang menggunakan memori pada IRQL yang tidak sesuai dan kesalahan timbul dalam win32k.

Cadangan praktikal di sini ialah lumpuhkan perisian tindanan buat sementara waktu (capture, GPU OSD), pemacu persisian perisian yang agresif (tikus/papan kekunci dengan makro) dan versi beta pemacu grafik, dan sempitkannya. Menggunakan Pengesah Pemandu pada suspek boleh membantu mengurangkan masalah dengan susunan yang lebih jelas.

Corak rangkaian yang sangat biasa: ndis.sys tidak selalu menjadi punca

Satu lagi kes biasa: tangkapan skrin dengan ndis.sys (lapisan rangkaian Windows). Pada komputer sebenar, sistem akan ranap serta-merta apabila dimulakan. Penyelesaian praktikal adalah untuk boot masuk Mod selamat tanpa fungsi rangkaian, buka Pengurus Peranti dan lumpuhkan penyesuai di bawah "Penyesuai Rangkaian" untuk mengasingkan masalah.

Dalam pasukan itu terdapat seorang Pengawal Keluarga Realtek PCIe GBE dan Atheros AR5007G. Dengan menyahaktifkan kedua-duanya, ia telah dikesan bahawa punca sebenar adalah athrx.sys (Atheros), walaupun skrin biru menyebut ndis.sysLonggokan mengesahkan ini: timbunan melepasi ndis!NdisFreeTimerObject tetapi modul yang bersalah adalah athrx.sysPembetulan terakhir ialah nyahpasang peranti dan pasang pemacu rasmi yang dikemas kini Dari laman web pengeluar Atheros. Moral: Modul yang disebut dalam BSOD mungkin sebahagian daripada subsistem yang terjejas, bukan sumbernya.

Sambutan sokongan biasa dan langkah pantas untuk pengguna

Dalam pertukaran sokongan yang tulen, seorang juruteknik menjawab: "Saya memohon maaf atas kesulitan ini. Ia mungkin isu pemacu, memori atau antivirus. Sila kemas kini pemacu anda dan, jika ia berterusan, jalankan diagnostik memori."Ini adalah nasihat asas tetapi sah; namun, jika ralat berterusan, adalah idea yang baik untuk pergi lebih jauh dengan Pengesah dan analisis pembuangan.

Bagi pengguna bukan teknikal, protokol yang munasabah ialah: 1) Semak peristiwa sistem, 2) Kemas kini pemacu utama (cipset/rangkaian/grafik), 3) Semak RAM dengan alat bersepadu, 4) ujian boot bersih tanpa perisian pihak ketiga yang memasukkan cangkuk ke dalam kernel/GUI, dan 5) menggunakan Verifier pada pemacu pihak ketiga jika tiada apa yang jelas.

Amalan terbaik untuk pembangun pemandu

Jika anda sedang membangun dan anda terjumpa D1/A, periksa bahawa rutin berjalan tidak ditandakan sebagai boleh halaman Jangan panggil fungsi boleh halaman semasa berjalan di DISPATCH_LEVEL atau lebih tinggi. Ini termasuk mengelakkan rujukan kepada data dalam bahagian halaman dan menghormati sekatan IRQL untuk pembantu kernel yang diterangkan dalam DDK.

Untuk menyegerakkan data yang dikongsi, gunakan peraturan "sentiasa mengakses data kongsi pada IRQL tinggi yang sama" dan gunakan kunci putaran apabila sesuai. Pada multipemproses, IRQL sahaja tidak menjamin pengecualian antara CPU yang berbeza; kunci putaran menaikkan IRQL (kepada DISPATCH_LEVEL) dan menyelaraskan akses antara teras. Jika anda perlu mengendalikan daftar perkakasan yang sensitif, KeSynchronizeExecution membantu anda melaksanakan bahagian kritikal pada DIRQL yang betul.

Apabila rancangan memerlukan peningkatan IRQL, kegunaan KeRaiseIrqlToDpcLevel untuk DISPATCH_LEVEL atau KeRaiseIrql dengan berhati-hati, menyimpan IRQL sebelumnya dan memulihkannya dengan tepat KeLowerIrql. Pergi ke bawah input IRQL, walaupun untuk seketika, Ia adalah ralat penyegerakan yang serius.

Hubungan dengan gangguan dan perkakasan

IRQL ialah mekanisme yang digunakan oleh Windows perintah mengganggu keutamaan dan tugas dalaman tertentuPada peringkat seni bina, ia berkaitan dengan konsep seperti "Sampuk", "Pengendali sampuk" atau "Tahap keutamaan sampuk" dan, pada platform klasik, dengan Pengawal Gangguan Boleh Aturcara (PIC)Dalam sistem lain, kawalan keutamaan dinyatakan melalui mekanisme seperti spl en Unix; idea umum adalah sama: siapa yang boleh mengganggu siapa.

Petua Penyahpepijatan Lanjutan

Di tempat pembuangan tempat timbunan menghala ke win32kfull!xxxProcessNotifyWinEvent dengan semak pepijat 0xA/0xD1, periksa konteks dengan .process y .thread (jika ada), lihat proses seperti explorer.exe en !process 0 1 dan semak tindanan dan pemacu interaksi GUI. Banyak kali masalah Ia adalah memori yang rosak oleh pihak ketiga yang muncul di laluan itu.

Jangan lupa untuk menyemak IRQL dengan !irql, dan kontras: jika anda berada di DISPATCH_LEVEL (2) dan parameter 3 menunjukkan baca/tulis/laksana pada halaman yang boleh dimuka surat, anda sudah mempunyai petunjuk mengapa ia telah jatuh. Silangkan petunjuk itu dengan ln dalam parameter 4 untuk mendapatkan fungsi tertentu.

Memahami Apakah IRQL itu? dan cara ia sesuai dengan pelaksanaan kernel membantu memisahkan bunyi daripada isyarat. Jika anda seorang pengguna, fokus pada pemacu dan perkakasan (dengan Pengesah, acara dan ujian secara lalai). Jika anda membangunkan, ikuti peraturan untuk IRQL, memori bukan halaman dan penyegerakan dengan kunci putaran dengan ketat. Dengan alat yang betul (WinDbg, Verifier) ​​​​dan pembacaan parameter yang teliti (1, 3, dan 4), Pemeriksaan pepijat ini bukan lagi misteri dan ia menjadi masalah yang boleh ditangani secara berkaedah.