Hvad er IRQL (Interrupt Request Level) i Windows, og hvordan hænger det sammen med BSOD'er?

Hvis du nogensinde har set en blå skærm med beskeder som IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, er du sikkert stødt på et koncept, der er mindre kendt uden for driververdenen: IRQL (Interrupt Request Level). Windows, dette niveau af afbrydelsesprioritet har forrang over trådprioritet, når systemet er over en bestemt tærskel, og dette har direkte konsekvenser for stabiliteten.

I de næste linjer finder du en komplet guide og på spansk fra Spanien om hvad IRQL er, og hvordan det fungerer, hvorfor det udløser blå skærme, hvordan man diagnosticerer problemet med WinDbg, og hvad man skal gøre, uanset om man er en bruger, der oplever fejlen, eller udvikler kerneltilstandsdrivere. Lad os komme i gang.

Hvad er IRQL (Interrupt Request Level) i Windows?

I Windows er IRQL definerer prioriteten for hardware hvor en processor opererer på et givet tidspunkt. Inden for Windows Driver Model (WDM) kan kode, der kører ved en lav IRQL, afbrydes af kode, der kører ved en højere IRQL. Faktisk kan hver CPU på en enkelt multi-core computer have en forskellig IRQL, hvilket komplicerer synkronisering.

Der er én nøgleregel: Når en CPU kører ved en IRQL over PASSIVE_LEVEL, kan den kun foregribes af aktivitet ved en endnu højere IRQL.Dette organiserer sameksistensen mellem brugerkode, kernefunktioner, udskudte opkald (DPC'er) og enhedsafbrydelsesservicerutiner (ISR'er).

Niveauer og prioriteter: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL og DIRQL

Generelt På x86 bruges IRQL-værdier mellem 0 og 31; på x64 mellem 0 og 15Den praktiske betydning er den samme: IRQL 0 (PASSIVE_LEVEL) er der, hvor normal brugerkode og mange driverfunktioner udføres; APC- og sidefejl De er normalt knyttet til IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) omfatter trådplanlæggeren og DPC'erne. Over DISPATCH_LEVEL er der niveauer reserveret til enhedsafbrydelser (kendt som DIRQL) og andre interne anvendelser såsom HIGH_LEVEL.

I førerøkosystemet, Mange almindelige rutiner kører på DISPATCH_LEVEL: for eksempel DPC og StartIo. Dette design sikrer, at mens en af ​​dem berører interne køer eller andre delte ressourcer, så vil en anden rutine på samme niveau ikke forudgå den på den CPU, fordi forudgåelsesreglen kun tillader afbrydelser på højere niveauer.

Mellem DISPATCH_LEVEL og profilerings-/højniveauerne er der plads til hardwareafbrydelser for hver enhed (DIRQL)En enheds IRQL definerer dens prioritet over andre enheder. En WDM-driver henter denne IRQL under IRP_MJ_PNP med IRP_MN_START_DEVICE. Denne enheds IRQL er ikke en global, fast værdi, men snarere den værdi, der er knyttet til en specifik afbrydelseslinje.

IRQL vs. trådprioritet

Det er tilrådeligt ikke at forveksle begreber: Trådprioritet bestemmer, hvornår scheduleren forudgår, og hvilken tråd der udføres; IRQL styrer, hvilken type aktivitet der kan udføres, og hvilke afbrydelser der maskeres. Over DISPATCH_LEVEL er der ingen trådskift: det er IRQL, der styrer, ikke trådprioriteten.

IRQL og personsøgning: Hvad du ikke bør gøre

En umiddelbar effekt af at hæve IRQL er, at systemet kan ikke håndtere sidefejlDen gyldne regel: Kode, der kører på eller over DISPATCH_LEVEL, kan ikke forårsage sidefejl. I praksis betyder det, at disse rutiner og de data, de berører, skal være i ikke-sidet hukommelseDerudover begrænser visse kernehjælpere deres brug baseret på IRQL: for eksempel, KeWaitForSingleObject DISPATCH_LEVEL kan kun kaldes, hvis du ikke blokerer (nul timeout), og for timeouts, der ikke er nul, skal du være under DISPATCH_LEVEL.

Implicit og eksplicit kontrol af IRQL

Det meste af tiden, Systemet selv kalder dine rutiner ved den korrekte IRQL for hvad de burde gøre. Dispatch-rutiner for IRP'er kører på PASSIVE_LEVEL (de kan blokere eller kalde enhver hjælper), StartIo og DPC kører på DISPATCH_LEVEL for at beskytte delte køer, og ISR'er kører på DIRQL.

Hvis du har brug for at styre det eksplicit, Du kan hæve og sænke IRQL med KeRaiseIrql y KeLowerIrqlDer er en meget brugt genvej: KeRaiseIrqlToDpcLevel() returnerer den forrige IRQL og efterlader dig på DISPATCH_LEVEL. Vigtigt: Sænk aldrig IRQL'en til under den værdi, den var på, da systemet kaldte dig; at bryde denne synkronisering kan åbne meget alvorlige kapløbsvinduer.

IRQL-relaterede blå skærmfejl: IRQL_NOT_LESS_OR_EQUAL og DRIVER_IRQL_NOT_LESS_OR_EQUAL

To klassiske fejltjek forbundet med disse problemer er IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Begge indikerer et forsøg på at tilgå en sidebar (eller ugyldig) adresse ved en IRQL, der er for høj. Dette skyldes normalt, at drivere bruger forkerte adresser, derefererer dårlige pointere eller udfører sidebar kode på upassende niveauer.

I det konkrete tilfælde af DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parametrene er meget informative: 1) refereret hukommelsesadresse; 2) IRQL på det tidspunkt; 3) adgangstype (0 læsning, 1 skrivning, 2/8 udførelse); 4) adressen på den instruktion, der refererede til hukommelsen. Med debuggeren kan du bruge ln på parameter 4 for angiv det nærmeste symbol og vid, hvilken funktion der kørte.

Almindelige årsager at huske på

Ud over den specifikke kode er der mønstre, der gentages. Dereferering af en ugyldig pointer til DISPATCH_LEVEL eller højere Dette er en sikker opskrift på katastrofe. Adgang til sidebare data på det niveau, eller udførelse af sidebar kode (f.eks. en funktion markeret som sidebar), udløser også fejltjekket.

Andre almindelige tilfælde inkluderer kald en funktion i en anden driver, der allerede er downloadet (dinglende funktionspointer) eller indirekte kaldet via en ugyldig funktionspointer. Ofte, hvis systemet er i stand til at identificere et modul, vil du se dets navn på selve den blå skærm, og det er også gemt i KiBugCheckDriver, tilgængelig med dx KiBugCheckDriver fra WinDbg.

En praktisk detalje: I de fleste D1/A er det egentlige problem ikke selve IRQL'en, men snarere den refererede hukommelsesadresse. Derfor er parametrene 1, 3 og 4 afgørende for at fokusere diagnosen.

Diagnostik med WinDbg: Nyttige kommandoer og parameteraflæsning

For at arbejde med disse sager, WinDbg er det vigtigste værktøj, og hvis BSOD'en nævner Ntoskrnl.exe Disse oplysninger giver en masse vejledning i, om fejlen ligger i kernelsystemet. Start med !analyze -v for at få et resumé af fejltjekket, stakken og, hvis du er heldig, det involverede modul. Hvis dumpen indeholder en capture frame, .trap sætter dig i kontekst af den defekte CPU.

masse kommandoer af bunke som k, kb, kc, kd, kp, kP, kv De viser dig forskellige niveauer af backtrace-detaljer. Med ln På parameter 4 kan du springe over til den instruktion, der refererede til hukommelsen og få symbolet for nærliggende områder. Og hvis du har mistanke om, at prioritetsniveauet kører før afbrydelsen, !irql viser dig den gemte IRQL for målprocessoren (f.eks. DISPATCH_LEVEL).

For at analysere retningen af ​​parameter 1, !pool Den vil fortælle dig, om den tilhører en pagineret pulje; !address y !pte dyk ned i hukommelseskortlægningen af ​​det område. Du kan bruge hukommelsesvisningskommandoerne at inspicere det indhold, der blev forsøgt at få adgang til. Endelig, u, ub, uu giver dig mulighed for at disassemblere omkring adressen på parameter 4.

Glem ikke lm t n for at liste indlæste moduler y !memusage for den generelle hukommelsestilstand. Hvis KiBugCheckDriver har noget, dx KiBugCheckDriver Den returnerer navnet på Unicode-modulet: i et typisk eksempel blev "Wdf01000.sys" set som den involverede driver under fejlkontrollen.

Systemværktøjer: Driververifikator, Event Viewer og Diagnostics

El Chaufførverifikator Undersøger drivernes adfærd i realtid og fremtvinger fejl, når den registrerer forkert ressourceforbrug (f.eks. puljen), og opretter en undtagelse for at isolere det problematiske område i koden. Den startes med verifier fra kommandoprompt og det er tilrådeligt at vælge det mindst mulige sæt drivere for at undgå at tilføje for meget overhead.

Hvis du ikke ser dig selv med WinDbg, anvende grundlæggende foranstaltningerKontrollér systemloggen i Logbogen for fejl, der peger på en bestemt enhed/driver; opdater eller deaktiver den driver, der nævnes på den blå skærm; verificer hardwarekompatibilitet med din version af Windows; og brug Windows Hukommelsesdiagnosticering, hvis du har mistanke om RAM. Disse handlinger er, selvom de er enkle, de løser et stort antal sager.

Eksempler fra det virkelige liv: Når BSOD'er virker tilfældige

En bruger med Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti og Gigabyte B450 AORUS PRO WIFI-kort, 16 GB RAM) oplevede periodiske "IRQL_LESS_OR_NOT_EQUAL"-skærme. Jeg havde allerede opdateret vigtige drivere (netværk, grafik), installeret alle Windows-opdateringer og kørt hukommelsesværktøjet, alt sammen uden at finde nogen problemer.

I scenarier som dette, Det næste trin er at analysere dumps med WinDbg og se efter mønstre: processer involveret, når den falder (for eksempel explorer.exe), grafiske grænseflademoduler (win32kfull.sys) og funktioner som f.eks. xxxProcessNotifyWinEvent vises i stakken. Selvom dette modul er Windows, er udløseren ofte en tredjepartsdriver (grafik, input, overlay, capture-kort), der bruger hukommelse med en upassende IRQL, og fejlen opstår inden for win32k.

Den praktiske anbefaling her er deaktiver midlertidigt overlay-software (optagelse, GPU OSD), aggressive softwaredrivere til periferiudstyr (mus/tastaturer med makroer) og betaversioner af grafikdrivere og indsnævre det. Brug af Driver Verifier på mistænkte systemer kan hjælpe med at indsnævre problemet med en tydeligere stak.

Et meget almindeligt netværksmønster: ndis.sys er ikke altid synderen

Et andet typisk tilfælde: skærmbillede med ndis.sys (Windows-netværkslaget). På en rigtig computer ville systemet gå ned umiddelbart efter opstart. Den praktiske løsning var at starte op i Sikker tilstand uden netværksfunktioner, åbn Enhedshåndtering og deaktiver adaptere under "Netværksadaptere" for at isolere problemet.

I det hold var der en Realtek PCIe GBE Family Controller og en Atheros AR5007GVed at deaktivere begge blev det opdaget, at den egentlige årsag var athrx.sys (Atheros), selvom den blå skærm nævnt ndis.sysLossepladsen bekræftede dette: stakken gik igennem ndis!NdisFreeTimerObject men det skyldige modul var athrx.sysDen endelige korrektion var afinstaller enheden og installer opdaterede officielle drivere Fra Atheros-producentens hjemmeside. Morale: Modulet, der er nævnt i BSOD'en, kan være en del af det berørte delsystem, ikke kilden.

Typisk supportrespons og hurtige trin for brugere

I en oprigtig supportudveksling svarede en tekniker: "Jeg beklager ulejligheden. Det kan være et problem med driveren, hukommelsen eller antivirusprogrammet. Opdater venligst dine drivere, og hvis det fortsætter, så kør hukommelsesdiagnosticeringen."Dette er et grundlæggende, men gyldigt råd; hvis fejlene fortsætter, er det dog en god idé at gå videre med Verifier og dumpanalyse.

For ikke-tekniske brugere ville en rimelig protokol være: 1) Tjek systemhændelser, 2) Opdater nøgledrivere (chipsæt/netværk/grafik), 3) Tjek RAM med det integrerede værktøj, 4) test støvle rens uden tredjepartssoftware, der indsætter hooks i kernen/GUI, og 5) brug Verifier på tredjepartsdrivere, hvis intet er klart.

Bedste praksis for driverudviklere

Hvis du er ved at udvikle D1/A, og du falder over det, skal du kontrollere, at Den kørende rutine er ikke markeret som sidebar Kald ikke sideinddelbare funktioner, mens de kører på DISPATCH_LEVEL eller højere. Dette inkluderer at undgå referencer til data i sideinddelte sektioner og respektere IRQL-begrænsningerne for kernehjælpere, der er beskrevet i DDK.

For at synkronisere delte data, Anvend reglen "altid adgang til delte data med samme høje IRQL" og brug spin-låse, når det er passende. På multiprocessorer garanterer IRQL alene ikke udelukkelse mellem forskellige CPU'er; spin-låse hæver IRQL (til DISPATCH_LEVEL) og koordinerer adgang mellem kerner. Hvis du har brug for at operere på følsomme hardwareregistre, KeSynchronizeExecution hjælper dig med at udføre kritiske sektioner ved den korrekte DIRQL.

Når planen kræver hævning af IRQL, USA KeRaiseIrqlToDpcLevel for DISPATCH_LEVEL eller KeRaiseIrql omhyggeligt, gemmer den tidligere IRQL og gendanner den præcist med KeLowerIrqlGå under input-IRQL'en, selv bare for et øjeblik, Det er en alvorlig synkroniseringsfejl.

Forholdet mellem afbrydelser og hardware

IRQL er den mekanisme, hvormed Windows ordrer afbryder prioriteter og visse interne opgaverPå det arkitektoniske niveau er det relateret til koncepter som "Interrupt", "Interrupt handler" eller "Interrupt priority level" og, på klassiske platforme, med Programmerbar afbrydelsescontroller (PIC)I andre systemer udtrykkes prioritetskontrol via mekanismer som f.eks. SPL en UnixDen overordnede idé er den samme: hvem kan afbryde hvem.

Avancerede fejlfindingstips

I dumps hvor stakken peger på win32kfull!xxxProcessNotifyWinEvent med fejltjek 0xA/0xD1, inspicer kontekst med .process y .thread (hvis tilgængelig), se på processer som explorer.exe en !process 0 1 og tjek overlays og GUI-interaktionsdrivere. Mange gange er problemet Det er hukommelse ødelagt af en tredjepart, der dukker op på den rute..

Glem ikke at tjekke IRQL'en med !irqlog kontrast: hvis du er på DISPATCH_LEVEL (2) og parameter 3 angiver læsning/skrivning/udførelse På en side, der kan sides om, har du allerede en ledetråd til, hvorfor den er faldet. Kryds den ledetråd med ln i parameter 4 for at opnå den specifikke funktion.

forstå Hvad er IRQL? og hvordan det passer ind i kernens udførelse hjælper med at adskille støj fra signaler. Hvis du er bruger, fokuser på drivere og hardware (med Verifier, events og tests som standard). Hvis du udvikler, skal du nøje følge reglerne for IRQL, ikke-sidet hukommelse og synkronisering med spin locks. Med de rigtige værktøjer (WinDbg, Verifier) ​​og omhyggelig læsning af parametre (1, 3 og 4), Disse fejltjek er ikke længere et mysterium. og de bliver til problemer, der kan løses metodisk.