Wat is IRQL (Interrupt Request Level) in Windows en hoe heeft het betrekking op BSOD's?

Als u ooit een blauw scherm hebt gezien met berichten zoals IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NIET_MINDER_OF_GELIJK, bent u waarschijnlijk een concept tegengekomen dat buiten de wereld van drivers weinig bekend is: de IRQL (Interrupt Request Level). In Windows, dit niveau van interruptprioriteit krijgt voorrang op threadprioriteit wanneer het systeem een ​​bepaalde drempelwaarde overschrijdt, en dit heeft directe gevolgen voor de stabiliteit.

In de volgende regels vindt u een complete gids en in het Spaans vanuit Spanje over wat de IRQL is, hoe het werkt, waarom het blauwe schermen veroorzaakt, hoe je het probleem met WinDbg kunt diagnosticeren en wat je moet doen, of je nu een gebruiker bent die de fout ervaart of kernelmodusdrivers ontwikkelt. Laten we aan de slag gaan.

Wat is IRQL (Interrupt Request Level) in Windows?

In Windows, de IRQL definieert de prioriteit van hardware waarop een processor werkt Op elk willekeurig moment. Binnen het Windows Driver Model (WDM) kan code die op een lage IRQL draait, worden onderbroken door code die op een hogere IRQL draait. Sterker nog, op één multi-core computer kan elke CPU een andere IRQL hebben, wat synchronisatie bemoeilijkt.

Er is één belangrijke regel: Wanneer een CPU op een IRQL boven PASSIVE_LEVEL draait, kan deze alleen worden gepreëmpteerd door activiteit op een nog hogere IRQL.Hiermee wordt de co-existentie georganiseerd tussen gebruikerscode, kernelfuncties, uitgestelde aanroepers (DPC's) en apparaatinterruptserviceroutines (ISR's).

Niveaus en prioriteiten: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL en DIRQL

In het algemeen Op x86 worden IRQL-waarden tussen 0 en 31 gebruikt; op x64 tussen 0 en 15De praktische betekenis is hetzelfde: IRQL 0 (PASSIVE_LEVEL) is waar normale gebruikerscode en veel driverfuncties worden uitgevoerd; APC- en paginafouten Ze worden meestal toegewezen aan IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) omvat de threadscheduler en DPC's. Boven DISPATCH_LEVEL bevinden zich niveaus die gereserveerd zijn voor apparaatinterrupts (ook wel DIRQL genoemd) en andere interne toepassingen, zoals HIGH_LEVEL.

In het driver-ecosysteem, Veel voorkomende routines worden uitgevoerd op DISPATCH_LEVEL: bijvoorbeeld DPC en StartIo. Dit ontwerp zorgt ervoor dat terwijl een van beide interne wachtrijen of andere gedeelde bronnen aanraakt, een andere routine op hetzelfde niveau deze niet op die CPU voorrang geeft, omdat de voorrangsregel alleen interrupts op hogere niveaus toestaat.

Tussen DISPATCH_LEVEL en de profilering/hoge niveaus is er ruimte voor de hardware-interrupts van elk apparaat (DIRQL)De IRQL van een apparaat definieert de prioriteit ervan ten opzichte van andere apparaten. Een WDM-driver verkrijgt deze IRQL tijdens IRP_MJ_PNP met IRP_MN_START_DEVICE. Deze IRQL van het apparaat is geen globale, vaste waarde, maar de waarde die aan een specifieke interruptlijn is gekoppeld.

IRQL versus threadprioriteit

Het is raadzaam om de volgende begrippen niet met elkaar te verwarren: De threadprioriteit bepaalt wanneer de scheduler voorrang geeft en welke thread wordt uitgevoerd; de IRQL bepaalt welk type activiteit kan worden uitgevoerd en welke interrupts worden gemaskeerd. Boven DISPATCH_LEVEL is er geen thread-switching: het is de IRQL die bepaalt, niet de threadprioriteit.

IRQL en paging: wat u niet moet doen

Een direct effect van het verhogen van IRQL is dat het systeem kan geen paginafouten verwerkenGouden regel: code die op of boven DISPATCH_LEVEL draait, kan geen paginafouten veroorzaken. In de praktijk betekent dit dat die routines en de data die ze aanraken moet zich in niet-gepagineerd geheugen bevindenBovendien beperken bepaalde kernelhelpers hun gebruik op basis van IRQL: bijvoorbeeld, KeWaitForSingleObject DISPATCH_LEVEL kan alleen worden aangeroepen als u niet blokkeert (time-out nul). Voor time-outs die niet nul zijn, moet u een waarde lager dan DISPATCH_LEVEL hebben.

Impliciete en expliciete controle van IRQL

Meestal, het systeem zelf roept uw ​​routines aan op de juiste IRQL voor wat ze zouden moeten doen. Dispatchroutines voor IRP's draaien op PASSIVE_LEVEL (ze kunnen elke helper blokkeren of aanroepen), StartIo en DPC draaien op DISPATCH_LEVEL om gedeelde wachtrijen te beschermen, en ISR's draaien op DIRQL.

Als u het expliciet wilt beheren, U kunt de IRQL verhogen en verlagen met KeRaiseIrql y KeLowerIrqlEr is een veelgebruikte sneltoets: KeRaiseIrqlToDpcLevel() Retourneert de vorige IRQL en laat u op DISPATCH_LEVEL staan. Belangrijk: verlaag de IRQL nooit onder de waarde die deze had toen het systeem u aanriep; het verbreken van die synchronisatie kan zeer ernstige racewindows veroorzaken.

IRQL-gerelateerde blauwe schermfouten: IRQL_NOT_LESS_OR_EQUAL en DRIVER_IRQL_NOT_LESS_OR_EQUAL

Twee klassieke bugcontroles die met deze problemen gepaard gaan, zijn: IRQL_NIET_MINDER_OF_GELIJK (0xA) y DRIVER_IRQL_NIET_MINDER_OF_GELIJK (0xD1)Beide duiden op een poging om toegang te krijgen tot een paginabaar (of ongeldig) adres met een te hoge IRQL. Dit komt meestal doordat drivers onjuiste adressen gebruiken, onjuiste pointers derefereren of paginabare code op onjuiste niveaus uitvoeren.

In het specifieke geval van DRIVER_IRQL_NIET_MINDER_OF_GELIJK (0x000000D1)De parameters zijn zeer informatief: 1) het geheugenadres waarnaar wordt verwezen; 2) de IRQL op dat moment; 3) het toegangstype (0 keer lezen, 1 keer schrijven, 2/8 keer uitvoeren); 4) het adres van de instructie die naar het geheugen verwijst. Met de debugger kunt u ln op parameter 4 voor Maak een lijst van het dichtstbijzijnde symbool en weet welke functie er actief was.

Veelvoorkomende oorzaken om in gedachten te houden

Naast de specifieke code zijn er patronen die zich herhalen. Het derefereren van een ongeldige pointer naar DISPATCH_LEVEL of hoger Dit is een gegarandeerd recept voor een ramp. Het benaderen van paginabare gegevens op dat niveau, of het uitvoeren van paginabare code (bijvoorbeeld een functie die als paginabaar is gemarkeerd), activeert ook de bugcontrole.

Andere veel voorkomende gevallen zijn: een functie aanroepen in een andere driver die al is gedownload (dangling function pointer), of indirect aangeroepen via een ongeldige functiepointer. Als het systeem een ​​module kan identificeren, zie je vaak de naam ervan op het blauwe scherm zelf, en is deze ook opgeslagen in KiBugCheckDriver, toegankelijk met dx KiBugCheckDriver van WinDbg.

Een praktisch detail: Bij de meeste D1/A is het echte probleem niet de IRQL zelf, maar eerder het gerefereerde geheugenadres. Daarom zijn parameters 1, 3 en 4 cruciaal voor het stellen van de diagnose.

Diagnostiek met WinDbg: nuttige opdrachten en parameteruitlezing

Om aan deze zaken te werken, WinDbg is het belangrijkste hulpmiddel, en als de BSOD vermeldt ntoskrnl.exe Deze informatie biedt veel aanwijzingen over de vraag of de fout zich in het kernelsubsysteem bevindt. Begin met !analyze -v om een ​​samenvatting te krijgen van de bugcheck, de stack en, als je geluk hebt, de betrokken module. Als de dump een capture frame bevat, .trap plaatst u in de context van de defecte CPU.

De commando's van stapel als k, kb, kc, kd, kp, kP, kv Ze laten je verschillende niveaus van backtrace-detail zien. Met ln op parameter 4 kunt u overslaan naar de instructie die naar het geheugen verwees en krijg het dichtstbijzijnde symbool. En als u vermoedt dat het prioriteitsniveau vóór de interrupt actief is, !irql toont u de opgeslagen IRQL voor de doelprocessor (bijv. DISPATCH_LEVEL).

Om de richting van parameter 1 te analyseren, !pool Hier ziet u of het tot een paginapool behoort; !address y !pte Duik in de geheugentoewijzing van dat gebied. Je kunt de geheugenweergave commando's om de inhoud te inspecteren die werd geprobeerd te openen. Ten slotte, u, ub, uu maken het mogelijk om te demonteren rondom het adres van parameter 4.

Vergeet niet lm t n om geladen modules weer te geven y !memusage voor de algemene toestand van het geheugen. Als KiBugCheckDriver heeft iets, dx KiBugCheckDriver De naam van de Unicode-module wordt geretourneerd: in een typisch voorbeeld werd “Wdf01000.sys” gezien als de driver die betrokken was bij de bugcontrole.

Systeemhulpprogramma's: Driver Verifier, Event Viewer en Diagnostiek

El Bestuurderverificatie Onderzoekt het gedrag van drivers in realtime en forceert fouten wanneer het onjuist resourcegebruik (zoals de pool) detecteert, waarbij een uitzondering wordt gegenereerd om het problematische gebied in de code te isoleren. Het wordt gestart met verifier van opdrachtprompt en het is raadzaam om de kleinst mogelijke set drivers te selecteren om te voorkomen dat er teveel overhead ontstaat.

Als je jezelf niet herkent met WinDbg, basismaatregelen toepassenControleer het systeemlogboek in Logboeken op fouten die wijzen op een specifiek apparaat/stuurprogramma; werk het stuurprogramma bij of schakel het uit dat in het blauwe scherm wordt aangegeven; controleer de hardwarecompatibiliteit met uw Windows-versie; en gebruik Windows Geheugendiagnose als u vermoedt dat er RAM-geheugen aanwezig is. Deze acties, hoewel eenvoudig, ze lossen een groot aantal zaken op.

Praktijkvoorbeelden: wanneer BSOD's willekeurig lijken

Een gebruiker met Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti en Gigabyte B450 AORUS PRO WIFI-bord, 16 GB RAM) vertoonde af en toe "IRQL_LESS_OR_NOT_EQUAL"-schermen. Ik had de belangrijkste drivers (netwerk, grafische kaart) al bijgewerkt, alle Windows-updates geïnstalleerd en de geheugentool uitgevoerd, maar dit alles zonder problemen te detecteren.

In scenario's als deze, De volgende stap is het analyseren van dumps met WinDbg en zoek naar patronen: processen die een rol spelen bij het vallen (bijvoorbeeld, explorer.exe), grafische interfacemodules (win32kfull.sys) en functies zoals xxxProcessNotifyWinEvent die in de stack verschijnen. Hoewel deze module Windows is, is de trigger vaak een driver van derden (grafische kaart, invoer, overlay, capture-kaarten) die geheugen gebruikt met een onjuiste IRQL en de fout ontstaat binnen win32k.

De praktische aanbeveling hier is: tijdelijk overlaysoftware uitschakelen (capture, GPU OSD), agressieve software-randapparatuurdrivers (muizen/toetsenborden met macro's) en bètaversies van grafische drivers, en beperk het probleem. Het gebruik van Driver Verifier op verdachte items kan helpen het probleem te beperken met een duidelijkere stack.

Een veelvoorkomend netwerkpatroon: ndis.sys is niet altijd de boosdoener

Nog een typisch geval: screenshot met ndis.sys (de Windows-netwerklaag). Op een echte computer crashte het systeem direct bij het opstarten. De praktische oplossing was om op te starten in Veilige modus zonder netwerkfuncties, open de Apparaatbeheer en schakel adapters uit onder 'Netwerkadapters' om het probleem te isoleren.

In dat team zat een Realtek PCIe GBE Family Controller en een Atheros AR5007GDoor beide uit te schakelen, werd ontdekt dat de werkelijke oorzaak de athrx.sys (Atheros), hoewel het blauwe scherm vermeldde ndis.sysDe dump bevestigde dit: de stapel passeerde ndis!NdisFreeTimerObject maar de schuldige module was athrx.sysDe laatste correctie was verwijder het apparaat en installeer bijgewerkte officiële drivers Van de website van de fabrikant Atheros. Moraal: De module die in de BSOD wordt genoemd, maakt mogelijk deel uit van het getroffen subsysteem, niet van de bron.

Typische ondersteuningsreactie en snelle stappen voor gebruikers

In een echte ondersteuningsuitwisseling antwoordde een technicus: "Mijn excuses voor het ongemak. Het kan een probleem met de driver, het geheugen of het antivirusprogramma zijn. Werk uw drivers bij en voer, als het probleem aanhoudt, de geheugendiagnose uit."Dit is een eenvoudig maar geldig advies. Als de fouten echter blijven bestaan, is het een goed idee om verder te gaan met Verifier en dumpanalyse.

Voor niet-technische gebruikers zou een redelijk protocol zijn: 1) Controleer systeemgebeurtenissen, 2) Werk belangrijke drivers bij (chipset/netwerk/grafische kaart), 3) Controleer RAM met de geïntegreerde tool, 4) test Boot schoon zonder software van derden die hooks in de kernel/GUI invoegt, en 5) Verifier gebruiken op drivers van derden als het niet duidelijk is.

Aanbevolen werkwijzen voor driverontwikkelaars

Als u zich ontwikkelt en u stuit op D1/A, controleer dan of de de lopende routine is niet gemarkeerd als paginabaar Roep geen paginafuncties aan tijdens uitvoering op DISPATCH_LEVEL of hoger. Dit betekent dat verwijzingen naar gegevens in paginasecties moeten worden vermeden en dat de IRQL-beperkingen voor kernelhelpers zoals beschreven in de DDK moeten worden gerespecteerd.

Om gedeelde gegevens te synchroniseren, pas de regel toe "altijd toegang tot gedeelde gegevens met dezelfde hoge IRQL" en gebruik spin locks waar nodig. Op multiprocessors garandeert IRQL alleen geen uitsluiting tussen verschillende CPU's; spin locks verhogen de IRQL (naar DISPATCH_LEVEL) en coördineren de toegang tussen cores. Als u met gevoelige hardwareregisters moet werken, KeSynchronizeExecution helpt u bij het uitvoeren van kritieke secties op de juiste DIRQL.

Wanneer het plan vereist dat de IRQL wordt verhoogd, toepassingen KeRaiseIrqlToDpcLevel voor DISPATCH_LEVEL of KeRaiseIrql voorzichtig, waarbij de vorige IRQL wordt opgeslagen en exact met dezelfde gegevens wordt hersteld KeLowerIrqlGa onder de invoer-IRQL, zelfs voor een moment, Het is een ernstige synchronisatiefout.

Relatie met interrupts en hardware

IRQL is het mechanisme waarmee Windows bestellingen onderbreken prioriteiten en bepaalde interne takenOp architectuurniveau heeft het betrekking op concepten als 'Interrupt', 'Interrupt-handler' of 'Interrupt-prioriteitsniveau' en op klassieke platforms op de Programmeerbare Interrupt Controller (PIC)In andere systemen wordt de prioriteitscontrole uitgedrukt via mechanismen zoals spl en Unix; het algemene idee is hetzelfde: wie mag wie onderbreken.

Geavanceerde debugtips

In stortplaatsen waar de stapel naar wijst win32kfull!xxxProcessNotifyWinEvent met bugcontrole 0xA/0xD1, context inspecteren met .process y .thread (indien beschikbaar), kijk naar processen zoals explorer.exe en !process 0 1 en controleer overlays en GUI-interactiedrivers. Vaak is het probleem Het is een geheugen dat beschadigd is door een derde partij die op die route opduikt.

Vergeet niet de IRQL te controleren met !irql, en contrast: als u zich op DISPATCH_LEVEL (2) bevindt en parameter 3 lezen/schrijven/uitvoeren aangeeft Op een pagina met pagina's heb je al een aanwijzing waarom het is gevallen. Kruis die aanwijzing aan met ln in parameter 4 om de specifieke functie te verkrijgen.

Te begrijpen Wat is de IRQL? en hoe het past in de kerneluitvoering helpt bij het scheiden van ruis van signalen. Als u een gebruiker bent, concentreer u dan op drivers en hardware (standaard met Verifier, gebeurtenissen en tests). Volg bij het ontwikkelen strikt de regels voor IRQL, niet-gepagineerd geheugen en synchronisatie met spinlocks. Met de juiste tools (WinDbg, Verifier) ​​en zorgvuldige uitlezing van parameters (1, 3 en 4), Deze bugcontroles zijn geen mysterie meer. en het worden problemen die methodisch aangepakt kunnen worden.