Kas ir IRQL (pārtraukuma pieprasījuma līmenis) operētājsistēmā Windows un kā tas ir saistīts ar BSOD?

Ja kādreiz esat redzējis zilu ekrānu ar ziņojumiem, piemēram, IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, jūs droši vien esat saskāries ar koncepciju, kas ārpus draiveru pasaules ir mazpazīstama: IRQL (pārtraukuma pieprasījuma līmenis). Windows, šim pārtraukuma prioritātes līmenim ir prioritāte pār pavediena prioritāti, kad sistēma pārsniedz noteiktu slieksni, un tam ir tiešas sekas uz stabilitāti.

Nākamajās rindās jūs atradīsiet una pilnīgs ceļvedis un spāņu valodā no Spānijas par to, kas ir IRQL un kā tas darbojas, kāpēc tas aktivizē zilos ekrānus, kā diagnosticēt problēmu ar WinDbg un ko darīt neatkarīgi no tā, vai esat lietotājs, kas saskaras ar kļūdu, vai arī izstrādājat kodola režīma draiverus. Ķersimies pie lietas.

Kas ir IRQL (pārtraukuma pieprasījuma līmenis) operētājsistēmā Windows?

Operētājsistēmā Windows IRQL definē prioritāti detaļas kurā darbojas procesors jebkurā laikā. Windows draiveru modeļa (WDM) ietvaros kodu, kas darbojas ar zemu IRQL, var pārtraukt kods, kas darbojas ar augstāku IRQL. Faktiski vienā daudzkodolu datorā katram centrālajam procesoram var būt atšķirīgs IRQL, kas sarežģī sinhronizāciju.

Ir viens galvenais noteikums: Kad centrālais procesors darbojas ar IRQL virs PASSIVE_LEVEL, to var apturēt tikai aktivitāte ar vēl augstāku IRQL.Tas organizē lietotāja koda, kodola funkciju, atlikto izsaucēju (DPC) un ierīču pārtraukumu apkalpošanas rutīnu (ISR) līdzāspastāvēšanu.

Līmeņi un prioritātes: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL un DIRQL

Vispār, x86 versijā tiek izmantotas IRQL vērtības no 0 līdz 31; x64 versijā - no 0 līdz 15.Praktiskā nozīme ir tāda pati: IRQL 0 (PASSIVE_LEVEL) ir vieta, kur tiek izpildīts parasts lietotāja kods un daudzas draivera funkcijas; APC un lappušu kļūdas Parasti tie tiek kartēti uz IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) ietver pavedienu plānotāju un DPC. Virs DISPATCH_LEVEL ir līmeņi, kas rezervēti ierīču pārtraukumiem (pazīstami kā DIRQL) un citiem iekšējiem lietojumiem, piemēram, HIGH_LEVEL.

Vadītāju ekosistēmā Daudzas izplatītas rutīnas darbojas DISPATCH_LEVEL līmenīpiemēram, DPC un StartIo. Šis dizains nodrošina, ka, kamēr viens no tiem pieskaras iekšējām rindām vai citiem koplietotiem resursiem, cita rutīna tajā pašā līmenī to neaizliedz šajā centrālajā procesorā, jo atcelšanas noteikums atļauj pārtraukumus tikai augstākos līmeņos.

Starp DISPATCH_LEVEL un profilēšanas/augstajiem līmeņiem ir vieta katras ierīces aparatūras pārtraukumi (DIRQL)Ierīces IRQL nosaka tās prioritāti salīdzinājumā ar citām ierīcēm. WDM draiveris iegūst šo IRQL IRP_MJ_PNP laikā ar IRP_MN_START_DEVICE. Šis ierīces IRQL nav globāla, fiksēta vērtība, bet gan vērtība, kas saistīta ar konkrētu pārtraukuma līniju.

IRQL pret pavediena prioritāti

Nav ieteicams jaukt jēdzienus: Pavediena prioritāte nosaka, kad plānotājs veic iepriekšēju izpildi un kurš pavediens tiek izpildīts.; IRQL kontrolē, kāda veida darbības var izpildīt un kuri pārtraukumi tiek maskēti. Virs DISPATCH_LEVEL pavedienu pārslēgšana nenotiek: to kontrolē IRQL, nevis pavediena prioritāte.

IRQL un lapošana: ko nevajadzētu darīt

IRQL paaugstināšanas tūlītēja ietekme ir tāda, ka sistēma nevar apstrādāt lappušu kļūdasZelta likums: kods, kas darbojas DISPATCH_LEVEL līmenī vai augstāk, nevar izraisīt lapas kļūdas. Praksē tas nozīmē, ka šīs rutīnas un dati, ar kuriem tās saskaras jāatrodas nelapotā atmiņāTurklāt daži kodola palīgi ierobežo to lietošanu, pamatojoties uz IRQL: piemēram, KeWaitForSingleObject DISPATCH_LEVEL var izsaukt tikai tad, ja netiek veikta bloķēšana (nulles taimauts), un, ja taimauts nav nulle, ir jābūt zem DISPATCH_LEVEL.

Netieša un tieša IRQL kontrole

Lielāko daļu laika, pati sistēma izsauc jūsu rutīnas pareizajā IRQL par to, kas viņiem būtu jādara. IRP nosūtīšanas rutīnas darbojas PASSIVE_LEVEL (tās var bloķēt vai izsaukt jebkuru palīgu), StartIo un DPC darbojas DISPATCH_LEVEL, lai aizsargātu koplietotās rindas, un ISR darbojas DIRQL līmenī.

Ja jums tas ir skaidri jākontrolē, Jūs varat paaugstināt un pazemināt IRQL ar KeRaiseIrql y KeLowerIrqlIr ļoti izmantots saīsinājums: KeRaiseIrqlToDpcLevel() atgriež iepriekšējo IRQL un atstāj jūs uz DISPATCH_LEVEL. Svarīgi: Nekad nesamaziniet IRQL zem vērtības, kāda tā bija, kad sistēma jūs izsauca; šīs sinhronizācijas pārtraukšana var atvērt ļoti nopietnus sacensību logus.

Ar IRQL saistītas zilā ekrāna kļūdas: IRQL_NOT_LESS_OR_EQUAL un DRIVER_IRQL_NOT_LESS_OR_EQUAL

Divas klasiskas kļūdu pārbaudes, kas saistītas ar šīm problēmām, ir IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Abi norāda uz mēģinājumu piekļūt lapojamai (vai nederīgai) adresei ar pārāk augstu IRQL. Tas parasti notiek tāpēc, ka draiveri izmanto nepareizas adreses, atceļ atsauces uz sliktiem rādītājiem vai izpilda lapojamu kodu nepiemērotos līmeņos.

Īpašā gadījumā DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parametri ir ļoti informatīvi: 1) atsauces atmiņas adrese; 2) IRQL tajā laikā; 3) piekļuves veids (0 lasīšana, 1 rakstīšana, 2/8 izpilde); 4) instrukcijas adrese, kas atsaucās uz atmiņu. Ar atkļūdotāju var izmantot ln uz 4. parametra uzskaitiet tuvāko simbolu un uzziniet, kāda funkcija darbojās.

Biežākie iemesli, kas jāpatur prātā

Papildus konkrētajam kodam ir arī atkārtoti modeļi. Nederīga rādītāja dereference uz DISPATCH_LEVEL vai augstāku līmeni Šī ir droša katastrofas recepte. Piekļūstot lapojamiem datiem šajā līmenī vai izpildot lapojamu kodu (piemēram, funkciju, kas atzīmēta kā lapojama), arī tiek aktivizēta kļūdu pārbaude.

Citi izplatīti gadījumi ir šādi: izsaukt funkciju citā draiverī, kas jau ir lejupielādēts (karājošs funkcijas rādītājs) vai netieši izsaukts, izmantojot nederīgu funkcijas rādītāju. Bieži vien, ja sistēma spēj identificēt moduli, tā nosaukums tiks parādīts pašā zilajā ekrānā, un tas tiks saglabāts arī KiBugCheckDriver, pieejams ar dx KiBugCheckDriver no WinDbg.

Praktiska detaļa: Vairumā D1/A gadījumu patiesā problēma nav pati IRQL., bet gan atsauces atmiņas adrese. Tāpēc parametri 1, 3 un 4 ir izšķiroši svarīgi diagnozes precizēšanai.

Diagnostika ar WinDbg: noderīgas komandas un parametru lasīšana

Lai strādātu pie šīm lietām, WinDbg ir galvenais rīks, un, ja BSOD piemin Ntoskrnl.exe Šī informācija sniedz daudz norādījumu par to, vai kļūme ir kodola apakšsistēmā. Sāciet ar !analyze -v lai iegūtu kļūdu pārbaudes, steka un, ja paveicas, iesaistītā moduļa kopsavilkumu. Ja izgāztuvē ir iekļauts uztveršanas kadrs, .trap novieto jūs neveiksmīgā centrālā procesora kontekstā.

L komandas no kaudzes kā k, kb, kc, kd, kp, kP, kv Tie parāda dažādus atpakaļizsekošanas detalizācijas līmeņus. Ar ln 4. parametrā varat izlaist uz instrukciju, kas atsaucās uz atmiņu un iegūstiet blakus esošo simbolu. Un, ja jums ir aizdomas, ka prioritātes līmenis darbojas pirms pārtraukuma, !irql parāda saglabāto IRQL mērķa procesoram (piemēram, DISPATCH_LEVEL).

Lai analizētu 1. parametra virzienu, !pool Tas jums pateiks, vai tas pieder lapotajam pūlam; !address y !pte iedziļināties šīs zonas atmiņas kartē. Varat izmantot atmiņas attēlošanas komandas lai pārbaudītu saturu, kuram tika mēģināts piekļūt. Visbeidzot, u, ub, uu ļauj izjaukt ap 4. parametra adresi.

Neaizmirsti lm t n lai uzskaitītu ielādētos moduļus y !memusage par vispārējo atmiņas stāvokli. Ja KiBugCheckDriver ir kaut kas, dx KiBugCheckDriver Tas atgriezīs Unicode moduļa nosaukumu: tipiskā piemērā kļūdu pārbaudes laikā kā iesaistītais draiveris tika uzskatīts “Wdf01000.sys”.

Sistēmas rīki: draiveru verificētājs, notikumu skatītājs un diagnostika

El Vadītāja verificētājs Reāllaikā pārbauda draiveru darbību un piespiež kļūdas, ja konstatē nepareizu resursu (piemēram, pūla) izmantošanu, izraisot izņēmumu, lai izolētu problemātisko koda zonu. Tas tiek palaists ar verifier no komandu uzvedne un ieteicams izvēlēties pēc iespējas mazāku draiveru komplektu, lai izvairītos no pārāk lielas pieskaitāmās slodzes.

Ja neredzat sevi ar WinDbg, piemērot pamata pasākumusPārbaudiet sistēmas žurnālu notikumu skatītājā, vai tajā nav kļūdu, kas norāda uz konkrētu ierīci/draiveri; atjauniniet vai atspējojiet zilā ekrāna norādīto draiveri; pārbaudiet aparatūras saderību ar jūsu Windows versiju; un, ja jums ir aizdomas par RAM, izmantojiet Windows atmiņas diagnostiku. Šīs darbības, lai arī vienkāršas, viņi atrisina lielu skaitu lietu.

Reālās dzīves gadījumi: kad BSOD šķiet nejauši

Lietotājs ar Windows 10 Pro (AMD Ryzen 5 3400G centrālais procesors, GPU NVIDIA GeForce GTX 1660 Ti un Gigabyte B450 AORUS PRO WIFI plate, 16 GB RAM) periodiski parādījās ekrāni "IRQL_LESS_OR_NOT_EQUAL". Es jau biju atjauninājis svarīgākos draiverus (tīkla, grafikas), instalējis visus Windows atjauninājumus un palaidis atmiņas rīku, taču nekādas problēmas netika konstatētas.

Šādos scenārijos Nākamais solis ir analizēt izgāztuves, izmantojot WinDbg un meklēt likumsakarības: procesus, kas notiek, kad tas krīt (piemēram, explorer.exe), grafiskā interfeisa moduļi (win32kfull.sys) un tādas funkcijas kā xxxProcessNotifyWinEvent parādās kaudzē. Lai gan šis modulis ir Windows, trigeris bieži vien ir trešās puses draiveris (grafika, ievade, pārklājums, uztveršanas kartes), kas izmanto atmiņu ar nepiemērotu IRQL, un kļūme rodas iekšā win32k.

Praktisks ieteikums šeit ir šāds īslaicīgi atspējot pārklājuma programmatūru (uztveršana, GPU OSD), agresīvi programmatūras perifērijas draiveri (peles/klaviatūras ar makro) un grafikas draiveru beta versijas, lai sašaurinātu problēmu. Izmantojot draiveru verificētāju aizdomīgajām ierīcēm, var palīdzēt sašaurināt problēmas loku, iegūstot skaidrāku steku.

Ļoti izplatīts tīkla modelis: ndis.sys ne vienmēr ir vaininieks

Vēl viens tipisks gadījums: ekrānuzņēmums ar ndis.sys (Windows tīkla slānis). Reālā datorā sistēma avarētu uzreiz pēc palaišanas. Praktiskais risinājums bija palaist Drošais režīms bez tīkla funkcijām, atveriet Ierīču pārvaldnieks un atspējojiet adapterus sadaļā “Tīkla adapteri”, lai izolētu problēmu.

Tajā komandā bija Realtek PCIe GBE saimes kontrolieris un Atheros AR5007GDeaktivizējot abus, tika atklāts, ka patiesais iemesls bija athrx.sys (Atheros), lai gan pieminētais zilais ekrāns ndis.sysIzgāztuve to apstiprināja: kaudze tika izieta cauri ndis!NdisFreeTimerObject bet vainīgais modulis bija athrx.sysGalīgais labojums bija atinstalējiet ierīci un instalējiet atjauninātos oficiālos draiverus No Atheros ražotāja vietnes. Morāle: BSOD minētais modulis var būt daļa no skartās apakšsistēmas, nevis avots.

Tipiska atbalsta atbilde un ātras darbības lietotājiem

Patiesā atbalsta apmaiņā tehniķis atbildēja: "Atvainojiet par sagādātajām neērtībām. Tā varētu būt draivera, atmiņas vai pretvīrusu problēma. Lūdzu, atjauniniet draiverus un, ja problēma joprojām pastāv, palaidiet atmiņas diagnostiku."Šis ir vienkāršs, bet derīgs padoms; tomēr, ja kļūdas joprojām pastāv, ieteicams veikt papildu pārbaudi, izmantojot verificētāju un izmetes analīzi.

Lietotājiem bez tehniskām zināšanām saprātīgs protokols būtu šāds: 1) Pārbaudiet sistēmas notikumus, 2) Atjauniniet galvenos draiverus (mikroshēmojumu/tīkla/grafikas), 3) Pārbaudiet RAM ar integrēto rīku, 4) pārbaude zābaks 5) tīrīt bez trešās puses programmatūras, kas ievieto āķus kodolā/grafiskajā lietotāja saskarnē, un 6) izmantot Verifier trešo pušu draiveros, ja nekas nav skaidrs.

Draiveru izstrādātāju labākā prakse

Ja jūs veicat izstrādi un nejauši uzduraties D1/A, pārbaudiet, vai Darbojošā rutīna nav atzīmēta kā lapojama Neizsauciet lapojamās funkcijas, kamēr tās darbojas DISPATCH_LEVEL vai augstākā līmenī. Tas ietver atsauču uz datiem lapojamās sadaļās neizvēlēšanos un IRQL ierobežojumu ievērošanu kodola palīgiem, kas aprakstīti DDK.

Lai sinhronizētu koplietotos datus, lietot noteikumu "vienmēr piekļūt koplietotajiem datiem ar tādu pašu augstu IRQL" un, ja nepieciešams, izmantojiet spin lock reģistrus. Vairākprocesoros IRQL vien negarantē izslēgšanu starp dažādiem centrālajiem procesoriem; spin lock paaugstina IRQL līmeni (līdz DISPATCH_LEVEL) un koordinē piekļuvi starp kodoliem. Ja jums ir jādarbojas ar jutīgiem aparatūras reģistriem, KeSynchronizeExecution palīdz izpildīt kritiskās sadaļas ar pareizo DIRQL.

Kad plāns paredz paaugstināt IRQL, lietojumi KeRaiseIrqlToDpcLevel DISPATCH_LEVEL vai KeRaiseIrql uzmanīgi, saglabājot iepriekšējo IRQL un atjaunojot to precīzi ar KeLowerIrqlIet zem ievades IRQL, pat tikai uz brīdi, Tā ir nopietna sinhronizācijas kļūda.

Saistība ar pārtraukumiem un aparatūru

IRQL ir mehānisms, ar kuru Windows rīkojumi pārtrauc prioritātes un noteiktus iekšējos uzdevumusArhitektūras līmenī tas ir saistīts ar tādiem jēdzieniem kā "Pārtraukums", "Pārtraukumu apstrādātājs" vai "Pārtraukuma prioritātes līmenis", un klasiskajās platformās ar Programmējams pārtraukumu kontrolieris (PIC)Citās sistēmās prioritāšu kontrole tiek izteikta, izmantojot tādus mehānismus kā spl en Unix; vispārējā ideja ir tāda pati: kurš var kuru pārtraukt.

Paplašināti atkļūdošanas padomi

Izgāztuvēs, kur kaudze norāda uz win32kfull!xxxProcessNotifyWinEvent ar kļūdu pārbaudi 0xA/0xD1, pārbaudiet kontekstu ar .process y .thread (ja pieejams), apskatiet tādus procesus kā explorer.exe en !process 0 1 un pārbaudiet pārklājumus un grafiskās lietotāja saskarnes draiverus. Bieži vien problēma Tā ir atmiņa, ko sabojājusi trešā persona, kas parādās šajā maršrutā..

Neaizmirstiet pārbaudīt IRQL ar !irqlun kontrasts: ja atrodaties DISPATCH_LEVEL (2) līmenī un 3. parametrs norāda lasīšanu/rakstīšanu/izpildi uz lapojamas lapas jums jau ir pavediens, kāpēc tā ir nokritusi. Pārsvītrojiet šo pavedienu ar ln 4. parametrā, lai iegūtu konkrēto funkciju.

saprast Kas ir IRQL? un kā tas iekļaujas kodola izpildē, palīdz atdalīt troksni no signāliem. Ja esat lietotājs, koncentrējieties uz draiveri un aparatūra (pēc noklusējuma ar Verifier, notikumiem un testiem). Izstrādājot, stingri ievērojiet IRQL, nelapotās atmiņas un sinhronizācijas ar spin locks noteikumus. Izmantojot pareizos rīkus (WinDbg, Verifier) ​​un rūpīgi nolasot parametrus (1, 3 un 4), Šīs kļūdu pārbaudes vairs nav noslēpums. un tās kļūst par problēmām, kuras var risināt metodiski.