Kas yra IRQL (pertraukimo užklausos lygis) sistemoje „Windows“ ir kaip jis susijęs su BSOD?

Jei kada nors matėte mėlyną ekraną su tokiais pranešimais kaip IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUALtikriausiai esate susidūrę su sąvoka, kuri už tvarkyklių pasaulio ribų yra mažai žinoma: IRQL (pertraukimo užklausos lygis). Windows, šis pertraukimo prioriteto lygis turi pirmenybę prieš gijos prioritetą, kai sistema viršija tam tikrą ribą, ir tai turi tiesioginių pasekmių stabilumui.

Kitose eilutėse rasite un,es pilnas vadovas ir ispanų kalba iš Ispanijos apie tai, kas yra IRQL ir kaip jis veikia, kodėl tai sukelia mėlynus ekranus, kaip diagnozuoti „WinDbg“ problemą ir ką daryti, jei esate vartotojas, patiriantis klaidą, arba kuriate branduolio režimo tvarkykles. Pradėkime nuo reikalo.

Kas yra IRQL (pertraukimo užklausos lygis) sistemoje „Windows“?

„Windows“ sistemoje IRQL apibrėžia prioritetą techninė įranga kuriame veikia procesorius bet kuriuo metu. „Windows“ tvarkyklių modelyje (WDM) kodą, veikiantį esant žemam IRQL, gali nutraukti kodas, veikiantis esant aukštesniam IRQL. Tiesą sakant, viename daugiabranduoliame kompiuteryje kiekvienas procesorius gali veikti skirtingu IRQL, o tai apsunkina sinchronizavimą.

Yra viena pagrindinė taisyklė: Kai procesoriaus IRQL lygis yra aukštesnis nei PASSIVE_LEVEL, jį gali užgožti tik aktyvumas esant dar aukštesniam IRQL lygiui.Tai organizuoja vartotojo kodo, branduolio funkcijų, atidėtųjų iškvietimų (DPC) ir įrenginių pertraukimų aptarnavimo procedūrų (ISR) sambūvį.

Lygiai ir prioritetai: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL ir DIRQL

Apskritai, „x86“ naudojamos IRQL reikšmės nuo 0 iki 31; „x64“ – nuo ​​0 iki 15.Praktinė reikšmė ta pati: IRQL 0 (PASSIVE_LEVEL) yra vieta, kur vykdomas įprastas vartotojo kodas ir daugelis tvarkyklės funkcijų; APC ir puslapio klaidos Paprastai jie susiejami su IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) apima gijų planuoklį ir DPC. Virš DISPATCH_LEVEL yra lygiai, rezervuoti įrenginio pertraukimams (žinomi kaip DIRQL) ir kitiems vidiniams tikslams, pvz., HIGH_LEVEL.

Vairuotojų ekosistemoje Daugelis įprastų procedūrų vykdomos DISPATCH_LEVEL lygyjepavyzdžiui, DPC ir StartIo. Ši konstrukcija užtikrina, kad nors vienas iš jų liečia vidines eiles ar kitus bendrinamus išteklius, kita to paties lygio rutina jo neriboja tame pačiame procesoriuje, nes pertraukimų prevencijos taisyklė leidžia tik aukštesnius lygius.

Tarp DISPATCH_LEVEL ir profiliavimo / aukštų lygių yra vietos kiekvieno įrenginio aparatinės įrangos pertraukimai (DIRQL)Įrenginio IRQL apibrėžia jo prioritetą kitų įrenginių atžvilgiu. WDM tvarkyklė gauna šį IRQL IRP_MJ_PNP metu su IRP_MN_START_DEVICE. Šis įrenginio IRQL nėra globali, fiksuota reikšmė, o reikšmė, susieta su konkrečia pertraukimo linija.

IRQL ir gijų prioritetas

Patartina nepainioti sąvokų: Gijos prioritetas nusprendžia, kada planuoklė atlieka išankstinius veiksmus ir kuri gija vykdoma; IRQL kontroliuoja, kokio tipo veikla gali būti vykdoma ir kurie pertraukimai yra užmaskuoti. Virš DISPATCH_LEVEL nėra gijų perjungimo: valdo IRQL, o ne gijos prioritetą.

IRQL ir puslapiavimas: ko neturėtumėte daryti

Tiesioginis IRQL didinimo poveikis yra tas, kad sistema negali apdoroti puslapio klaidųAuksinė taisyklė: kodas, veikiantis ties DISPATCH_LEVEL arba aukštesniu lygiu, negali sukelti puslapio klaidų. Praktiškai tai reiškia, kad tos rutinos ir duomenys, su kuriais jos liečiasi turi būti nepuslapinėje atmintyjeBe to, tam tikri branduolio pagalbininkai riboja savo naudojimą pagal IRQL: pavyzdžiui, KeWaitForSingleObject DISPATCH_LEVEL galima iškviesti tik tuo atveju, jei neblokuojate (skirtasis laikas nulinis), o jei skirtasis laikas nėra nulinis, turite būti žemiau DISPATCH_LEVEL.

Numanoma ir aiški IRQL kontrolė

Dažniausiai pati sistema iškviečia jūsų rutinas teisingu IRQL ką jie turėtų daryti. IRP siuntimo rutinos veikia PASSIVE_LEVEL (jie gali blokuoti arba iškviesti bet kurį pagalbininką), StartIo ir DPC veikia DISPATCH_LEVEL, kad apsaugotų bendras eiles, o ISR veikia DIRQL.

Jei reikia aiškiai kontroliuoti, Galite padidinti ir sumažinti IRQL naudodami KeRaiseIrql y KeLowerIrqlYra labai dažnai naudojamas trumpinys: KeRaiseIrqlToDpcLevel() grąžina ankstesnį IRQL ir palieka jus ties DISPATCH_LEVEL. Svarbu: Niekada nemažinkite IRQL žemiau vertės, kuri buvo, kai sistema jus iškvietė; sinchronizacijos nutraukimas gali atverti labai rimtus lenktynių langus.

Su IRQL susijusios mėlynojo ekrano klaidos: IRQL_NOT_LESS_OR_EQUAL ir DRIVER_IRQL_NOT_LESS_OR_EQUAL

Du klasikiniai su šiomis problemomis susiję klaidų patikrinimai yra šie: IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Abu šie kodai rodo bandymą pasiekti puslapiuojamą (arba negaliojantį) adresą, kurio IRQL yra per aukštas. Paprastai taip nutinka dėl to, kad tvarkyklės naudoja neteisingus adresus, pašalina blogas nuorodas arba puslapiuojamą kodą vykdo netinkamais lygiais.

Konkrečiu atveju DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parametrai yra labai informatyvūs: 1) nuorodos atminties adresas; 2) tuo metu galiojęs IRQL; 3) prieigos tipas (0 skaitymas, 1 rašymas, 2/8 vykdymas); 4) instrukcijos, kuri nurodė atmintį, adresas. Su derinimo įrankiu galite naudoti ln 4 parametro atveju išvardyti artimiausią simbolį ir žinoti, kokia funkcija buvo vykdoma.

Dažnos priežastys, į kurias reikia atkreipti dėmesį

Be konkretaus kodo, yra ir pasikartojančių šablonų. Neteisingo rodyklės išėmimas iš nuorodos į DISPATCH_LEVEL arba aukštesnį lygį Tai garantuotas katastrofos receptas. Prieiga prie puslapiuojamų duomenų tame lygmenyje arba puslapiuojamo kodo (pvz., funkcijos, pažymėtos kaip puslapiuojama) vykdymas taip pat suaktyvina klaidų tikrinimą.

Kiti dažni atvejai yra šie: iškvieskite funkciją kitoje, jau atsisiųstoje tvarkyklėje (kabanti funkcijos rodyklė) arba netiesiogiai iškviečiama per negaliojančią funkcijos rodyklę. Dažnai, jei sistema gali atpažinti modulį, jo pavadinimą matysite pačiame mėlyname ekrane, o jis taip pat išsaugomas KiBugCheckDriver, prieinama su dx KiBugCheckDriver iš „WinDbg“.

Praktinė detalė: Daugumoje D1/A tikroji problema yra ne pats IRQL., o veikiau nurodytą atminties adresą. Štai kodėl 1, 3 ir 4 parametrai yra labai svarbūs diagnozei nustatyti.

Diagnostika naudojant „WinDbg“: naudingos komandos ir parametrų skaitymas

Dirbti su šiais atvejais, „WinDbg“ yra pagrindinė priemonė, ir jei BSOD mini Ntoskrnl.exe Ši informacija suteikia daug informacijos apie tai, ar gedimas yra branduolio posistemėje. Pradėkite nuo !analyze -v kad gautumėte klaidų patikrinimo, steko ir, jei pasiseks, susijusio modulio santrauką. Jei išklotinėje yra fiksavimo kadras, .trap jus pateikia sugedusio procesoriaus kontekste.

Los komandos krūvos kaip k, kb, kc, kd, kp, kP, kv Jie rodo skirtingus atgalinio sekimo detalumo lygius. Su ln 4 parametre galite praleisti į instrukciją, kuri nurodė atmintį ir gaukite netoliese esantį simbolį. Ir jei įtariate, kad prioriteto lygis veikia prieš pertraukimą, !irql rodo išsaugotą tikslinio procesoriaus IRQL (pvz., DISPATCH_LEVEL).

Norint išanalizuoti 1 parametro kryptį, !pool Tai jums pasakys, ar jis priklauso puslapiuojamam telkiniui; !address y !pte įsigilinkite į tos srities atminties žemėlapį. Galite naudoti atminties rodymo komandos kad būtų galima patikrinti turinį, prie kurio buvo bandyta prisijungti. Galiausiai, u, ub, uu leidžia išardyti aplink 4 parametro adresą.

Nepamirškite lm t n pateikti įkeltų modulių sąrašą y !memusage bendrai atminties būklei. Jei KiBugCheckDriver turi kažką, dx KiBugCheckDriver Grąžins Unicode modulio pavadinimą: tipiškame pavyzdyje „Wdf01000.sys“ buvo nurodyta kaip tvarkyklė, susijusi klaidos tikrinimo metu.

Sistemos įrankiai: tvarkyklės tikrintuvas, įvykių peržiūros programa ir diagnostika

El Vairuotojo tikrintuvas Realiuoju laiku tikrina tvarkyklių elgseną ir, aptikęs neteisingą išteklių (pvz., telkinio) naudojimą, sukelia klaidas, sukurdamas išimtį, kad išskirtų probleminę kodo sritį. Paleidžiama su verifier nuo komandinė eilutė ir patartina pasirinkti kuo mažesnį tvarkyklių rinkinį, kad būtų išvengta per didelių pridėtinių sąnaudų.

Jei nematai savęs su „WinDbg“, taikyti pagrindines priemonesPatikrinkite sistemos žurnalą įvykių peržiūros programoje, ar nėra klaidų, nukreipiančių į konkretų įrenginį / tvarkyklę; atnaujinkite arba išjunkite tvarkyklę, kurią nurodo mėlynas ekranas; patikrinkite aparatinės įrangos suderinamumą su jūsų „Windows“ versija; ir, jei įtariate RAM, naudokite „Windows“ atminties diagnostiką. Šie veiksmai, nors ir paprasti, jie išsprendžia daugybę bylų.

Realūs atvejai: kai BSOD atrodo atsitiktiniai

Vartotojas, turintis „Windows 10 Pro“ (AMD Ryzen 5 3400G procesorių, GPU "NVIDIA „GeForce GTX 1660 Ti“ ir „Gigabyte B450 AORUS PRO WIFI“ plokštė, 16 GB RAM) retkarčiais pasirodydavo ekranai „IRQL_LESS_OR_NOT_EQUAL“. Jau buvau atnaujinęs pagrindines tvarkykles (tinklo, grafikos), įdiegiau visus „Windows“ naujinimus ir paleidęs atminties įrankį, tačiau jokių problemų neaptikau.

Tokiais atvejais, Kitas žingsnis – išklotinių analizė naudojant „WinDbg“ ir ieškokite dėsningumų: procesų, vykstančių jam krentant (pavyzdžiui, explorer.exe), grafinės sąsajos moduliai (win32kfull.sys) ir tokias funkcijas kaip xxxProcessNotifyWinEvent rodomi steke. Nors šis modulis yra „Windows“, jį dažnai sukelia trečiosios šalies tvarkyklė (grafikos, įvesties, perdangos, vaizdo įrašymo plokštės), kuri naudoja atmintį netinkamu IRQL, ir gedimas atsiranda win32k.

Praktinė rekomendacija čia yra tokia laikinai išjungti perdengimo programinę įrangą (vaizdo fiksavimas, GPU OSD), agresyvios programinės įrangos periferinių įrenginių tvarkyklės (pelės / klaviatūros su makrokomandomis) ir grafikos tvarkyklių beta versijos, ir susiaurinkite paiešką. Įtartinų kompiuterinių tvarkyklių tvarkyklės tikrinimo priemonės naudojimas gali padėti susiaurinti problemą ir gauti aiškesnį vaizdą.

Labai dažnas tinklo modelis: ndis.sys ne visada yra kaltininkas

Kitas tipiškas atvejis: ekrano kopija su ndis.sys (Windows tinklo sluoksnis). Tikrame kompiuteryje sistema užstrigtų iš karto po paleidimo. Praktinis sprendimas buvo paleisti iš Saugus režimas be tinklo funkcijų, atidarykite Įrenginių tvarkytuvė ir išjunkite adapterius skiltyje „Tinklo adapteriai“, kad išskirtumėte problemą.

Toje komandoje buvo „Realtek PCIe GBE“ šeimos valdiklis ir „Atheros AR5007G“Išjungus abu, buvo nustatyta, kad tikroji priežastis buvo athrx.sys (Atheros), nors mėlynas ekranas buvo minėtas ndis.sysSąvartynas tai patvirtino: krūva praėjo ndis!NdisFreeTimerObject bet kaltas modulis buvo athrx.sysGalutinis pataisymas buvo pašalinkite įrenginį ir įdiekite atnaujintus oficialius tvarkykles Iš „Atheros“ gamintojo svetainės. Moralas: BSOD nurodytas modulis gali būti paveiktos posistemės dalis, o ne šaltinis.

Tipinis palaikymo komandos atsakymas ir greiti veiksmai vartotojams

Tikrame palaikymo pokalbyje technikas atsakė: „Atsiprašau už nepatogumus. Tai gali būti tvarkyklės, atminties ar antivirusinės programos problema. Atnaujinkite tvarkykles ir, jei problema išlieka, paleiskite atminties diagnostiką.“Tai yra pagrindinis, bet pagrįstas patarimas; tačiau jei klaidos išlieka, patartina atlikti išsamesnę analizę naudojant tikrintuvą ir duomenų išklotinę.

Netechniniams vartotojams tinkamas protokolas būtų: 1) Patikrinkite sistemos įvykius, 2) Atnaujinkite pagrindines tvarkykles (lustų rinkinį / tinklą / grafiką), 3) Patikrinkite RAM atmintį su integruotu įrankiu, 4) bandymas bagažinė 5) išvalyti be trečiųjų šalių programinės įrangos, kuri įterpia kabliukus į branduolį/grafinę sąsają, ir 6) naudoti „Verifier“ trečiųjų šalių tvarkyklėms, jei niekas neaišku.

Geriausia vairuotojų kūrėjų praktika

Jei kuriate ir netyčia aptinkate D1/A, patikrinkite, ar vykdoma rutina nepažymėta kaip puslapiuojama Nekvieskite puslapiuojamų funkcijų, kai veikiate DISPATCH_LEVEL ar aukštesniu lygiu. Tai apima nuorodų į duomenis puslapiuojamuose skyriuose vengimą ir IRQL apribojimų, susijusių su branduolio pagalbininkais, laikymąsi, aprašytų DDK.

Norėdami sinchronizuoti bendrinamus duomenis, taikyti taisyklę „visada pasiekti bendrinamus duomenis tuo pačiu aukštu IRQL“ ir prireikus naudokite sukimosi užraktus. Daugiaprocesoriuose vien IRQL negarantuoja išskyrimo tarp skirtingų procesorių; sukimosi užraktai padidina IRQL (iki DISPATCH_LEVEL) ir koordinuoja prieigą tarp branduolių. Jei reikia dirbti su jautriais aparatinės įrangos registrais, KeSynchronizeExecution padeda vykdyti kritinius skyrius teisingu DIRQL.

Kai planas reikalauja padidinti IRQL, JAV KeRaiseIrqlToDpcLevel DISPATCH_LEVEL arba KeRaiseIrql atsargiai, išsaugodami ankstesnį IRQL ir tiksliai jį atkurdami su KeLowerIrql. Net ir akimirkai nusileiskite žemiau įvesties IRQL ribos. Tai rimta sinchronizacijos klaida.

Ryšys su pertraukimais ir technine įranga

IRQL yra mechanizmas, kuriuo „Windows“ įsakymai nutraukia prioritetus ir tam tikras vidines užduotisArchitektūriniu lygmeniu jis susijęs su tokiomis sąvokomis kaip „Pertraukimas“, „Pertraukimų tvarkytojas“ arba „Pertraukimų prioriteto lygis“, o klasikinėse platformose – su Programuojamas pertraukų valdiklis (PIC)Kitose sistemose prioritetų valdymas išreiškiamas tokiais mechanizmais kaip spl en unix; bendra idėja ta pati: kas gali ką pertraukti.

Išplėstiniai derinimo patarimai

Sąvartynuose, kur krūva rodo į win32kfull!xxxProcessNotifyWinEvent su klaidų patikrinimu 0xA/0xD1, konteksto patikrinimas su .process y .thread (jei įmanoma), peržiūrėkite tokius procesus kaip explorer.exe en !process 0 1 ir patikrinkite perdengimus bei grafinės sąsajos tvarkykles. Dažnai problema kyla Tai trečiosios šalies sugadinta atmintis, kuri atsiranda tame maršrute..

Nepamirškite patikrinti IRQL su !irqlir kontrastas: jei esate DISPATCH_LEVEL (2) lygyje ir 3 parametras rodo skaitymą / rašymą / vykdymą puslapyje, kurį galima spausdinti, jau turite užuominą, kodėl jis nukrito. Perbraukite tą užuominą su ln 4 parametre, kad gautumėte konkrečią funkciją.

suprasti Kas yra IRQL? ir kaip tai dera prie branduolio vykdymo, padeda atskirti triukšmą nuo signalų. Jei esate vartotojas, sutelkite dėmesį į tvarkyklės ir aparatinė įranga (su numatytaisiais „Verifier“, įvykiais ir testais). Jei kuriate, griežtai laikykitės IRQL, nepuslapinės atminties ir sinchronizavimo su sukimosi užraktais taisyklių. Naudodami tinkamus įrankius („WinDbg“, „Verifier“) ir atidžiai skaitydami parametrus (1, 3 ir 4), Šie klaidų patikrinimai nebėra paslaptis ir jos tampa problemomis, kurias galima spręsti metodiškai.