Mis on Windowsi IRQL (katkestustaotluse tase) ja kuidas see on seotud BSOD-idega?

Kui olete kunagi näinud sinist ekraani selliste teadetega nagu IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUALolete ilmselt kokku puutunud mõistega, mis on väljaspool draiverite maailma vähetuntud: IRQL (katkestustaotluse tase). Windows, on sellel katkestuse prioriteedi tasemel eelis niidi prioriteedi ees, kui süsteem on üle teatud läve ja sellel on otsesed tagajärjed stabiilsusele.

Järgmistes ridades leiad ,es täielik juhend ja hispaania keeles Hispaaniast selle kohta, mis on IRQL ja kuidas see toimib, miks see siniseid ekraane käivitab, kuidas diagnoosida WinDbg-ga seotud probleemi ja mida teha olenemata sellest, kas olete kasutaja, kellel esineb viga, või arendate kernel-režiimi draivereid. Asume asja kallale.

Mis on Windowsi katkestustaotluse tase (IRQL)?

Windowsis, IRQL määratleb prioriteedi riistvara kus protsessor töötab igal ajahetkel. Windowsi draiverimudeli (WDM) piires võib madala IRQL-iga töötav kood katkeda kõrgema IRQL-iga töötava koodi poolt. Tegelikult võib ühes mitmetuumalises arvutis olla iga protsessori IRQL-i väärtus erinev, mis raskendab sünkroonimist.

On üks peamine reegel: Kui protsessori IRQL-väärtus on kõrgem kui PASSIVE_LEVEL, saab seda ennetada ainult veelgi kõrgema IRQL-väärtusega aktiivsus.See korraldab kasutajakoodi, kerneli funktsioonide, edasilükatud helistajate (DPC-de) ja seadme katkestuste teenuserutiinide (ISR-ide) kooseksisteerimist.

Tasemed ja prioriteedid: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL ja DIRQL

Üldiselt x86-l kasutatakse IRQL väärtusi vahemikus 0 kuni 31; x64-l vahemikus 0 kuni 15Praktiline tähendus on sama: IRQL 0 (PASSIVE_LEVEL) on koht, kus käivitatakse tavaline kasutajakood ja paljud draiveri funktsioonid; APC ja lehekülje vead Tavaliselt on need kaardistatud IRQL 1-le (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) hõlmab lõimede ajastajat ja DPC-sid. DISPATCH_LEVEL-ist kõrgemad on tasemed, mis on reserveeritud seadme katkestustele (tuntud kui DIRQL) ja muule sisemisele kasutusele, näiteks HIGH_LEVEL.

Juhi ökosüsteemis Paljud levinud rutiinid töötavad DISPATCH_LEVEL-ilNäiteks DPC ja StartIo. See disain tagab, et kui üks neist puudutab sisemisi järjekordi või muid jagatud ressursse, siis samal tasemel olev teine ​​rutiin ei tühista seda protsessoril, kuna ennetusreegel lubab katkestusi ainult kõrgematel tasemetel.

DISPATCH_LEVEL ja profileerimise/kõrgete tasemete vahel on ruumi iga seadme riistvarakatkestused (DIRQL)Seadme IRQL määrab selle prioriteedi teiste seadmete ees. WDM-draiver saab selle IRQL-i IRP_MJ_PNP ajal koos IRP_MN_START_DEVICE-ga. See seadme IRQL ei ole globaalne, fikseeritud väärtus, vaid pigem väärtus, mis on seotud konkreetse katkestusliiniga.

IRQL vs. lõime prioriteet

Soovitav on mitte segi ajada mõisteid: Lõime prioriteet määrab, millal ajastaja eelseadistab toimingu ja milline lõim käivitub.; IRQL kontrollib, millist tüüpi tegevust saab käivitada ja millised katkestused maskeeritakse. Üle DISPATCH_LEVEL-i lõime vahetamist ei toimu: seda kontrollib IRQL, mitte lõime prioriteet.

IRQL ja lehitsemine: mida te ei tohiks teha

IRQL-i tõstmise otsene mõju on see, et süsteem ei suuda lehevigu käsitledaKuldreegel: DISPATCH_LEVEL-il või kõrgemal töötav kood ei saa põhjustada lehevigu. Praktikas tähendab see, et need rutiinid ja andmed, mida nad puudutavad, peab asuma mittelehelises mälusLisaks piiravad teatud kerneli abiprogrammid oma kasutamist IRQL-i alusel: näiteks KeWaitForSingleObject DISPATCH_LEVEL-i saab kutsuda ainult siis, kui te ei blokeeri (null ajalõpp) ja nullist erinevate ajalõpude korral peate olema alla DISPATCH_LEVEL-i.

IRQL-i kaudne ja otsene kontroll

Enamasti süsteem ise käivitab teie rutiinid õige IRQL-i juures mida nad peaksid tegema. IRP-de dispetšerrutiinid töötavad PASSIVE_LEVEL-il (nad saavad blokeerida või kutsuda mis tahes abilist), StartIo ja DPC töötavad jagatud järjekordade kaitsmiseks DISPATCH_LEVEL-il ning ISR-id töötavad DIRQL-il.

Kui teil on vaja seda otseselt kontrollida, Saate IRQL-i tõsta ja langetada, kasutades KeRaiseIrql y KeLowerIrqlSeal on üks väga kasutatav otsetee: KeRaiseIrqlToDpcLevel() tagastab eelmise IRQL-i ja jätab sulle DISPATCH_LEVEL-i. Tähtis: ära kunagi langeta IRQL-i allapoole väärtust, millel see oli süsteemi kutsumise hetkel; selle sünkroniseerimise rikkumine võib avada väga tõsiseid võidujooksuaknaid.

IRQL-iga seotud sinise ekraani vead: IRQL_NOT_LESS_OR_EQUAL ja DRIVER_IRQL_NOT_LESS_OR_EQUAL

Kaks nende probleemidega seotud klassikalist veakontrolli on IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Mõlemad viitavad katsele pääseda ligi leheküljele sobivale (või kehtetule) aadressile liiga kõrge IRQL-iga. Tavaliselt on selle põhjuseks draiverid, mis kasutavad valesid aadresse, eemaldavad halbu pointereid või käivitavad leheküljele sobivat koodi sobimatutel tasemetel.

Konkreetsel juhul DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parameetrid on väga informatiivsed: 1) viidatud mäluaadress; 2) IRQL sel ajal; 3) juurdepääsu tüüp (0 lugemine, 1 kirjutamine, 2/8 täitmine); 4) mälule viitava käsu aadress. Siluriga saate kasutada ln parameetri 4 kohta loetlege lähim sümbol ja teadke, milline funktsioon töötas.

Levinud põhjused, mida meeles pidada

Lisaks konkreetsele koodile on ka korduvaid mustreid. Vigase pointeri viitamine DISPATCH_LEVEL-ile või kõrgemale tasemele See on kindel katastroofi retsept. Sellel tasemel leheldatavatele andmetele juurdepääs või leheldatava koodi (nt leheldatavaks märgitud funktsiooni) käivitamine käivitab samuti veakontrolli.

Muud levinud juhtumid hõlmavad järgmist kutsuge funktsiooni teises draiveris, mis on juba alla laaditud (rippuv funktsiooni osuti) või kaudselt käivitatud sobimatu funktsiooni osuti kaudu. Sageli, kui süsteem suudab mooduli tuvastada, näete selle nime sinisel ekraanil endal ja see salvestatakse ka KiBugCheckDriver, ligipääsetav koos dx KiBugCheckDriver WinDbgist.

Praktiline detail: Enamikus D1/A-des ei ole tegelik probleem mitte IRQL ise., vaid pigem viidatud mäluaadress. Seetõttu on parameetrid 1, 3 ja 4 diagnoosi täpsustamiseks üliolulised.

Diagnostika WinDbg-ga: kasulikud käsud ja parameetrite lugemine

Nende juhtumitega töötamiseks WinDbg on peamine tööriistja kui BSOD mainib ntoskrnl.exe See teave annab palju juhiseid selle kohta, kas viga on kerneli alamsüsteemis. Alustage sellest, et !analyze -v et saada veakontrolli, pinu ja heal juhul ka kaasatud mooduli kokkuvõte. Kui mälutõmmis sisaldab jäädvustuskaadrit, .trap asetab teid rikkis protsessori konteksti.

osa käsud kuhjast kui k, kb, kc, kd, kp, kP, kv Need näitavad sulle tagasijälgimise detailsuse erinevaid tasemeid. ln parameetri 4 puhul võite vahele jätta käsule, mis viitas mälule ja hankige lähedalasuv sümbol. Ja kui kahtlustate, et prioriteeditase töötab enne katkestust, !irql näitab sihtprotsessori salvestatud IRQL-i (nt DISPATCH_LEVEL).

Parameetri 1 suuna analüüsimiseks !pool See annab sulle teada, kas see kuulub leheküljega jagatud basseini; !address y !pte süveneda selle piirkonna mälukaardistamisse. Saate seda kasutada mälu kuvamise käsud et kontrollida sisu, millele üritati juurde pääseda. Lõpuks u, ub, uu võimaldab teil parameetri 4 aadressi ümber lahti võtta.

Ära unusta lm t n laaditud moodulite loetlemiseks y !memusage mälu üldise seisundi kohta. Kui KiBugCheckDriver omab midagi, dx KiBugCheckDriver See tagastab Unicode'i mooduli nime: tüüpilises näites nähti veakontrolli käigus kaasatud draiverina „Wdf01000.sys”.

Süsteemitööriistad: draiveri kontrollija, sündmustevaatur ja diagnostika

El Juhi kontrollija Uurib draiverite käitumist reaalajas ja tekitab vigu, kui tuvastab vale ressursikasutuse (näiteks basseini), tekitades erandi, et isoleerida koodi probleemne ala. See käivitatakse koos verifier pärit käsuviip ja liigse üldkulu vältimiseks on soovitatav valida võimalikult väike draiverite komplekt.

Kui sa ei näe ennast WinDbg-iga sobivana, rakendage põhimeetmeidKontrollige sündmustevaaturis süsteemilogist konkreetsele seadmele/draiverile viitavaid vigu; värskendage või keelake sinise ekraani poolt viidatud draiver; kontrollige riistvara ühilduvust oma Windowsi versiooniga; ja kasutage Windowsi mäludiagnostikat, kui kahtlustate RAM-i puudumist. Need toimingud, kuigi lihtsad, nad lahendavad suure hulga juhtumeid.

Päriselus esinevad juhtumid: kui BSOD-id tunduvad juhuslikud

Kasutaja, kellel on Windows 10 Pro (AMD Ryzen 5 3400G protsessor, GPU NVIDIA GeForce GTX 1660 Ti ja Gigabyte B450 AORUS PRO WIFI-plaat, 16 GB muutmälu) esines vahelduvaid ekraanipilte "IRQL_LESS_OR_NOT_EQUAL". Olin juba värskendanud olulised draiverid (võrgu-, graafikakaart), installinud kõik Windowsi värskendused ja käivitanud mälutööriista, kuid probleeme ei tuvastatud.

Sellistel juhtudel Järgmine samm on prügimägede analüüsimine WinDbg abil ja otsige mustreid: protsesse, mis toimuvad kukkumisel (näiteks explorer.exe), graafilise liidese moodulid (win32kfull.sys) ja funktsioonid, näiteks xxxProcessNotifyWinEvent ilmuvad pinus. Kuigi see moodul on Windowsi moodul, on käivitajaks sageli kolmanda osapoole draiver (graafika, sisend, ülekate, jäädvustuskaardid), mis kasutab mälu sobimatu IRQL-iga ja viga tekib win32k.

Praktiline soovitus on siin ajutiselt keelake pealiskihi tarkvara (jäädvustamine, GPU OSD), agressiivsed tarkvaralised välisseadmete draiverid (makrodega hiired/klaviatuurid) ja graafikadraiverite beetaversioonid ning kitsendada valikut. Kahtlusaluste draiverite puhul aitab draiveri kontrollija probleemi kitsendada ja leida selgema lahenduse.

Väga levinud võrgumuster: ndis.sys pole alati süüdlane

Teine tüüpiline juhtum: ekraanipilt failiga ndis.sys (Windowsi võrgukiht). Päris arvutis jookseks süsteem kohe käivitamisel kokku. Praktiline lahendus oli buutida Turvarežiim ilma võrgufunktsioonideta avage Seadmehaldur ja probleemi isoleerimiseks keelake adapterid jaotises „Võrguadapterid”.

Selles meeskonnas oli Realtek PCIe GBE perekonna kontroller ja Atheros AR5007GMõlema deaktiveerimise teel tuvastati, et tegelik põhjus oli athrx.sys (Atheros), kuigi sinine ekraan mainitud ndis.sysPrügimägi kinnitas seda: virn läbis ndis!NdisFreeTimerObject aga süüdi moodul oli athrx.sysLõplik parandus oli desinstallige seade ja installige uuendatud ametlikud draiverid Atherose tootja veebisaidilt. Moraal: BSOD-is viidatud moodul võib olla osa mõjutatud alamsüsteemist, mitte allikas.

Tüüpiline tugivastus ja kiired sammud kasutajatele

Tõelises tugivestluses vastas tehnik: "Vabandust ebamugavuste pärast. Võimalik, et tegemist on draiveri, mälu või viirusetõrje probleemiga. Palun värskendage draivereid ja kui probleem püsib, käivitage mäludiagnostika."See on elementaarne, aga kehtiv nõuanne; kui vead püsivad, on hea mõte minna edasi kontrollija ja prügimäe analüüsiga.

Mitte-tehniliste kasutajate jaoks oleks mõistlik protokoll järgmine: 1) Kontrollige süsteemisündmusi, 2) Värskendage võtmedraivereid (kiibistik/võrk/graafika), 3) Kontrollige RAM-i integreeritud tööriistaga, 4) test saabas 5) puhastada ilma kolmanda osapoole tarkvarata, mis lisab kerneli/graafilisse kasutajaliidesesse konksusid, ja 6) kasutada Verifierit kolmanda osapoole draiverite puhul, kui miski pole selge.

Draiverite arendajate parimad tavad

Kui oled arendusjärgus ja komistad D1/A otsa, siis kontrolli, kas Töötav rutiin ei ole märgitud leheküljeks Ärge kutsuge leheküljestatavaid funktsioone, kui töötate DISPATCH_LEVEL-il või kõrgemal tasemel. See hõlmab viidete vältimist leheküljestatud sektsioonide andmetele ja DDK-s kirjeldatud kerneli abistajate IRQL-piirangute austamist.

Jagatud andmete sünkroonimiseks rakenda reeglit "juurdepääs jagatud andmetele alati sama kõrge IRQL-iga" ja kasutage vajadusel spin-lukke. Mitmeprotsessorilistes arvutites ei garanteeri IRQL üksi erinevate protsessorite vahelist välistamist; spin-lukud tõstavad IRQL-i (DISPATCH_LEVEL-ile) ja koordineerivad juurdepääsu tuumade vahel. Kui teil on vaja töötada tundlike riistvararegistritega, KeSynchronizeExecution aitab teil kriitilisi sektsioone õige DIRQL-iga täita.

Kui plaan nõuab IRQL-i tõstmist, USA KeRaiseIrqlToDpcLevel DISPATCH_LEVEL jaoks või KeRaiseIrql hoolikalt, salvestades eelmise IRQL-i ja taastades selle täpselt KeLowerIrqlMine allapoole sisendi IRQL-i, isegi kui vaid hetkeks, See on tõsine sünkroniseerimisviga.

Seos katkestuste ja riistvaraga

IRQL on mehhanism, mille abil Windows korraldused katkestavad prioriteedid ja teatud sisemised ülesandedArhitektuurilisel tasandil on see seotud selliste mõistetega nagu "katkestus", "katkestuste käitleja" või "katkestuse prioriteeditase" ning klassikalistel platvormidel ka ... Programmeeritav katkestuskontroller (PIC)Teistes süsteemides väljendatakse prioriteetide kontrolli selliste mehhanismide kaudu nagu spl en Unix; üldine idee on sama: kes saab keda segada.

Täiustatud silumisnipid

Prügimägedes, kuhu virn osutab win32kfull!xxxProcessNotifyWinEvent veakontrolliga 0xA/0xD1, kontrolli konteksti .process y .thread (kui see on olemas), vaadake protsesse, näiteks explorer.exe en !process 0 1 ja kontrollige ülekatteid ning GUI interaktsiooni draivereid. Sageli on probleem See on sellel marsruudil ilmuv kolmanda osapoole poolt rikutud mälu..

Ära unusta IRQL-i kontrollida !irqlja kontrast: kui olete DISPATCH_LEVEL (2) tasemel ja parameeter 3 näitab lugemist/kirjutamist/käivitamist Kui lekitataval lehel on sul juba vihje, miks see kukkus, siis tee sellele vihjele kriipsu. ln parameetris 4, et saada konkreetne funktsioon.

Saage aru Mis on IRQL? ja kuidas see kerneli teostusse sobitub, aitab müra signaalidest eraldada. Kui oled kasutaja, keskendu sellele, draiverid ja riistvara (vaikimisi Verifieri, sündmuste ja testidega). Arendamise korral järgige rangelt IRQL-i, mittelehelise mälu ja spin-lukkude sünkroniseerimise reegleid. Õigete tööriistade (WinDbg, Verifier) ​​​​ja parameetrite (1, 3 ja 4) hoolika lugemise abil Need veakontrollid pole enam mingi müsteerium. ja neist saavad probleemid, mida saab metoodiliselt lahendada.