Što je IRQL (Interrupt Request Level - razina zahtjeva za prekid) u sustavu Windows i kako je povezan s BSOD-ima?

Ako ste ikada vidjeli plavi ekran s porukama poput IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, vjerojatno ste naišli na koncept koji je malo poznat izvan svijeta upravljačkih programa: IRQL (Interrupt Request Level - razina zahtjeva za prekid). Windows, ova razina prioriteta prekida ima prednost nad prioritetom niti kada je sustav iznad određenog praga, a to ima izravne posljedice na stabilnost.

U sljedećim redovima naći ćete u cjeloviti vodič i na španjolskom iz Španjolske o tome što je IRQL, kako funkcionira, zašto se pojavljuju plavi ekrani, kako dijagnosticirati problem s WinDbg-om i što učiniti bez obzira jeste li korisnik koji ima grešku ili razvijate upravljačke programe za kernel mod. Prijeđimo na posao.

Što je IRQL (Interrupt Request Level - razina zahtjeva za prekid) u sustavu Windows?

U sustavu Windows, IRQL definira prioritet hardver na kojem procesor radi u bilo kojem trenutku. Unutar Windows Driver Modela (WDM), kod koji se izvršava na niskom IRQL-u može biti prekinut kodom koji se izvršava na višem IRQL-u. Zapravo, na jednom višejezgrenom računalu, svaki CPU može biti na drugom IRQL-u, što komplicira sinkronizaciju.

Postoji jedno ključno pravilo: Kada CPU radi na IRQL-u iznad PASSIVE_LEVEL, može ga preuzeti samo aktivnost na još višem IRQL-u.Ovo organizira koegzistenciju između korisničkog koda, kernel funkcija, odgođenih pozivatelja (DPC) i rutina za obradu prekida uređaja (ISR).

Razine i prioriteti: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL i DIRQL

Općenito, Na x86 se koriste IRQL vrijednosti između 0 i 31; na x64, između 0 i 15.Praktično značenje je isto: IRQL 0 (PASSIVE_LEVEL) je mjesto gdje se izvršava normalan korisnički kod i mnoge funkcije upravljačkog programa; APC i pogreške stranice Obično su mapirani na IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) obuhvaća raspoređivač niti i DPC-ove. Iznad DISPATCH_LEVEL su razine rezervirane za prekide uređaja (poznate kao DIRQL) i druge interne upotrebe kao što je HIGH_LEVEL.

U ekosustavu vozača, Mnoge uobičajene rutine se izvode na DISPATCH_LEVELna primjer, DPC i StartIo. Ovaj dizajn osigurava da dok jedan od njih dodiruje interne redove čekanja ili druge dijeljene resurse, druga rutina na istoj razini ga ne preuzima na tom CPU-u, jer pravilo preempcije dopušta prekide samo na višim razinama.

Između DISPATCH_LEVEL i profiliranja/visokih razina ima mjesta za hardverski prekidi svakog uređaja (DIRQL)IRQL uređaja definira njegov prioritet nad drugim uređajima. WDM upravljački program dobiva ovaj IRQL tijekom IRP_MJ_PNP s IRP_MN_START_DEVICE. Ovaj IRQL uređaja nije globalna, fiksna vrijednost, već vrijednost povezana s određenom linijom prekida.

IRQL u odnosu na prioritet niti

Preporučljivo je ne miješati pojmove: Prioritet niti određuje kada raspoređivač preuzima odgovornost i koja se nit izvršava.; IRQL kontrolira koja se vrsta aktivnosti može izvršiti i koji su prekidi maskirani. Iznad DISPATCH_LEVEL nema prebacivanja niti: IRQL kontrolira, a ne prioritet niti.

IRQL i straničenje: Što ne biste trebali raditi

Neposredan učinak povećanja IRQL-a je da sustav ne može obraditi greške straniceZlatno pravilo: kod koji se izvršava na ili iznad DISPATCH_LEVEL ne može uzrokovati greške stranica. U praksi to znači da te rutine i podaci koje dodiruju mora se nalaziti u nestraničnoj memorijiOsim toga, određeni kernel pomoćnici ograničavaju svoju upotrebu na temelju IRQL-a: na primjer, KeWaitForSingleObject DISPATCH_LEVEL se može pozvati samo ako ne blokirate (nulti timeout), a za timeoute koji nisu nulti, morate biti ispod DISPATCH_LEVEL.

Implicitna i eksplicitna kontrola IRQL-a

Većinu vremena, sam sustav poziva vaše rutine na ispravnom IRQL-u za što bi trebali učiniti. Rutine otpreme za IRP-ove izvode se na PASSIVE_LEVEL (mogu blokirati ili pozvati bilo kojeg pomagača), StartIo i DPC izvode se na DISPATCH_LEVEL kako bi zaštitili dijeljene redove čekanja, a ISR-ovi se izvode na DIRQL.

Ako ga trebate eksplicitno kontrolirati, IRQL možete povećati i smanjiti pomoću KeRaiseIrql y KeLowerIrqlPostoji vrlo korištena prečica: KeRaiseIrqlToDpcLevel() vraća prethodni IRQL i ostavlja vas na DISPATCH_LEVEL. Važno: Nikada ne snižavajte IRQL ispod vrijednosti na kojoj je bio kada vas je sustav pozvao; prekid te sinkronizacije može otvoriti vrlo ozbiljne prozore utrke.

Greške plavog ekrana povezane s IRQL-om: IRQL_NOT_LESS_OR_EQUAL i DRIVER_IRQL_NOT_LESS_OR_EQUAL

Dvije klasične provjere grešaka povezane s ovim problemima su IRQL_NIJE_MANJI_ILI_JEDNAKI (0xA) y DRIVER_IRQL_NIJE_MANJI_ILI_JEDNAKI (0xD1)Oba ukazuju na pokušaj pristupa straničivoj (ili nevažećoj) adresi na IRQL-u koji je previsok. To je obično zbog toga što upravljački programi koriste netočne adrese, dereferenciraju loše pokazivače ili izvršavaju straničivi kod na neprikladnim razinama.

U konkretnom slučaju DRIVER_IRQL_NIJE_MANJI_ILI_JEDNAKI (0x000000D1), parametri su vrlo informativni: 1) referencirana adresa memorije; 2) IRQL u tom trenutku; 3) vrsta pristupa (0 čitanje, 1 pisanje, 2/8 izvršavanje); 4) adresa instrukcije koja je referencirala memoriju. Pomoću debuggera možete koristiti ln na parametru 4 za navesti najbliži simbol i znati koja se funkcija izvršavala.

Uobičajeni uzroci koje treba imati na umu

Osim specifičnog koda, postoje i obrasci koji se ponavljaju. Dereferenciranje nevažećeg pokazivača na DISPATCH_LEVEL ili više Ovo je siguran recept za katastrofu. Pristup podacima koji se mogu podijeliti u stranice na toj razini ili izvršavanje koda koji se može podijeliti u stranice (npr. funkcija označena kao podijelljiva u stranice) također pokreće provjeru grešaka.

Drugi uobičajeni slučajevi uključuju pozvati funkciju u drugom upravljačkom programu koji je već preuzet (viseći pokazivač funkcije) ili neizravno pozvan putem nevažećeg pokazivača funkcije. Često, ako sustav može identificirati modul, vidjet ćete njegovo ime na samom plavom ekranu, a također je spremljen u KiBugCheckDriver, dostupno s dx KiBugCheckDriver iz WinDbg-a.

Praktičan detalj: U većini D1/A, pravi problem nije sam IRQL., već referencirana memorijska adresa. Zato su parametri 1, 3 i 4 ključni za fokusiranje dijagnoze.

Dijagnostika s WinDbg-om: Korisne naredbe i čitanje parametara

Za rad na ovim slučajevima, WinDbg je ključni alati ako BSOD spominje ntoskrnl.exe Ove informacije pružaju mnogo smjernica o tome je li greška u podsustavu jezgre. Započnite s !analyze -v da biste dobili sažetak provjere grešaka, stog i, ako imate sreće, uključeni modul. Ako dump uključuje okvir za snimanje, .trap stavlja vas u kontekst neispravnog CPU-a.

The naredbe hrpe kao k, kb, kc, kd, kp, kP, kv Oni vam pokazuju različite razine detalja povratnog praćenja. S ln na parametru 4 možete preskočiti instrukciji koja je referencirala memoriju i dobiti obližnji simbol. A ako sumnjate da je razina prioriteta pokrenuta prije prekida, !irql prikazuje spremljeni IRQL za ciljni procesor (npr. DISPATCH_LEVEL).

Za analizu smjera parametra 1, !pool Reći će vam pripada li straničenom skupu; !address y !pte istražiti mapiranje memorije tog područja. Možete koristiti naredbe za prikaz memorije pregledati sadržaj kojem se pokušalo pristupiti. Konačno, u, ub, uu omogućuju vam rastavljanje oko adrese parametra 4.

Ne zaboravite lm t n za popis učitanih modula y !memusage za opće stanje pamćenja. Ako KiBugCheckDriver ima nešto, dx KiBugCheckDriver Vratit će naziv Unicode modula: u tipičnom primjeru, "Wdf01000.sys" je prepoznat kao upravljački program uključen tijekom provjere grešaka.

Sistemski alati: Provjera upravljačkih programa, Preglednik događaja i Dijagnostika

El Verifikator upravljačkog programa Ispituje ponašanje upravljačkih programa u stvarnom vremenu i prisiljava pogreške kada otkrije neispravno korištenje resursa (kao što je skup), podižući iznimku za izolaciju problematičnog područja koda. Pokreće se s verifier od naredbeni redak i preporučljivo je odabrati što manji skup upravljačkih programa kako bi se izbjeglo preveliko opterećenje.

Ako se ne vidite s WinDbg-om, primijeniti osnovne mjere: Provjerite zapisnik sustava u Pregledniku događaja za pogreške koje upućuju na određeni uređaj/upravljački program; ažurirajte ili onemogućite upravljački program koji je naveo plavi ekran; provjerite kompatibilnost hardvera s vašom verzijom sustava Windows; i upotrijebite dijagnostiku memorije sustava Windows ako sumnjate na RAM. Ove radnje, iako jednostavne, rješavaju veliki broj slučajeva.

Slučajevi iz stvarnog života: Kada se BSOD-ovi čine nasumičnima

Korisnik s Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti i Gigabyte B450 AORUS PRO WIFI ploča, 16 GB RAM-a) povremeno je pojavljivao ekrane "IRQL_LESS_OR_NOT_EQUAL". Već sam ažurirao bitne upravljačke programe (mrežu, grafiku), instalirao sva ažuriranja za Windows i pokrenuo alat za memoriju, sve bez ikakvih problema.

U scenarijima poput ovog, Sljedeći korak je analiza dumpova pomoću WinDbg-a i potražite obrasce: procese koji se događaju kada padne (na primjer explorer.exe), moduli grafičkog sučelja (win32kfull.sys) i funkcije kao što su xxxProcessNotifyWinEvent pojavljuju se u stogu. Iako je ovaj modul Windows, okidač je često upravljački program treće strane (grafika, ulaz, prekrivanje, kartice za snimanje) koji koristi memoriju na neodgovarajućem IRQL-u i kvar nastaje unutar win32k.

Praktična preporuka ovdje je privremeno onemogućite softver za prekrivanje (snimanje, GPU OSD), agresivne softverske periferne upravljačke programe (miševi/tipkovnice s makroima) i beta verzije grafičkih upravljačkih programa te suzite izbor. Korištenje alata za provjeru upravljačkih programa na sumnjivim mjestima može pomoći u sužavanju problema s jasnijim pregledom.

Vrlo čest mrežni obrazac: ndis.sys nije uvijek krivac

Još jedan tipičan slučaj: snimka zaslona s ndis.sys (Windows mrežni sloj). Na stvarnom računalu, sustav bi se srušio odmah nakon pokretanja. Praktično rješenje bilo je pokrenuti ga u Siguran način rada bez mrežnih funkcija, otvorite Administrator dispozitiva i onemogućite adaptere pod "Mrežni adapteri" kako biste izolirali problem.

U toj ekipi je bio Realtek PCIe GBE Family kontroler i Atheros AR5007GDeaktiviranjem oba, otkriveno je da je pravi uzrok bio athrx.sys (Atheros), iako se na plavom ekranu spominjalo ndis.sysIzmet je to potvrdio: stog je prošao kroz ndis!NdisFreeTimerObject ali modul krivnje bio je athrx.sysKonačna korekcija je bila Deinstalirajte uređaj i instalirajte ažurirane službene upravljačke programe S web stranice proizvođača Atherosa. Pouka: Modul naveden u BSOD-u može biti dio pogođenog podsustava, a ne izvor.

Tipičan odgovor podrške i brzi koraci za korisnike

U iskrenoj razmjeni podrške, tehničar je odgovorio: "Žao mi je zbog neugodnosti. Moguće je da je problem s upravljačkim programom, memorijom ili antivirusnim programom. Ažurirajte upravljačke programe i, ako se problem nastavi, pokrenite dijagnostiku memorije."Ovo je osnovni, ali valjan savjet; međutim, ako se pogreške i dalje pojavljuju, dobra je ideja ići dalje s Verifikatorom i analizom izvatka.

Za korisnike koji nisu tehnički potkovani, razuman protokol bi bio: 1) Provjerite događaje sustava, 2) Ažurirajte ključne upravljačke programe (čipset/mreža/grafika), 3) Provjerite RAM s integriranim alatom, 4) testirajte čizma čisto bez softvera treće strane koji ubacuje hooks u kernel/GUI i 5) koristite Verifier na upravljačkim programima treće strane ako ništa nije jasno.

Najbolje prakse za razvojne programere upravljačkih programa

Ako razvijate i naiđete na D1/A, provjerite da Izvršena rutina nije označena kao stranica Ne pozivajte funkcije koje se mogu podijeliti u stranice dok se izvršavaju na DISPATCH_LEVEL ili višoj razini. To uključuje izbjegavanje referenci na podatke u odjeljcima s podijeljenim stranicama i poštivanje IRQL ograničenja za pomoćne programe kernela opisane u DDK-u.

Za sinkronizaciju dijeljenih podataka, primijenite pravilo "uvijek pristupite dijeljenim podacima s istom visokom IRQL vrijednošću" i koristite spin lockove kada je to prikladno. Na višeprocesorskim računalima, sam IRQL ne jamči isključenje između različitih CPU-a; spin lockovi podižu IRQL (na DISPATCH_LEVEL) i koordiniraju pristup između jezgri. Ako trebate raditi na osjetljivim hardverskim registrima, KeSynchronizeExecution pomaže vam da izvršite kritične dijelove na ispravnom DIRQL-u.

Kada plan zahtijeva podizanje IRQL-a, namjene KeRaiseIrqlToDpcLevel za RAZINU_OTPREME ili KeRaiseIrql pažljivo, spremanje prethodnog IRQL-a i njegovo vraćanje točno s KeLowerIrqlIdite ispod ulaznog IRQL-a, čak i samo na trenutak, To je ozbiljna greška u sinkronizaciji.

Odnos s prekidima i hardverom

IRQL je mehanizam kojim Windows naredbe prekidaju prioritete i određene interne zadatkeNa arhitektonskoj razini, povezano je s konceptima kao što su "Prekid", "Upravljač prekidima" ili "Razina prioriteta prekida", a na klasičnim platformama i s Programabilni kontroler prekida (PIC)U drugim sustavima, kontrola prioriteta izražava se putem mehanizama kao što su wanly en Unix; opća ideja je ista: tko koga može prekinuti.

Napredni savjeti za otklanjanje pogrešaka

U dumpovima gdje stog pokazuje na win32kfull!xxxProcessNotifyWinEvent s provjerom grešaka 0xA/0xD1, pregledajte kontekst s .process y .thread (ako je dostupno), pogledajte procese poput explorer.exe en !process 0 1 i provjerite prekrivanja i upravljačke programe za interakciju s GUI-jem. Mnogo puta problem To je sjećanje oštećeno od strane treće strane koja se pojavljuje na toj ruti.

Ne zaboravite provjeriti IRQL s !irqli kontrast: ako ste na DISPATCH_LEVEL (2) i parametar 3 označava čitanje/pisanje/izvršavanje Na stranici koja se može dijelje, već imate trag zašto je pala. Prekrižite taj trag s ln u parametru 4 kako bi se dobila specifična funkcija.

razumjeti Što je IRQL? i kako se uklapa u izvršavanje kernela pomaže u odvajanju šuma od signala. Ako ste korisnik, usredotočite se na upravljački programi i hardver (s Verifierom, događajima i testovima prema zadanim postavkama). Ako razvijate, strogo se pridržavajte pravila za IRQL, nestraničnu memoriju i sinkronizaciju sa spin lockovima. S pravim alatima (WinDbg, Verifier) ​​​​i pažljivim čitanjem parametara (1, 3 i 4), Ove provjere grešaka više nisu misterij i oni postaju problemi koji se mogu metodično rješavati.