Šta je IRQL (Interrupt Request Level - nivo zahtjeva za prekid) u Windowsu i kako je povezan sa BSOD-ovima?

Ako ste ikada vidjeli plavi ekran s porukama poput IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LEG_OR_EQUAL, vjerovatno ste naišli na koncept koji je malo poznat izvan svijeta drajvera: IRQL (Interrupt Request Level - nivo zahtjeva za prekid). Windows, ovaj nivo prioriteta prekida ima prednost nad prioritetom niti kada je sistem iznad određenog praga, a to ima direktne posljedice na stabilnost.

U narednim redovima ćete pronaći una potpuni vodič i na španskom iz Španije o tome šta je IRQL, kako funkcioniše, zašto se pojavljuju plavi ekrani, kako dijagnosticirati problem s WinDbg-om i šta učiniti bez obzira jeste li korisnik koji ima problema s greškom ili razvijate upravljačke programe za kernel mod. Hajde da se bacimo na posao.

Šta je IRQL (Interrupt Request Level - nivo zahtjeva za prekid) u Windowsu?

U operativnom sistemu 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. U stvari, na jednom višejezgrenom računaru, svaki CPU može biti na drugom IRQL-u, što komplicira sinhronizaciju.

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

Nivoi i prioriteti: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL i DIRQL

Uopšteno govoreći, 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 drajvera; APC i greške stranica Obično su mapirani na IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) obuhvata raspoređivač niti i DPC-ove. Iznad DISPATCH_LEVEL su nivoi rezervisani za prekide uređaja (poznati kao DIRQL) i druge interne upotrebe kao što je HIGH_LEVEL.

U ekosistemu vozača, Mnoge uobičajene rutine se izvršavaju 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 istom nivou ga ne preuzima na tom CPU-u, jer pravilo preempcije dozvoljava prekide samo na višim nivoima.

Između DISPATCH_LEVEL i profiliranja/visokih nivoa postoji prostor za hardverski prekidi svakog uređaja (DIRQL)IRQL uređaja definira njegov prioritet nad drugim uređajima. WDM drajver dobija ovaj IRQL tokom IRP_MJ_PNP sa IRP_MN_START_DEVICE. Ovaj IRQL uređaja nije globalna, fiksna vrijednost, već vrijednost povezana sa specifičnom linijom prekida.

IRQL u odnosu na prioritet niti

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

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

Neposredan efekat povećanja IRQL-a je da sistem 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 osnovu 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, Sistem sam poziva vaše rutine na ispravnom IRQL-u za ono što bi trebali raditi. Rutine otpreme za IRP-ove se izvršavaju na PASSIVE_LEVEL (mogu blokirati ili pozvati bilo kojeg pomagača), StartIo i DPC se izvršavaju na DISPATCH_LEVEL radi zaštite dijeljenih redova čekanja, a ISR-ovi se izvršavaju na DIRQL.

Ako to trebate eksplicitno kontrolirati, IRQL možete povećati i smanjiti pomoću KeRaiseIrql y KeLowerIrqlPostoji jedna veoma korištena prečica: KeRaiseIrqlToDpcLevel() vraća prethodni IRQL i ostavlja vas na DISPATCH_LEVEL. Važno: Nikada ne snižavajte IRQL ispod vrijednosti koju je imao kada vas je sistem pozvao; kršenje te sinhronizacije 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_MANJE_ILI_JEDNAKO (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 drajveri koriste netačne adrese, dereferenciraju loše pokazivače ili izvršavaju straničivi kod na neodgovarajućim nivoima.

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) tip 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 navedite najbliži simbol i saznajte koja se funkcija izvršavala.

Uobičajeni uzroci koje treba imati na umu

Pored specifičnog koda, postoje i obrasci koji se ponavljaju. Dereferenciranje nevažećeg pokazivača na DISPATCH_LEVEL ili viši nivo Ovo je siguran recept za katastrofu. Pristup podacima koji se mogu straniceti na tom nivou ili izvršavanje koda koji se može straniceti (npr. funkcija označena kao stranicativa) također pokreće provjeru grešaka.

Drugi uobičajeni slučajevi uključuju pozivanje funkcije u drugom drajveru koji je već preuzet (viseći pokazivač funkcije) ili indirektno pozvan putem nevažećeg pokazivača funkcije. Često, ako sistem može identificirati modul, vidjet ćete njegovo ime na samom plavom ekranu, a također je sačuvan u KiBugCheckDriver, dostupan sa 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 pomoću WinDbg-a: Korisne naredbe i čitanje parametara

Da biste radili na ovim slučajevima, WinDbg je ključni alat, i ako BSOD spomene ntoskrnl.exe Ove informacije pružaju mnogo smjernica o tome da li je greška u podsistemu kernela. Započnite sa !analyze -v da biste dobili sažetak provjere grešaka, stek i, ako imate sreće, uključeni modul. Ako ispis uključuje okvir za snimanje, .trap stavlja vas u kontekst neispravnog CPU-a.

u naredbe gomile kao k, kb, kc, kd, kp, kP, kv Oni vam pokazuju različite nivoe detalja povratnog traga. Sa ln na parametru 4 možete preskočiti instrukciji koja je referencirala memoriju i dobijte obližnji simbol. A ako sumnjate da je nivo prioriteta pokrenut prije prekida, !irql prikazuje sačuvani IRQL za ciljni procesor (npr. DISPATCH_LEVEL).

Da bismo analizirali smjer parametra 1, !pool Reći će vam da li pripada straničenom skupu; !address y !pte istražite mapiranje memorije tog područja. Možete koristiti komande za prikaz memorije pregledati sadržaj kojem se pokušalo pristupiti. Konačno, u, ub, uu omogućavaju vam da rastavite 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 tokom provjere grešaka.

Sistemski alati: Verifikator drajvera, Preglednik događaja i Dijagnostika

El Verifikator upravljačkog programa Ispituje ponašanje drajvera u realnom vremenu i prisiljava greške kada otkrije neispravno korištenje resursa (kao što je bazen), podižući izuzetak kako bi izolovao problematično područje koda. Pokreće se sa verifier od naredbeni redak i preporučljivo je odabrati najmanji mogući skup drajvera kako bi se izbjeglo preveliko opterećenje.

Ako se ne vidite s WinDbg-om, primijeniti osnovne mjereProvjerite sistemski dnevnik u Pregledniku događaja za greške koje ukazuju na određeni uređaj/drajver; ažurirajte ili onemogućite drajver koji je naveden plavim ekranom; provjerite kompatibilnost hardvera s vašom verzijom Windowsa; i koristite Windows Memory Diagnostic ako sumnjate na RAM. Ove radnje, iako jednostavne, rješavaju veliki broj slučajeva.

Slučajevi iz stvarnog života: Kada BSOD-ovi izgledaju nasumični

Korisnik sa Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti i Gigabyte B450 AORUS PRO WIFI matična ploča, 16 GB RAM-a) povremeno je imao ekrane sa greškom "IRQL_LESS_OR_NOT_EQUAL". Već sam ažurirao osnovne 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 tražite obrasce: procese koji se javljaju kada padne (na primjer explorer.exe), moduli grafičkog interfejsa (win32kfull.sys) i funkcije kao što su xxxProcessNotifyWinEvent pojavljuju se u steku. 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 greška nastaje unutar win32k.

Praktična preporuka ovdje je privremeno onemogućite softver za preklapanje (snimanje, GPU OSD), agresivne softverske periferne drajvere (miševi/tastature s makroima) i beta verzije grafičkih drajvera, te suzite izbor. Korištenje alata za provjeru upravljačkih programa na sumnjivim lokacijama može pomoći u sužavanju problema uz jasniji pregled.

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

Još jedan tipičan slučaj: snimak ekrana sa ndis.sys (Windows mrežni sloj). Na stvarnom računaru, sistem bi se srušio odmah nakon pokretanja. Praktično rješenje je bilo pokrenuti ga u Sigurni režim bez mrežnih funkcija, otvorite Upravitelj uređaja i onemogućite adaptere pod "Mrežni adapteri" da biste izolovali problem.

U toj ekipi je bilo Realtek PCIe GBE Family kontroler i Atheros AR5007GDeaktiviranjem oba, otkriveno je da je pravi uzrok bio athrx.sys (Atheros), iako se plavi ekran spominjao ndis.sysDamp je to potvrdio: stek je prošao kroz ndis!NdisFreeTimerObject ali modul krivnje je bio athrx.sysKonačna korekcija je bila Deinstalirajte uređaj i instalirajte ažurirane službene upravljačke programe Sa web stranice proizvođača Atherosa. Pouka: Modul naveden u BSOD-u može biti dio pogođenog podsistema, 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 u drajveru, memoriji ili antivirusu. Molimo vas da ažurirate drajvere i, ako se problem nastavi, pokrenite dijagnostiku memorije."Ovo je osnovni, ali valjan savjet; međutim, ako se greške i dalje pojavljuju, dobra je ideja nastaviti s Verifierom i analizom izvatka.

Za korisnike koji nisu tehnički potkovani, razuman protokol bi bio: 1) Provjerite sistemske događaje, 2) Ažurirajte ključne drajvere (čipset/mreža/grafika), 3) Provjerite RAM memoriju sa integrisanim alatom, 4) testirajte boot čisto bez softvera treće strane koji ubacuje hooks u kernel/GUI, i 5) koristite Verifier na drajverima treće strane ako ništa nije jasno.

Najbolje prakse za programere drajvera

Ako razvijate i naiđete na D1/A, provjerite da li je Izvršena rutina nije označena kao stranica za pregled Ne pozivajte funkcije koje se mogu straničiti dok se izvršavaju na DISPATCH_LEVEL ili višem nivou. To uključuje izbjegavanje referenci na podatke u stranicama sekcija i poštivanje IRQL ograničenja za kernel pomoćnike opisane u DDK-u.

Da biste sinhronizovali dijeljene podatke, primijenite pravilo "uvijek pristupite dijeljenim podacima na istom visokom IRQL-u" i koristite spin lockove kada je to prikladno. Na multiprocesorskim računarima, sam IRQL ne garantuje isključenje između različitih CPU-a; spin lockovi podižu IRQL (na DISPATCH_LEVEL) i koordiniraju pristup između jezgara. 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, SAD KeRaiseIrqlToDpcLevel za DISPATCH_LEVEL ili KeRaiseIrql pažljivo, čuvajući prethodni IRQL i vraćajući ga tačno sa KeLowerIrqlIdite ispod ulaznog IRQL-a, čak i samo na trenutak, To je ozbiljna greška u sinhronizaciji.

Veza s prekidima i hardverom

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

Napredni savjeti za otklanjanje grešaka

U dumpovima gdje stek pokazuje na win32kfull!xxxProcessNotifyWinEvent sa provjerom grešaka 0xA/0xD1, pregledaj kontekst sa .process y .thread (ako je dostupno), pogledajte procese poput explorer.exe en !process 0 1 i provjerite prekrivače i upravljačke programe za interakciju s grafičkim korisničkim interfejsom. Problem je često To je sjećanje oštećeno od strane treće strane koja se pojavljuje na toj ruti.

Ne zaboravite provjeriti IRQL sa !irql, i kontrast: ako ste na DISPATCH_LEVEL (2) i parametar 3 označava čitanje/pisanje/izvršavanje Na stranici koja se može dijeljevati na stranice, već imate naznaku zašto je pala. Ukrstite tu naznaku sa ln u parametru 4 da biste dobili specifičnu funkciju.

Shvati Šta je IRQL? i kako se uklapa u izvršavanje kernela pomaže u odvajanju šuma od signala. Ako ste korisnik, fokusirajte se na drajveri i hardver (sa Verifierom, događajima i testovima po defaultu). Ako razvijate, strogo se pridržavajte pravila za IRQL, nestraničnu memoriju i sinhronizaciju sa spin lockovima. Sa pravim alatima (WinDbg, Verifier) ​​​​i pažljivim čitanjem parametara (1, 3 i 4), Ove provjere grešaka više nisu misterija i oni postaju problemi koji se mogu metodično rješavati.