Hva er IRQL (Interrupt Request Level) i Windows, og hvordan er det relatert til BSOD-er?

Hvis du noen gang har sett en blåskjerm med meldinger som IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQUAL_NOT_LESS_OR_EQUAL, har du sannsynligvis kommet over et konsept som er lite kjent utenfor sjåførverdenen: IRQL (Interrupt Request Level). Windows, dette nivået av avbruddsprioritet prioriteres over trådprioritet når systemet er over en viss terskel, og dette har direkte konsekvenser for stabiliteten.

I de neste linjene finner du en komplett guide og på spansk fra Spania om hva IRQL er, hvordan det fungerer, hvorfor det utløser blåskjermer, hvordan du diagnostiserer problemet med WinDbg, og hva du skal gjøre enten du er en bruker som opplever feilen eller utvikler kjernemodusdrivere. La oss komme i gang.

Hva er IRQL (avbruddsforespørselsnivå) i Windows?

I Windows, IRQL definerer prioriteten til maskinvare som en prosessor opererer på til enhver tid. Innenfor Windows Driver Model (WDM) kan kode som kjører med lav IRQL avbrytes av kode som kjører med høyere IRQL. Faktisk kan hver CPU på en enkelt flerkjernedatamaskin ha en annen IRQL, noe som kompliserer synkronisering.

Det er én nøkkelregel: Når en CPU kjører på en IRQL over PASSIVE_LEVEL, kan den bare foregripes av aktivitet ved en enda høyere IRQL.Dette organiserer sameksistensen mellom brukerkode, kjernefunksjoner, utsatte innringere (DPC-er) og enhetsavbruddsrutiner (ISR-er).

Nivåer og prioriteringer: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL og DIRQL

Generelt, På x86 brukes IRQL-verdier mellom 0 og 31; på x64, mellom 0 og 15Den praktiske betydningen er den samme: IRQL 0 (PASSIVE_LEVEL) er der vanlig brukerkode og mange driverfunksjoner utføres; APC- og sidefeil De er vanligvis kartlagt til IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) omfatter trådplanleggeren og DPC-ene. Over DISPATCH_LEVEL er nivåer reservert for enhetsavbrudd (kjent som DIRQL) og annen intern bruk som HIGH_LEVEL.

I sjåførøkosystemet, Mange vanlige rutiner kjører på DISPATCH_LEVEL: for eksempel DPC og StartIo. Denne designen sikrer at selv om en av dem berører interne køer eller andre delte ressurser, vil ikke en annen rutine på samme nivå gi den forrang på den CPU-en, fordi forrangsregelen bare tillater avbrudd på høyere nivåer.

Mellom DISPATCH_LEVEL og profilerings-/høynivåene er det plass til maskinvareavbrudd for hver enhet (DIRQL)En enhets IRQL definerer dens prioritet over andre enheter. En WDM-driver henter denne IRQL-en under IRP_MJ_PNP med IRP_MN_START_DEVICE. Denne enhetens IRQL er ikke en global, fast verdi, men snarere verdien som er knyttet til en spesifikk avbruddslinje.

IRQL vs. trådprioritet

Det er tilrådelig å ikke blande sammen konseptene: Trådprioritet bestemmer når planleggeren forhåndsbestemmer og hvilken tråd som kjøres; IRQL kontrollerer hvilken type aktivitet som kan utføres og hvilke avbrudd som maskeres. Over DISPATCH_LEVEL er det ingen trådbytte: det er IRQL som kontrollerer, ikke trådprioriteten.

IRQL og personsøking: Hva du ikke bør gjøre

En umiddelbar effekt av å øke IRQL er at systemet kan ikke håndtere sidefeil. Gylden regel: kode som kjører på eller over DISPATCH_LEVEL kan ikke forårsake sidefeil. I praksis betyr dette at disse rutinene og dataene de berører må ligge i ikke-sideberegnet minneI tillegg begrenser visse kjernehjelpere bruken deres basert på IRQL: for eksempel, KeWaitForSingleObject DISPATCH_LEVEL kan bare kalles hvis du ikke blokkerer (null timeout), og for timeouts som ikke er null, må du være under DISPATCH_LEVEL.

Implisitt og eksplisitt kontroll av IRQL

Mesteparten av tiden, systemet selv starter rutinene dine ved riktig IRQL for hva de burde gjøre. Dispatch-rutiner for IRP-er kjører på PASSIVE_LEVEL (de kan blokkere eller kalle en hvilken som helst hjelper), StartIo og DPC kjører på DISPATCH_LEVEL for å beskytte delte køer, og ISR-er kjører på DIRQL.

Hvis du trenger å kontrollere det eksplisitt, Du kan øke og senke IRQL med KeRaiseIrql y KeLowerIrqlDet finnes en veldig brukt snarvei: KeRaiseIrqlToDpcLevel() returnerer den forrige IRQL-en og lar deg stå på DISPATCH_LEVEL. Viktig: Senk aldri IRQL-en under verdien den hadde da systemet kalte deg opp. Å bryte denne synkroniseringen kan åpne svært alvorlige kappløpsvinduer.

IRQL-relaterte blåskjermfeil: IRQL_NOT_LESS_OR_EQUAL og DRIVER_IRQL_NOT_LESS_OR_EQUAL

To klassiske feilsøkinger knyttet til disse problemene er IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Begge indikerer et forsøk på å få tilgang til en paginerbar (eller ugyldig) adresse med en IRQL som er for høy. Dette skyldes vanligvis at drivere bruker feil adresser, derefererer dårlige pekere eller kjører paginerbar kode på upassende nivåer.

I det spesifikke tilfellet av DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), parameterne er svært informative: 1) referert minneadresse; 2) IRQL på det tidspunktet; 3) tilgangstype (0 lesing, 1 skriving, 2/8 utførelse); 4) adressen til instruksjonen som refererte til minnet. Med feilsøkingsprogrammet kan du bruke ln på parameter 4 for liste opp nærmeste symbol og vite hvilken funksjon som kjørte.

Vanlige årsaker å huske på

Utover den spesifikke koden finnes det mønstre som gjentas. Fjerne referansen til en ugyldig peker til DISPATCH_LEVEL eller høyere Dette er en sikker oppskrift på katastrofe. Tilgang til sidebare data på det nivået, eller kjøring av sidebar kode (f.eks. en funksjon merket som sidebar), utløser også feilsjekken.

Andre vanlige tilfeller inkluderer kall en funksjon i en annen driver som allerede er nedlastet (dinglende funksjonspeker), eller indirekte påkalt via en ugyldig funksjonspeker. Ofte, hvis systemet er i stand til å identifisere en modul, vil du se navnet på selve den blå skjermen, og den er også lagret i KiBugCheckDriver, tilgjengelig med dx KiBugCheckDriver fra WinDbg.

En praktisk detalj: I de fleste D1/A er det virkelige problemet ikke selve IRQL-en, men snarere den refererte minneadressen. Derfor er parameterne 1, 3 og 4 avgjørende for å fokusere diagnosen.

Diagnostikk med WinDbg: Nyttige kommandoer og parameterlesing

For å jobbe med disse sakene, WinDbg er det viktigste verktøyet, og hvis BSOD-en nevner ntoskrnl.exe Denne informasjonen gir mye veiledning om hvorvidt feilen ligger i kjernesystemet. Start med !analyze -v for å få et sammendrag av feilsjekken, stakken og, hvis du er heldig, modulen som er involvert. Hvis dumpen inneholder en opptaksramme, .trap setter deg i kontekst av den defekte CPU-en.

den kommandoer av haug som k, kb, kc, kd, kp, kP, kv De viser deg ulike nivåer av tilbakesporingsdetaljer. Med ln på parameter 4 kan du hoppe over til instruksjonen som refererte til minnet og få symbolet for nærhet. Og hvis du mistenker at prioritetsnivået kjører før avbruddet, !irql viser deg den lagrede IRQL-en for målprosessoren (f.eks. DISPATCH_LEVEL).

For å analysere retningen til parameter 1, !pool Den vil fortelle deg om den tilhører et paginert basseng; !address y !pte fordyp deg i minnekartleggingen av det området. Du kan bruke minnevisningskommandoene å inspisere innholdet som ble forsøkt å få tilgang til. Til slutt, u, ub, uu lar deg demontere rundt adressen til parameter 4.

Ikke glem lm t n for å liste opp lastede moduler y !memusage for den generelle tilstanden til minnet. Hvis KiBugCheckDriver har noe, dx KiBugCheckDriver Den vil returnere navnet på Unicode-modulen: i et typisk eksempel ble «Wdf01000.sys» sett som driveren som var involvert under feilsjekken.

Systemverktøy: Driververifisering, hendelsesvisning og diagnostikk

El Sjåførverifikator Undersøker drivernes oppførsel i sanntid og fremtvinger feil når den oppdager feil ressursbruk (som poolen), og genererer et unntak for å isolere det problematiske området i koden. Den startes med verifier fra ledetekst og det anbefales å velge det minste settet med drivere som mulig for å unngå å legge til for mye overhead.

Hvis du ikke ser for deg at du bruker WinDbg, anvende grunnleggende tiltakSjekk systemloggen i Hendelsesvisning for feil som peker mot en bestemt enhet/driver; oppdater eller deaktiver driveren som det vises på den blå skjermen; bekreft maskinvarekompatibilitet med din Windows-versjon; og bruk Windows Memory Diagnostic hvis du mistenker RAM. Disse handlingene, selv om de er enkle, de løser et stort antall saker.

Ekte tilfeller: Når BSOD-er virker tilfeldige

En bruker 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) opplevde periodiske "IRQL_LESS_OR_NOT_EQUAL"-skjermer. Jeg hadde allerede oppdatert viktige drivere (nettverk, grafikk), installert alle Windows-oppdateringer og kjørt minneverktøyet, alt uten å oppdage noen problemer.

I slike scenarier, Neste steg er å analysere dumpfiler med WinDbg og se etter mønstre: prosesser involvert når den faller (for eksempel, explorer.exe), grafiske grensesnittmoduler (win32kfull.sys) og funksjoner som xxxProcessNotifyWinEvent vises i stakken. Selv om denne modulen er Windows, er utløseren ofte en tredjepartsdriver (grafikk, inndata, overlegg, opptakskort) som bruker minne med en upassende IRQL, og feilen oppstår i win32k.

Den praktiske anbefalingen her er deaktiver overleggsprogramvare midlertidig (opptak, GPU OSD), aggressive programvaredrivere for periferiutstyr (mus/tastaturer med makroer) og betaversjoner av grafikkdrivere, og begrense det. Bruk av Driver Verifier på mistenkte kan bidra til å begrense problemet med en tydeligere stakk.

Et veldig vanlig nettverksmønster: ndis.sys er ikke alltid synderen

Et annet typisk tilfelle: skjermbilde med ndis.sys (Windows-nettverkslaget). På en ekte datamaskin ville systemet krasje umiddelbart ved oppstart. Den praktiske løsningen var å starte opp i Sikker modus uten nettverksfunksjoner, åpne Enhetsbehandling og deaktiver adaptere under «Nettverksadaptere» for å isolere problemet.

I det laget var det en Realtek PCIe GBE-familiekontroller og en Atheros AR5007GVed å deaktivere begge ble det oppdaget at den virkelige årsaken var athrx.sys (Atheros), selv om den blå skjermen nevnt ndis.sysDumpen bekreftet dette: stabelen gikk gjennom ndis!NdisFreeTimerObject men den skyldige modulen var athrx.sysDen endelige korreksjonen var avinstaller enheten og installer oppdaterte offisielle drivere Fra Atheros-produsentens nettsted. Moral: Modulen som er nevnt i BSOD-en kan være en del av det berørte delsystemet, ikke kilden.

Typisk supportrespons og raske trinn for brukere

I en ekte kundestøtteutveksling svarte en tekniker: «Beklager ulempen. Det kan være et problem med driveren, minnet eller antivirusprogrammet. Oppdater driverne, og kjør minnediagnostikken hvis det vedvarer.»Dette er et grunnleggende, men gyldig råd. Hvis feilene vedvarer, er det imidlertid lurt å gå videre med Verifier og dumpanalyse.

For ikke-tekniske brukere ville en rimelig protokoll være: 1) Sjekk systemhendelser, 2) Oppdater viktige drivere (brikkesett/nettverk/grafikk), 3) Sjekk RAM med det integrerte verktøyet, 4) test boot rengjøre uten tredjepartsprogramvare som setter inn kroker i kjernen/GUI, og 5) bruke Verifier på tredjepartsdrivere hvis ingenting er klart.

Beste praksis for driverutviklere

Hvis du utvikler D1/A og snubler over det, sjekk at kjørerutine er ikke merket som sidebar Ikke kall sidevektbare funksjoner mens de kjører på DISPATCH_LEVEL eller høyere. Dette inkluderer å unngå referanser til data i sidevektbare seksjoner og respektere IRQL-begrensningene for kjernehjelpere beskrevet i DDK.

For å synkronisere delte data, bruk regelen «alltid tilgang til delte data med samme høye IRQL» og bruk spinnlåser når det er passende. På flerprosessorer garanterer ikke IRQL alene ekskludering mellom forskjellige CPU-er; spinnlåser hever IRQL (til DISPATCH_LEVEL) og koordinerer tilgang mellom kjerner. Hvis du trenger å operere på sensitive maskinvareregistre, KeSynchronizeExecution hjelper deg med å utføre kritiske seksjoner med riktig DIRQL.

Når planen krever økning av IRQL, usa KeRaiseIrqlToDpcLevel for DISPATCH_LEVEL eller KeRaiseIrql nøye, lagrer den forrige IRQL-en og gjenoppretter den nøyaktig med KeLowerIrqlGå under inngangs-IRQL, selv bare for et øyeblikk, Det er en alvorlig synkroniseringsfeil.

Forholdet mellom avbrudd og maskinvare

IRQL er mekanismen som Windows bruker ordrer forstyrrer prioriteringer og visse interne oppgaverPå arkitekturnivå er det relatert til konsepter som «Avbrudd», «Avbruddshåndterer» eller «Avbruddsprioritetsnivå», og på klassiske plattformer med Programmerbar avbruddskontroller (PIC)I andre systemer uttrykkes prioritetskontroll via mekanismer som spl en Unix; den generelle ideen er den samme: hvem kan avbryte hvem.

Avanserte feilsøkingstips

I dumps der stakken peker til win32kfull!xxxProcessNotifyWinEvent med feilsjekk 0xA/0xD1, inspiser kontekst med .process y .thread (hvis tilgjengelig), se på prosesser som explorer.exe en !process 0 1 og sjekk overlegg og GUI-interaksjonsdrivere. Mange ganger er problemet Det er minne ødelagt av en tredjepart som dukker opp på den ruten.

Ikke glem å sjekke IRQL-en med !irql, og kontrast: hvis du er på DISPATCH_LEVEL (2) og parameter 3 indikerer lese/skrive/utføre På en paginerbar side har du allerede en anelse om hvorfor den har falt. Kryss av den anelsen med ln i parameter 4 for å få den spesifikke funksjonen.

For å forstå Hva er IRQL? og hvordan den passer inn i kjerneutførelsen bidrar til å skille støy fra signaler. Hvis du er en bruker, fokuser på drivere og maskinvare (med Verifier, hendelser og tester som standard). Hvis du utvikler, følg strengt reglene for IRQL, ikke-paged minne og synkronisering med spin locks. Med de riktige verktøyene (WinDbg, Verifier) ​​og nøye lesing av parametere (1, 3 og 4), Disse feilsjekkene er ikke lenger et mysterium og de blir problemer som kan løses metodisk.