Čo je IRQL (úroveň požiadavky na prerušenie) v systéme Windows a ako súvisí s BSOD?

Ak ste niekedy videli modrú obrazovku so správami ako IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, pravdepodobne ste sa už stretli s konceptom, ktorý je mimo sveta ovládačov málo známy: IRQL (úroveň požiadavky na prerušenie). WindowsTáto úroveň priority prerušenia má prednosť pred prioritou vlákien, keď systém prekročí určitú prahovú hodnotu, a to má priame dôsledky na stabilitu.

V ďalších riadkoch nájdete una kompletný sprievodca a v španielčine zo Španielska o tom, čo je IRQL a ako funguje, prečo sa zobrazujú modré obrazovky, ako diagnostikovať problém s WinDbg a čo robiť, či už ste používateľ, ktorý má problém, alebo vyvíjate ovládače v režime jadra. Poďme sa pustiť do práce.

Čo je IRQL (úroveň požiadavky na prerušenie) v systéme Windows?

V systéme Windows sa IRQL definuje prioritu technické vybavenie na ktorom procesor pracuje kedykoľvek. V rámci modelu ovládačov systému Windows (WDM) môže byť kód bežiaci s nízkou hodnotou IRQL prerušený kódom bežiacim s vyššou hodnotou IRQL. V skutočnosti môže byť na jednom viacjadrovom počítači každý procesor na inej hodnote IRQL, čo komplikuje synchronizáciu.

Existuje jedno kľúčové pravidlo: Keď CPU beží na úrovni IRQL vyššej ako PASSIVE_LEVEL, môže byť zablokovaný iba aktivitou na ešte vyššej úrovni IRQL.Toto organizuje koexistenciu medzi používateľským kódom, funkciami jadra, odloženými volajúcimi (DPC) a rutinami obsluhy prerušení zariadenia (ISR).

Úrovne a priority: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL a DIRQL

Všeobecne platí, že Na x86 sa používajú hodnoty IRQL medzi 0 a 31; na x64 medzi 0 a 15Praktický význam je rovnaký: IRQL 0 (PASSIVE_LEVEL) je miesto, kde sa vykonáva bežný používateľský kód a mnoho funkcií ovládača; APC a chyby stránky Zvyčajne sú mapované na IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) zahŕňa plánovač vlákien a DPC. Nad DISPATCH_LEVEL sú úrovne vyhradené pre prerušenia zariadení (známe ako DIRQL) a iné interné použitie, ako napríklad HIGH_LEVEL.

V ekosystéme vodičov, Mnoho bežných rutín sa spúšťa na úrovni DISPATCH_LEVEL.napríklad DPC a StartIo. Tento návrh zabezpečuje, že zatiaľ čo jeden z nich sa dotýka interných frontov alebo iných zdieľaných zdrojov, iná rutina na rovnakej úrovni ho na danom CPU neprevezme, pretože pravidlo prevzatia povoľuje prerušenia iba na vyšších úrovniach.

Medzi úrovňou DISPATCH_LEVEL a profilovaním/vysokými úrovňami je priestor pre hardvérové ​​prerušenia každého zariadenia (DIRQL)IRQL zariadenia definuje jeho prioritu oproti iným zariadeniam. Ovládač WDM získa toto IRQL počas IRP_MJ_PNP s IRP_MN_START_DEVICE. Toto IRQL zariadenia nie je globálna, fixná hodnota, ale skôr hodnota spojená s konkrétnou linkou prerušenia.

IRQL verzus priorita vlákna

Je vhodné nezamieňať si pojmy: Priorita vlákna určuje, kedy plánovač preemptuje a ktoré vlákno sa vykoná.; IRQL riadi, aký typ aktivity sa môže vykonať a ktoré prerušenia sú maskované. Nad úrovňou DISPATCH_LEVEL nedochádza k prepínaniu vlákien: riadi ho IRQL, nie priorita vlákien.

IRQL a stránkovanie: Čo by ste nemali robiť

Okamžitým dôsledkom zvýšenia IRQL je, že systém nedokáže spracovať chyby stránkyZlaté pravidlo: kód bežiaci na úrovni DISPATCH_LEVEL alebo vyššej nemôže spôsobiť chyby stránky. V praxi to znamená, že tieto rutiny a údaje, ktorých sa dotýkajú musí sa nachádzať v nestránkovanej pamätiOkrem toho niektoré pomocné programy jadra obmedzujú svoje použitie na základe IRQL: napríklad KeWaitForSingleObject Funkciu DISPATCH_LEVEL je možné volať iba v prípade, že neblokujete (nulový časový limit) a pre nenulové časové limity musíte byť pod úrovňou DISPATCH_LEVEL.

Implicitná a explicitná kontrola IRQL

Väčšinou, systém sám vyvolá vaše rutiny pri správnom IRQL pre to, čo by mali robiť. Dispatch rutiny pre IRP bežia na PASSIVE_LEVEL (môžu blokovať alebo volať ľubovoľného pomocníka), StartIo a DPC bežia na DISPATCH_LEVEL na ochranu zdieľaných frontov a ISR bežia na DIRQL.

Ak to potrebujete explicitne ovládať, IRQL môžete zvýšiť a znížiť pomocou KeRaiseIrql y KeLowerIrqlExistuje veľmi používaná skratka: KeRaiseIrqlToDpcLevel() vráti predchádzajúce IRQL a ponechá vás na úrovni DISPATCH_LEVEL. Dôležité: Nikdy neznižujte IRQL pod hodnotu, na ktorej bol, keď vás systém volal; prerušenie tejto synchronizácie môže viesť k veľmi vážnym problémom s pretekaním.

Chyby modrej obrazovky súvisiace s IRQL: IRQL_NOT_LESS_OR_EQUAL a DRIVER_IRQL_NOT_LESS_OR_EQUAL

Dve klasické kontroly chýb spojené s týmito problémami sú IRQL_NIE_JE_MENEJ_ALEBO_ROVNANÉ (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Obidva hlásia pokus o prístup k stránkovateľnej (alebo neplatnej) adrese s príliš vysokým IRQL. Zvyčajne je to spôsobené ovládačmi používajúcimi nesprávne adresy, dereferencovaním chybných ukazovateľov alebo vykonávaním stránkovateľného kódu na nevhodných úrovniach.

V konkrétnom prípade DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parametre sú veľmi informatívne: 1) adresa odkazovanej pamäte; 2) IRQL v danom čase; 3) typ prístupu (0 čítanie, 1 zápis, 2/8 vykonanie); 4) adresa inštrukcie, ktorá odkazovala na pamäť. Pomocou debuggeru môžete použiť ln na parametri 4 pre vypíšte najbližší symbol a zistite, ktorá funkcia bola spustená.

Bežné príčiny, ktoré treba mať na pamäti

Okrem špecifického kódu existujú aj opakujúce sa vzory. Dereferencovanie neplatného ukazovateľa na úroveň DISPATCH_LEVEL alebo vyššiu Toto je istý recept na katastrofu. Prístup k stránkovateľným údajom na tejto úrovni alebo spustenie stránkovateľného kódu (napr. funkcie označenej ako stránkovateľná) tiež spustí kontrolu chýb.

Medzi ďalšie bežné prípady patria volanie funkcie v inom ovládači, ktorý už bol stiahnutý (visiaci ukazovateľ funkcie) alebo nepriamo vyvolaný prostredníctvom neplatného ukazovateľa funkcie. Ak systém dokáže identifikovať modul, často sa jeho názov zobrazí na modrej obrazovke a je tiež uložený v KiBugCheckDriver, prístupný s dx KiBugCheckDriver z WinDbg.

Praktický detail: Vo väčšine D1/A nie je skutočným problémom samotné IRQL., ale skôr odkazovaná pamäťová adresa. Preto sú parametre 1, 3 a 4 kľúčové pre zameranie diagnózy.

Diagnostika pomocou WinDbg: Užitočné príkazy a čítanie parametrov

Aby sme mohli pracovať na týchto prípadoch, WinDbg je kľúčový nástroja ak BSOD uvádza ntoskrnl.exe Tieto informácie poskytujú veľa návodov, či je chyba v subsystéme jadra. Začnite s !analyze -v aby ste získali súhrn kontroly chýb, zásobník a, ak budete mať šťastie, aj príslušný modul. Ak výpis obsahuje rámec zachytenia, .trap vás zaradí do kontextu zlyhaného procesora.

undefined príkazy hromady ako k, kb, kc, kd, kp, kP, kv Zobrazujú vám rôzne úrovne detailov spätného sledovania. S ln pri parametri 4 môžete preskočiť k inštrukcii, ktorá odkazovala na pamäť a získajte blízky symbol. A ak máte podozrenie, že úroveň priority beží pred prerušením, !irql zobrazuje uložené IRQL pre cieľový procesor (napr. DISPATCH_LEVEL).

Analyzovať smer parametra 1, !pool Povie vám, či patrí do stránkovaného fondu; !address y !pte ponorte sa do mapovania pamäte v danej oblasti. Môžete použiť príkazy na zobrazenie pamäte skontrolovať obsah, ku ktorému sa pokúšalo získať prístup. Nakoniec, u, ub, uu umožňujú vám rozobrať okolo adresy parametra 4.

Nezabudni lm t n zobraziť zoznam načítaných modulov y !memusage pre celkový stav pamäte. Ak KiBugCheckDriver má niečo, dx KiBugCheckDriver Vráti názov modulu Unicode: v typickom príklade bol počas kontroly chýb ako ovládač zapojený „Wdf01000.sys“.

Systémové nástroje: Overovač ovládačov, Prehliadač udalostí a Diagnostika

El Overovač ovládača Skúma správanie ovládačov v reálnom čase a vynúti chyby, keď zistí nesprávne využitie zdrojov (napríklad fondu), pričom vyvolá výnimku na izoláciu problematickej oblasti kódu. Spúšťa sa pomocou verifier z príkazový riadok a je vhodné vybrať čo najmenšiu sadu ovládačov, aby sa predišlo prílišnému zaťaženiu.

Ak sa s WinDbg nenájdete, uplatniť základné opatrenia: Skontrolujte systémový denník v prehliadači udalostí, či neobsahuje chyby odkazujúce na konkrétne zariadenie/ovládač; aktualizujte alebo vypnite ovládač uvedený v modrej obrazovke; overte kompatibilitu hardvéru s vašou verziou systému Windows; a ak máte podozrenie na RAM, použite Diagnostiku pamäte systému Windows. Tieto akcie, hoci sú jednoduché, riešia veľké množstvo prípadov.

Prípady zo skutočného života: Keď sa BSOD zdajú byť náhodné

Používateľ s operačným systémom Windows 10 Pro (procesor AMD Ryzen 5 3400G, GPU NVIDIA GeForce GTX 1660 Ti a základná doska Gigabyte B450 AORUS PRO s Wi-Fi, 16 GB RAM) sa občas zobrazovali obrazovky „IRQL_LESS_OR_NOT_EQUAL“. Už som aktualizoval základné ovládače (sieť, grafika), nainštaloval všetky aktualizácie systému Windows a spustil nástroj na kontrolu pamäte, všetko bez zistených problémov.

V takýchto scenároch, Ďalším krokom je analýza výpisov pomocou WinDbg a hľadajte vzory: procesy, ktoré sa vyskytujú pri jeho páde (napríklad explorer.exe), moduly grafického rozhrania (win32kfull.sys) a funkcie ako napríklad xxxProcessNotifyWinEvent objavujúce sa v zásobníku. Hoci tento modul je pre systém Windows, spúšťačom je často ovládač tretej strany (grafika, vstup, prekrytie, zachytávacie karty), ktorý používa pamäť s nevhodným IRQL a chyba vzniká v rámci win32k.

Praktické odporúčanie je tu dočasne deaktivujte softvér na prekrytie (zachytávanie, OSD GPU), agresívne ovládače softvérových periférií (myši/klávesnice s makrami) a beta verzie grafických ovládačov a zúžte ich. Použitie nástroja Driver Verifier na podozrivých problémoch môže pomôcť zúžiť problém s prehľadnejším zoznamom.

Veľmi bežný sieťový vzorec: ndis.sys nie je vždy vinníkom

Ďalší typický prípad: snímka obrazovky s ndis.sys (sieťová vrstva Windows). Na skutočnom počítači by systém okamžite po spustení havaroval. Praktickým riešením bolo spustenie systému Núdzový režim bez sieťových funkcií otvorte Správca zariadení a vypnite adaptéry v časti „Sieťové adaptéry“, aby ste problém izolovali.

V tom tíme bol Radič rodiny Realtek PCIe GBE a Atheros AR5007GDeaktiváciou oboch sa zistilo, že skutočnou príčinou bola athrx.sys (Atheros), hoci sa na modrej obrazovke spomínalo ndis.sysVýpis to potvrdil: zásobník prešiel cez ndis!NdisFreeTimerObject ale vinný modul bol athrx.sysPosledná korekcia bola odinštalujte zariadenie a nainštalujte aktualizované oficiálne ovládače Z webovej stránky výrobcu Atheros. Ponaučenie: Modul uvedený v BSOD môže byť súčasťou postihnutého subsystému, nie jeho zdrojom.

Typická odpoveď podpory a rýchle kroky pre používateľov

V úprimnej výmene informácií technik odpovedal: „Ospravedlňujem sa za nepríjemnosti. Môže ísť o problém s ovládačom, pamäťou alebo antivírusom. Aktualizujte ovládače a ak problém pretrváva, spustite diagnostiku pamäte.“Toto je základná, ale platná rada; ak však chyby pretrvávajú, je dobré pokračovať s overovačom a analýzou výpisu.

Pre netechnických používateľov by bol rozumný protokol: 1) Skontrolujte systémové udalosti, 2) Aktualizujte kľúčové ovládače (čipová sada/sieť/grafika), 3) Skontrolujte RAM s integrovaným nástrojom, 4) test topánka vyčistiť bez softvéru tretej strany, ktorý vkladá hooky do jadra/GUI, a 5) použiť Verifier na ovládačoch tretej strany, ak nič nie je jasné.

Najlepšie postupy pre vývojárov ovládačov

Ak vyvíjate a narazíte na D1/A, skontrolujte, či spustená rutina nie je označená ako stránkovateľná Nevolajte stránkovateľné funkcie, keď sú spustené na úrovni DISPATCH_LEVEL alebo vyššej. To zahŕňa vyhýbanie sa odkazom na údaje v stránkovaných sekciách a rešpektovanie obmedzení IRQL pre pomocné programy jadra opísané v DDK.

Ak chcete synchronizovať zdieľané údaje, použiť pravidlo „vždy pristupovať k zdieľaným údajom s rovnako vysokou úrovňou IRQL“ a v prípade potreby používajte spin locky. Na multiprocesorových počítačoch samotné IRQL nezaručuje vylúčenie medzi rôznymi CPU; spin locky zvyšujú IRQL (na úroveň DISPATCH_LEVEL) a koordinujú prístup medzi jadrami. Ak potrebujete pracovať s citlivými hardvérovými registrami, KeSynchronizeExecution pomáha vám spustiť kritické sekcie na správnom DIRQL.

Keď plán vyžaduje zvýšenie IRQL, Spojené štáty americké KeRaiseIrqlToDpcLevel pre DISPATCH_LEVEL alebo KeRaiseIrql opatrne, uloženie predchádzajúceho IRQL a jeho obnovenie presne podľa KeLowerIrqlPrejdite pod vstupnú úroveň IRQL, čo i len na okamih, Je to vážna chyba synchronizácie.

Vzťah k prerušeniam a hardvéru

IRQL je mechanizmus, pomocou ktorého systém Windows príkazy narúšajú priority a určité interné úlohyNa architektonickej úrovni súvisí s konceptmi ako „Prerušenie“, „Obsluha prerušení“ alebo „Úroveň priority prerušenia“ a na klasických platformách s Programovateľný ovládač prerušení (PIC)V iných systémoch je riadenie priorít vyjadrené mechanizmami, ako napríklad spl en unix; všeobecná myšlienka je rovnaká: kto môže koho vyrušiť.

Tipy pre pokročilé ladenie

V dumpoch, kde zásobník ukazuje na win32kfull!xxxProcessNotifyWinEvent s kontrolou chýb 0xA/0xD1, skontrolujte kontext pomocou .process y .thread (ak je k dispozícii), pozrite sa na procesy ako explorer.exe en !process 0 1 a skontrolujte prekrytia a ovládače interakcie s grafickým používateľským rozhraním. Problém je často Je to pamäť poškodená treťou stranou, ktorá sa objaví na tejto trase.

Nezabudnite skontrolovať IRQL pomocou !irqla kontrast: ak ste na úrovni DISPATCH_LEVEL (2) a parameter 3 označuje čítanie/zápis/spustenie na stránkovateľnej stránke už máte indíciu, prečo sa zrútila. Preškrtnite túto indíciu s ln v parametri 4, aby ste získali špecifickú funkciu.

rozumieť Čo je IRQL? a ako to zapadá do vykonávania jadra, pomáha oddeliť šum od signálov. Ak ste používateľ, zamerajte sa na ovládače a hardvér (s predvoleným Verifierom, udalosťami a testami). Ak vyvíjate, prísne dodržiavajte pravidlá pre IRQL, nestránkovanú pamäť a synchronizáciu so spin lockmi. So správnymi nástrojmi (WinDbg, Verifier) ​​a starostlivým čítaním parametrov (1, 3 a 4), Tieto kontroly chýb už nie sú záhadou. a stávajú sa problémami, ktoré možno riešiť metodicky.