Ano ang IRQL (Interrupt Request Level) sa Windows at paano ito nauugnay sa mga BSOD?

Kung nakakita ka na ng asul na screen na may mga mensahe tulad ng IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, malamang na nakatagpo ka ng isang konsepto na hindi gaanong kilala sa labas ng mundo ng mga driver: ang IRQL (Interrupt Request Level). Sa Windows, ang antas na ito ng interrupt na priyoridad ay nangunguna kaysa sa thread priority kapag ang system ay lampas sa isang tiyak na threshold, at ito ay may direktang mga kahihinatnan sa katatagan.

Sa mga susunod na linya ay makikita mo isang kumpletong gabay at sa Espanyol mula sa Espanya tungkol sa kung ano ang IRQL, kung paano ito gumagana, kung bakit ito nagti-trigger ng mga asul na screen, kung paano i-diagnose ang problema sa WinDbg, at kung ano ang gagawin kung ikaw ay isang user na nakakaranas ng error o pagbuo ng mga driver ng kernel-mode. Bumaba tayo sa negosyo.

Ano ang IRQL (Interrupt Request Level) sa Windows?

Sa Windows, ang Tinutukoy ng IRQL ang priyoridad ng hardware kung saan gumagana ang isang processor sa anumang oras. Sa loob ng Windows Driver Model (WDM), ang code na tumatakbo sa mababang IRQL ay maaaring maputol ng code na tumatakbo sa mas mataas na IRQL. Sa katunayan, sa isang solong multi-core na computer, ang bawat CPU ay maaaring nasa ibang IRQL, na nagpapahirap sa pag-synchronize.

Mayroong isang pangunahing panuntunan: Kapag ang isang CPU ay tumatakbo sa isang IRQL sa itaas ng PASSIVE_LEVEL, maaari lamang itong ma-preempted ng aktibidad sa mas mataas na IRQL.Inaayos nito ang magkakasamang buhay sa pagitan ng user code, mga kernel function, deferred caller (DPC), at device interrupt service routines (ISRs).

Mga antas at priyoridad: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL at DIRQL

Sa pangkalahatan, Sa x86, ginagamit ang mga halaga ng IRQL sa pagitan ng 0 at 31; sa x64, sa pagitan ng 0 at 15Ang praktikal na kahulugan ay pareho: IRQL 0 (PASSIVE_LEVEL) ay kung saan ang normal na user code at maraming mga function ng driver ay isinasagawa; APC at page faults Sila ay karaniwang nakamapa sa IRQL 1 (APC_LEVEL); Ang IRQL 2 (DISPATCH_LEVEL) ay sumasaklaw sa scheduler ng thread at mga DPC. Sa itaas ng DISPATCH_LEVEL ay mga antas na nakalaan para sa mga pagkaantala ng device (kilala bilang DIRQL) at iba pang panloob na paggamit gaya ng HIGH_LEVEL.

Sa driver ecosystem, Maraming karaniwang gawain ang tumatakbo sa DISPATCH_LEVEL: halimbawa, DPC at StartIo. Tinitiyak ng disenyong ito na habang ang isa sa mga ito ay humahawak sa mga panloob na pila o iba pang ibinahaging mapagkukunan, ang isa pang routine sa parehong antas ay hindi nangunguna sa CPU na iyon, dahil pinapayagan lamang ng panuntunan sa pag-iingat ang mga pagkaantala sa mas matataas na antas.

Sa pagitan ng DISPATCH_LEVEL at ang profiling/matataas na antas ay may puwang para sa hardware interrupts ng bawat device (DIRQL)Tinutukoy ng IRQL ng isang device ang priyoridad nito kaysa sa iba pang mga device. Nakukuha ng driver ng WDM ang IRQL na ito sa panahon ng IRP_MJ_PNP gamit ang IRP_MN_START_DEVICE. Ang IRQL ng device na ito ay hindi isang pandaigdigang, nakapirming halaga, ngunit sa halip ay ang halaga na nauugnay sa isang partikular na linya ng interrupt.

IRQL vs. Thread Priority

Maipapayo na huwag malito ang mga konsepto: Ang priyoridad ng thread ay nagpapasya kung kailan ang scheduler ay nag-preempt at kung aling thread ang ipapatupad; kinokontrol ng IRQL kung anong uri ng aktibidad ang maaaring isagawa at kung aling mga interrupt ang naka-mask. Sa itaas ng DISPATCH_LEVEL, walang thread switching: ang IRQL ang kumokontrol, hindi ang thread priority.

IRQL at Paging: Ano ang Hindi Mo Dapat Gawin

Ang isang agarang epekto ng pagtaas ng IRQL ay ang sistema hindi makayanan ang mga page fault. Golden rule: ang code na tumatakbo sa DISPATCH_LEVEL o mas mataas ay hindi maaaring maging sanhi ng mga page fault. Sa pagsasagawa, nangangahulugan ito na ang mga nakagawiang iyon at ang data na kanilang hinawakan dapat manatili sa hindi paged na memorya. Bilang karagdagan, ang ilang mga kernel helper ay naghihigpit sa kanilang paggamit batay sa IRQL: halimbawa, KeWaitForSingleObject Matatawag lang ang DISPATCH_LEVEL kung hindi ka nagba-block (zero timeout), at para sa mga non-zero timeout, kailangan mong mas mababa sa DISPATCH_LEVEL.

Implicit at tahasang kontrol ng IRQL

Kadalasan, ang system mismo ay humihiling ng iyong mga gawain sa tamang IRQL para sa dapat nilang gawin. Ang mga gawain sa pagpapadala para sa mga IRP ay tumatakbo sa PASSIVE_LEVEL (maaari nilang i-block o tawagan ang sinumang katulong), ang StartIo at DPC ay tumatakbo sa DISPATCH_LEVEL upang protektahan ang mga nakabahaging pila, at ang mga ISR ay tumatakbo sa DIRQL.

Kung kailangan mong kontrolin ito nang tahasan, Maaari mong taasan at babaan ang IRQL gamit ang KeRaiseIrql y KeLowerIrqlMayroong isang napaka-ginagamit na shortcut: KeRaiseIrqlToDpcLevel() ibinabalik ang dating IRQL at iniiwan ka sa DISPATCH_LEVEL. Mahalaga: Huwag kailanman ibababa ang IRQL sa halaga nito noong tinawag ka ng system; Ang pagsira sa pag-synchronize na iyon ay maaaring magbukas ng napakaseryosong mga window ng karera.

Mga error sa asul na screen na nauugnay sa IRQL: IRQL_NOT_LESS_OR_EQUAL at DRIVER_IRQL_NOT_LESS_OR_EQUAL

Dalawang klasikong pagsusuri sa bug na nauugnay sa mga isyung ito ay IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Parehong nagpapahiwatig ng pagtatangkang i-access ang isang pageable (o di-wasto) na address sa isang IRQL na masyadong mataas. Ito ay kadalasang dahil sa mga driver na gumagamit ng mga maling address, hindi nagre-refer ng mga masasamang pointer, o nagsasagawa ng pageable na code sa hindi naaangkop na antas.

Sa tukoy na kaso ng DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), ang mga parameter ay napaka-kaalaman: 1) isinangguni na memorya ng address; 2) IRQL sa oras na iyon; 3) uri ng pag-access (0 read, 1 write, 2/8 execute); 4) address ng pagtuturo na sumangguni sa memorya. Gamit ang debugger maaari mong gamitin ln sa parameter 4 para sa ilista ang pinakamalapit na simbolo at alamin kung anong function ang tumatakbo.

Mga karaniwang dahilan na dapat tandaan

Higit pa sa partikular na code, may mga pattern na paulit-ulit. Ang pagde-refer ng isang di-wastong pointer sa DISPATCH_LEVEL o mas mataas Ito ay isang tiyak na recipe para sa kalamidad. Ang pag-access sa pageable na data sa antas na iyon, o pag-execute ng pageable na code (hal., isang function na minarkahan bilang pageable), ay nagti-trigger din ng pagsusuri sa bug.

Kasama sa iba pang karaniwang mga kaso tumawag ng function sa ibang driver na na-download na (nakalawit na function pointer), o hindi direktang na-invoke sa pamamagitan ng di-wastong function pointer. Kadalasan, kung matukoy ng system ang isang module, makikita mo ang pangalan nito sa mismong asul na screen, at naka-save din ito sa KiBugCheckDriver, naa-access sa dx KiBugCheckDriver mula sa WinDbg.

Isang praktikal na detalye: Sa karamihan ng D1/A, ang tunay na problema ay hindi ang IRQL mismo, ngunit sa halip ang tinutukoy na memorya ng address. Iyon ang dahilan kung bakit ang mga parameter 1, 3, at 4 ay mahalaga para sa pagtuon sa diagnosis.

Diagnostics sa WinDbg: Mga kapaki-pakinabang na command at pagbabasa ng parameter

Upang magtrabaho sa mga kasong ito, Ang WinDbg ay ang pangunahing tool, at kung binanggit ng BSOD ntoskrnl.exe Ang impormasyong ito ay nagbibigay ng maraming gabay kung ang kasalanan ay nasa kernel subsystem. Magsimula sa pamamagitan ng !analyze -v upang makakuha ng buod ng pagsusuri sa bug, ang stack, at, kung ikaw ay mapalad, ang module na kasangkot. Kung ang dump ay may kasamang capture frame, .trap inilalagay ka sa konteksto ng nabigong CPU.

Los comandos ng pile bilang k, kb, kc, kd, kp, kP, kv Nagpapakita sila sa iyo ng iba't ibang antas ng detalye ng backtrace. Sa ln sa parameter 4 maaari mong laktawan sa pagtuturo na tumutukoy sa memorya at kunin ang kalapit na simbolo. At kung pinaghihinalaan mo ang antas ng priyoridad na tumatakbo bago ang interrupt, !irql ipinapakita sa iyo ang naka-save na IRQL para sa target na processor (hal. DISPATCH_LEVEL).

Upang pag-aralan ang direksyon ng parameter 1, !pool Sasabihin nito sa iyo kung kabilang ito sa isang paged pool; !address y !pte bungkalin ang memory mapping ng lugar na iyon. Maaari mong gamitin ang mga utos ng memory display upang siyasatin ang nilalaman na sinubukang ma-access. Sa wakas, u, ub, uu nagpapahintulot sa iyo na i-disassemble sa paligid ng address ng parameter 4.

Huwag kalimutan lm t n upang ilista ang mga na-load na module y !memusage para sa pangkalahatang estado ng memorya. Kung KiBugCheckDriver may isang bagay, dx KiBugCheckDriver Ibabalik nito ang pangalan ng Unicode module: sa isang tipikal na halimbawa, ang "Wdf01000.sys" ay nakita bilang driver na kasangkot sa pagsusuri ng bug.

Mga Tool ng System: Driver Verifier, Event Viewer at Diagnostics

El Tagapag-verify ng Driver Sinusuri ang pag-uugali ng mga driver sa real time at pinipilit ang mga error kapag nakita nito ang hindi tamang paggamit ng mapagkukunan (tulad ng pool), na nagtataas ng isang pagbubukod upang ihiwalay ang problemang bahagi ng code. Ito ay inilunsad kasama ang verifier mula sa command prompt at ipinapayong piliin ang pinakamaliit na hanay ng mga driver na posible upang maiwasan ang pagdaragdag ng masyadong maraming overhead.

Kung hindi mo nakikita ang iyong sarili sa WinDbg, ilapat ang mga pangunahing hakbang: Suriin ang log ng system sa Event Viewer para sa mga error na tumuturo sa isang partikular na device/driver; i-update o huwag paganahin ang driver na binanggit ng asul na screen; i-verify ang pagiging tugma ng hardware sa iyong bersyon ng Windows; at gamitin ang Windows Memory Diagnostic kung pinaghihinalaan mo ang RAM. Ang mga pagkilos na ito, bagaman simple, malutas nila ang isang malaking bilang ng mga kaso.

Mga kaso sa totoong buhay: Kapag ang mga BSOD ay tila random

Isang user na may Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti at Gigabyte B450 AORUS PRO WIFI board, 16 GB ng RAM) ay nakakaranas ng pasulput-sulpot na "IRQL_LESS_OR_NOT_EQUAL" na mga screen. Na-update ko na ang mga mahahalagang driver (network, graphics), na-install ang lahat ng mga update sa Windows, at pinatakbo ang memory tool, lahat nang walang nakitang anumang problema.

Sa mga ganitong senaryo, Ang susunod na hakbang ay pag-aralan ang mga dump gamit ang WinDbg at maghanap ng mga pattern: mga prosesong kasangkot kapag nahulog ito (halimbawa, explorer.exe), mga graphical na interface module (win32kfull.sys) at mga function tulad ng xxxProcessNotifyWinEvent lumilitaw sa stack. Bagama't ang module na ito ay Windows, ang trigger ay kadalasang isang third-party na driver (graphics, input, overlay, capture card) na gumagamit ng memory sa isang hindi naaangkop na IRQL at ang pagkakamali ay lumitaw sa loob win32k.

Ang praktikal na rekomendasyon dito ay pansamantalang huwag paganahin ang overlay na software (capture, GPU OSD), mga agresibong software na peripheral driver (mga mouse/keyboard na may mga macro), at beta na bersyon ng mga graphics driver, at paliitin ito. Ang paggamit ng Driver Verifier sa mga pinaghihinalaan ay maaaring makatulong na paliitin ang problema sa isang mas malinaw na stack.

Isang napakakaraniwang pattern ng network: hindi palaging ang ndis.sys ang may kasalanan

Isa pang tipikal na kaso: screenshot gamit ang ndis.sys (ang layer ng network ng Windows). Sa isang tunay na computer, ang system ay mag-crash kaagad sa pagsisimula. Ang praktikal na solusyon ay mag-boot sa Ligtas na mode nang walang mga function ng network, buksan ang Device Manager at huwag paganahin ang mga adaptor sa ilalim ng "Mga Network Adapter" upang ihiwalay ang problema.

Sa pangkat na iyon ay mayroong isang Realtek PCIe GBE Family Controller at isang Atheros AR5007G. Sa pamamagitan ng pag-deactivate sa pareho, natukoy na ang tunay na dahilan ay ang athrx.sys (Atheros), bagaman nabanggit ang asul na screen ndis.sysKinumpirma ito ng dump: dumaan ang stack ndis!NdisFreeTimerObject ngunit ang may kasalanan na module ay athrx.sysAng huling pagwawasto ay i-uninstall ang device at i-install ang na-update na opisyal na mga driver Mula sa website ng tagagawa ng Atheros. Moral: Ang module na binanggit sa BSOD ay maaaring bahagi ng apektadong subsystem, hindi ang pinagmulan.

Karaniwang tugon sa suporta at mabilis na hakbang para sa mga user

Sa isang tunay na palitan ng suporta, tumugon ang isang technician: "Paumanhin para sa abala. Maaaring ito ay isang isyu sa driver, memorya, o antivirus. Paki-update ang iyong mga driver at, kung magpapatuloy ito, patakbuhin ang memory diagnostic."Ito ay pangunahing ngunit wastong payo; gayunpaman, kung magpapatuloy ang mga error, magandang ideya na magpatuloy pa sa pagsusuri ng Verifier at dump.

Para sa mga hindi teknikal na gumagamit, ang isang makatwirang protocol ay: 1) Suriin ang mga kaganapan sa system, 2) I-update ang mga pangunahing driver (chipset/network/graphics), 3) Suriin ang RAM gamit ang pinagsamang tool, 4) pagsubok boot malinis nang walang third-party na software na naglalagay ng mga hook sa kernel/GUI, at 5) gumamit ng Verifier sa mga third-party na driver kung walang malinaw.

Pinakamahuhusay na kagawian para sa mga developer ng driver

Kung ikaw ay umuunlad at natitisod ka sa D1/A, suriin na ang ang running routine ay hindi minarkahan bilang pageable Huwag tumawag sa mga pageable function habang tumatakbo sa DISPATCH_LEVEL o mas mataas. Kabilang dito ang pag-iwas sa mga reference sa data sa paged na mga seksyon at paggalang sa mga paghihigpit sa IRQL para sa mga kernel helper na inilarawan sa DDK.

Upang i-synchronize ang nakabahaging data, ilapat ang panuntunang "palaging i-access ang nakabahaging data sa parehong mataas na IRQL" at gumamit ng mga spin lock kung naaangkop. Sa mga multiprocessor, ang IRQL lamang ay hindi ginagarantiyahan ang pagbubukod sa pagitan ng iba't ibang mga CPU; ang mga spin lock ay nagtataas ng IRQL (sa DISPATCH_LEVEL) at nag-coordinate ng access sa pagitan ng mga core. Kung kailangan mong magpatakbo sa mga sensitibong rehistro ng hardware, KeSynchronizeExecution tumutulong sa iyo na magsagawa ng mga kritikal na seksyon sa tamang DIRQL.

Kapag ang plano ay nangangailangan ng pagtaas ng IRQL, Estados Unidos KeRaiseIrqlToDpcLevel para sa DISPATCH_LEVEL o KeRaiseIrql maingat, i-save ang nakaraang IRQL at i-restore ito nang eksakto sa KeLowerIrql. Pumunta sa ibaba ng input IRQL, kahit sa isang iglap, Ito ay isang malubhang error sa pag-synchronize.

Relasyon sa mga pagkagambala at hardware

Ang IRQL ay ang mekanismo kung saan ang Windows ang mga order ay nakakagambala sa mga priyoridad at ilang mga panloob na gawainSa antas ng arkitektura, nauugnay ito sa mga konsepto tulad ng "Interrupt", "Interrupt handler" o "Interrupt priority level" at, sa mga klasikong platform, na may Programmable Interrupt Controller (PIC)Sa ibang mga sistema, ang kontrol ng priyoridad ay ipinahayag sa pamamagitan ng mga mekanismo tulad ng spl en Unix; ang pangkalahatang ideya ay pareho: sino ang maaaring makagambala kung kanino.

Advanced na Mga Tip sa Pag-debug

Sa mga tambakan kung saan nakaturo ang stack win32kfull!xxxProcessNotifyWinEvent na may bug check 0xA/0xD1, siyasatin ang konteksto gamit ang .process y .thread (kung magagamit), tingnan ang mga proseso tulad ng explorer.exe en !process 0 1 at suriin ang mga overlay at mga driver ng pakikipag-ugnayan ng GUI. Maraming beses ang problema Ito ay memorya na nasira ng isang third party na lumalabas sa rutang iyon.

Huwag kalimutang suriin ang IRQL gamit ang !irql, at kaibahan: kung ikaw ay nasa DISPATCH_LEVEL (2) at ang parameter 3 ay nagpapahiwatig ng read/write/execute sa isang paginable page, mayroon ka nang clue kung bakit ito nahulog. I-cross ang clue na iyon ln sa parameter 4 upang makuha ang tiyak na function.

maunawaan Ano ang IRQL? at kung paano ito umaangkop sa kernel execution ay nakakatulong sa paghiwalay ng ingay sa mga signal. Kung ikaw ay isang user, tumutok sa mga driver at hardware (na may Verifier, mga kaganapan, at mga pagsubok bilang default). Kung bubuo ka, mahigpit na sundin ang mga panuntunan para sa IRQL, hindi paged na memorya, at pag-synchronize sa mga spin lock. Gamit ang mga tamang tool (WinDbg, Verifier) ​​​​at maingat na pagbabasa ng mga parameter (1, 3, at 4), Ang mga pagsusuri sa bug na ito ay hindi na isang misteryo at sila ay nagiging mga problema na maaaring matugunan nang may pamamaraan.