Was ist IRQL (Interrupt Request Level) in Windows und in welcher Beziehung steht es zu BSODs?

Wenn Sie schon einmal einen blauen Bildschirm mit Meldungen wie IRQL NICHT WENIGER ODER GLEICH o DRIVER_IRQL_NOT_LESS_OR_EQUAL, sind Sie wahrscheinlich schon einmal auf ein Konzept gestoßen, das außerhalb der Welt der Treiber wenig bekannt ist: IRQL (Interrupt Request Level). In Windows, diese Stufe der Interrupt-Priorität hat Vorrang vor der Thread-Priorität, wenn das System einen bestimmten Schwellenwert überschreitet, und dies hat direkte Auswirkungen auf die Stabilität.

In den nächsten Zeilen finden Sie sind eine komplette Anleitung und auf Spanisch aus Spanien darüber, was das IRQL ist, wie es funktioniert, warum es Bluescreens auslöst, wie Sie das Problem mit WinDbg diagnostizieren und was zu tun ist, egal ob Sie ein Benutzer sind, bei dem der Fehler auftritt, oder Kernelmodustreiber entwickeln. Kommen wir zur Sache.

Was ist IRQL (Interrupt Request Level) in Windows?

Unter Windows ist die IRQL definiert die Priorität von Hardware bei der ein Prozessor arbeitet zu jeder Zeit. Innerhalb des Windows-Treibermodells (WDM) kann Code, der mit einem niedrigen IRQL ausgeführt wird, durch Code, der mit einem höheren IRQL ausgeführt wird, unterbrochen werden. Tatsächlich kann auf einem einzelnen Multi-Core-Computer jede CPU einen anderen IRQL aufweisen, was die Synchronisierung erschwert.

Es gibt eine wichtige Regel: Wenn eine CPU mit einem IRQL über PASSIVE_LEVEL läuft, kann sie nur durch Aktivität mit einem noch höheren IRQL vorweggenommen werden.Dadurch wird die Koexistenz zwischen Benutzercode, Kernelfunktionen, Deferred Callers (DPCs) und Device Interrupt Service Routines (ISRs) organisiert.

Ebenen und Prioritäten: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL und DIRQL

Im Allgemeinen Auf x86 werden IRQL-Werte zwischen 0 und 31 verwendet, auf x64 zwischen 0 und 15Die praktische Bedeutung ist dieselbe: IRQL 0 (PASSIVE_LEVEL) ist der Ort, an dem normaler Benutzercode und viele Treiberfunktionen ausgeführt werden; APC- und Seitenfehler Sie werden normalerweise IRQL 1 (APC_LEVEL) zugeordnet; IRQL 2 (DISPATCH_LEVEL) umfasst den Thread-Scheduler und die DPCs. Oberhalb von DISPATCH_LEVEL sind Ebenen für Geräteinterrupts (bekannt als DIRQL) und andere interne Verwendungen wie HIGH_LEVEL reserviert.

Im Fahrer-Ökosystem Viele gängige Routinen laufen auf DISPATCH_LEVEL: beispielsweise DPC und StartIo. Dieses Design stellt sicher, dass, während eine von ihnen interne Warteschlangen oder andere gemeinsam genutzte Ressourcen berührt, eine andere Routine auf derselben Ebene sie auf dieser CPU nicht verdrängt, da die Verdrängungsregel nur Interrupts auf höheren Ebenen zulässt.

Zwischen DISPATCH_LEVEL und den Profiling-/High-Levels gibt es Raum für die Hardware-Interrupts jedes Geräts (DIRQL)Der IRQL eines Geräts definiert dessen Priorität gegenüber anderen Geräten. Ein WDM-Treiber erhält diesen IRQL während IRP_MJ_PNP mit IRP_MN_START_DEVICE. Dieser Geräte-IRQL ist kein globaler, fester Wert, sondern der einer bestimmten Interruptleitung zugeordnete Wert.

IRQL vs. Thread-Priorität

Es ist ratsam, die Konzepte nicht zu verwechseln: Die Thread-Priorität entscheidet, wann der Scheduler preempts und welcher Thread ausgeführt wird; IRQL steuert, welche Aktivitätstypen ausgeführt werden können und welche Interrupts maskiert werden. Oberhalb von DISPATCH_LEVEL gibt es keinen Thread-Wechsel: Es ist IRQL, das steuert, nicht die Thread-Priorität.

IRQL und Paging: Was Sie nicht tun sollten

Eine unmittelbare Auswirkung der Erhöhung von IRQL besteht darin, dass das System kann Seitenfehler nicht verarbeiten. Goldene Regel: Code, der auf oder über DISPATCH_LEVEL läuft, kann keine Seitenfehler verursachen. In der Praxis bedeutet dies, dass diese Routinen und die Daten, die sie berühren muss sich im nicht ausgelagerten Speicher befinden. Darüber hinaus schränken bestimmte Kernel-Helfer ihre Verwendung basierend auf IRQL ein: zum Beispiel KeWaitForSingleObject DISPATCH_LEVEL kann nur aufgerufen werden, wenn Sie nicht blockieren (Timeout Null), und bei Timeouts ungleich Null müssen Sie unter DISPATCH_LEVEL liegen.

Implizite und explizite Kontrolle von IRQL

Die meiste Zeit, Das System selbst ruft Ihre Routinen mit dem richtigen IRQL auf für das, was sie tun sollen. Dispatch-Routinen für IRPs laufen auf PASSIVE_LEVEL (sie können jeden Helfer blockieren oder aufrufen), StartIo und DPC laufen auf DISPATCH_LEVEL, um gemeinsame Warteschlangen zu schützen, und ISRs laufen auf DIRQL.

Wenn Sie es explizit steuern müssen, Sie können den IRQL erhöhen und senken mit KeRaiseIrql y KeLowerIrqlEs gibt eine häufig verwendete Abkürzung: KeRaiseIrqlToDpcLevel() Gibt den vorherigen IRQL zurück und belässt Sie auf DISPATCH_LEVEL. Wichtig: Senken Sie den IRQL niemals unter den Wert, der beim Systemaufruf galt. Eine Unterbrechung dieser Synchronisierung kann zu schwerwiegenden Race Window-Problemen führen.

IRQL-bezogene Bluescreen-Fehler: IRQL_NOT_LESS_OR_EQUAL und DRIVER_IRQL_NOT_LESS_OR_EQUAL

Zwei klassische Fehlerprüfungen im Zusammenhang mit diesen Problemen sind IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Beide weisen auf einen Versuch hin, auf eine auslagerbare (oder ungültige) Adresse mit einem zu hohen IRQL zuzugreifen. Dies liegt normalerweise daran, dass Treiber falsche Adressen verwenden, ungültige Zeiger dereferenzieren oder auslagerbaren Code auf unangemessenen Ebenen ausführen.

Im konkreten Fall von TREIBER_IRQL_NICHT_WENIGER_ODER_GLEICH (0x000000D1), die Parameter sind sehr informativ: 1) referenzierte Speicheradresse; 2) IRQL zu diesem Zeitpunkt; 3) Zugriffstyp (0 Lesen, 1 Schreiben, 2/8 Ausführen); 4) Adresse der Anweisung, die den Speicher referenziert hat. Mit dem Debugger können Sie ln auf Parameter 4 für Listen Sie das nächste Symbol auf und wissen Sie, welche Funktion ausgeführt wurde.

Häufige Ursachen, die Sie im Hinterkopf behalten sollten

Über den spezifischen Code hinaus gibt es Muster, die sich wiederholen. Dereferenzierung eines ungültigen Zeigers auf DISPATCH_LEVEL oder höher Dies ist ein sicheres Rezept für eine Katastrophe. Der Zugriff auf auslagerbare Daten auf dieser Ebene oder die Ausführung auslagerbaren Codes (z. B. einer als auslagerbar gekennzeichneten Funktion) löst ebenfalls die Fehlerprüfung aus.

Andere häufige Fälle sind Rufen Sie eine Funktion in einem anderen Treiber auf, der bereits heruntergeladen wurde (hängender Funktionszeiger) oder indirekt über einen ungültigen Funktionszeiger aufgerufen. Wenn das System ein Modul identifizieren kann, wird dessen Name oft auf dem blauen Bildschirm selbst angezeigt und es wird auch in KiBugCheckDriver, erreichbar mit dx KiBugCheckDriver von WinDbg.

Ein praktisches Detail: In den meisten D1/A ist das eigentliche Problem nicht der IRQL selbst, sondern die referenzierte Speicheradresse. Deshalb sind die Parameter 1, 3 und 4 für die Fokussierung der Diagnose entscheidend.

Diagnose mit WinDbg: Nützliche Befehle und Parameter lesen

Um an diesen Fällen zu arbeiten, WinDbg ist das Schlüsseltool, und wenn der BSOD erwähnt ntoskrnl.exe Diese Informationen geben Aufschluss darüber, ob der Fehler im Kernel-Subsystem liegt. Beginnen Sie mit !analyze -v um eine Zusammenfassung der Fehlerprüfung, des Stacks und, wenn Sie Glück haben, des betroffenen Moduls zu erhalten. Wenn der Dump einen Capture-Frame enthält, .trap versetzt Sie in den Kontext der ausgefallenen CPU.

Die Befehle von Stapel als k, kb, kc, kd, kp, kP, kv Sie zeigen Ihnen verschiedene Ebenen der Backtrace-Details. Mit ln Bei Parameter 4 können Sie überspringen zur Anweisung, die auf den Speicher verwiesen hat und holen Sie sich das nächste Symbol. Und wenn Sie vermuten, dass die Prioritätsstufe vor dem Interrupt läuft, !irql zeigt Ihnen den gespeicherten IRQL für den Zielprozessor (z. B. DISPATCH_LEVEL).

Um die Richtung von Parameter 1 zu analysieren, !pool Es wird Ihnen mitgeteilt, ob es zu einem ausgelagerten Pool gehört. !address y !pte Tauchen Sie ein in die Speicherzuordnung dieses Bereichs. Sie können verwenden die Speicheranzeigebefehle um den Inhalt zu überprüfen, auf den zugegriffen werden sollte. Schließlich u, ub, uu ermöglichen Ihnen die Demontage um die Adresse von Parameter 4.

Vergessen Sie nicht, lm t n um geladene Module aufzulisten y !memusage für den allgemeinen Zustand des Gedächtnisses. Wenn KiBugCheckDriver hat etwas, dx KiBugCheckDriver Es wird der Name des Unicode-Moduls zurückgegeben: In einem typischen Beispiel wurde bei der Fehlerprüfung „Wdf01000.sys“ als der betroffene Treiber erkannt.

Systemtools: Treiberüberprüfung, Ereignisanzeige und Diagnose

El Treiberüberprüfung Untersucht das Verhalten von Treibern in Echtzeit und erzwingt Fehler, wenn eine falsche Ressourcennutzung (z. B. des Pools) erkannt wird. Dabei wird eine Ausnahme ausgelöst, um den problematischen Bereich des Codes zu isolieren. Es wird gestartet mit verifier von Eingabeaufforderung und es ist ratsam, den kleinstmöglichen Treibersatz auszuwählen, um zu viel Overhead zu vermeiden.

Wenn Sie sich mit WinDbg nicht auskennen, grundlegende Maßnahmen anwenden: Überprüfen Sie das Systemprotokoll in der Ereignisanzeige auf Fehler, die auf ein bestimmtes Gerät/einen bestimmten Treiber hinweisen. Aktualisieren oder deaktivieren Sie den im Bluescreen angezeigten Treiber. Überprüfen Sie die Hardwarekompatibilität mit Ihrer Windows-Version. Verwenden Sie die Windows-Speicherdiagnose, wenn Sie RAM vermuten. Diese Aktionen sind zwar einfach, Sie lösen eine große Anzahl von Fällen.

Fälle aus dem echten Leben: Wenn BSODs zufällig erscheinen

Ein Benutzer mit Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA GeForce GTX 1660 Ti und Gigabyte B450 AORUS PRO WIFI-Board, 16 GB RAM) traten zeitweise „IRQL_LESS_OR_NOT_EQUAL“-Bildschirme auf. Ich hatte bereits wichtige Treiber (Netzwerk, Grafik) aktualisiert, alle Windows-Updates installiert und das Speichertool ausgeführt, ohne dass Probleme festgestellt wurden.

In solchen Szenarien Der nächste Schritt ist die Analyse von Dumps mit WinDbg und suchen Sie nach Mustern: Prozesse, die beim Fallen ablaufen (zum Beispiel explorer.exe), grafische Schnittstellenmodule (win32kfull.sys) und Funktionen wie xxxProcessNotifyWinEvent im Stapel angezeigt. Obwohl dieses Modul Windows ist, ist der Auslöser oft ein Treiber eines Drittanbieters (Grafik, Eingabe, Overlay, Capture-Karten), der Speicher mit einem ungeeigneten IRQL verwendet und der Fehler innerhalb auftritt win32k.

Die praktische Empfehlung lautet hier Overlay-Software vorübergehend deaktivieren (Aufnahme, GPU-OSD), aggressive Software-Peripherietreiber (Mäuse/Tastaturen mit Makros) und Betaversionen von Grafiktreibern und grenzen Sie das Problem ein. Die Verwendung von Driver Verifier bei verdächtigen Problemen kann helfen, das Problem mit einem übersichtlicheren Stapel einzugrenzen.

Ein sehr häufiges Netzwerkmuster: ndis.sys ist nicht immer der Übeltäter

Ein weiterer typischer Fall: Screenshot mit ndis.sys (die Windows-Netzwerkschicht). Auf einem echten Computer würde das System sofort beim Start abstürzen. Die praktische Lösung bestand darin, in Abgesicherter Modus ohne Netzwerkfunktionen öffnen Sie die Geräte-Manager und deaktivieren Sie Adapter unter „Netzwerkadapter“, um das Problem einzugrenzen.

In diesem Team gab es einen Realtek PCIe GBE Family Controller und ein Atheros AR5007G. Durch die Deaktivierung beider wurde festgestellt, dass die eigentliche Ursache die athrx.sys (Atheros), obwohl der blaue Bildschirm erwähnt ndis.sysDer Dump bestätigte dies: Der Stapel durchlief ndis!NdisFreeTimerObject aber das schuldige Modul war athrx.sysDie letzte Korrektur war Deinstallieren Sie das Gerät und installieren Sie aktualisierte offizielle Treiber Von der Website des Atheros-Herstellers. Moral: Das im BSOD genannte Modul ist möglicherweise Teil des betroffenen Subsystems, nicht die Quelle.

Typische Support-Antwort und schnelle Schritte für Benutzer

In einem echten Support-Austausch antwortete ein Techniker: „Es tut mir leid für die Unannehmlichkeiten. Es könnte ein Treiber-, Speicher- oder Antivirus-Problem sein. Bitte aktualisieren Sie Ihre Treiber und führen Sie die Speicherdiagnose aus, falls das Problem weiterhin besteht.“Dies ist ein grundlegender, aber gültiger Ratschlag. Wenn die Fehler jedoch weiterhin bestehen, ist es eine gute Idee, mit Verifier und Dump-Analyse weiterzugehen.

Für nicht-technische Benutzer wäre ein sinnvolles Protokoll: 1) Systemereignisse prüfen, 2) Wichtige Treiber aktualisieren (Chipsatz/Netzwerk/Grafik), 3) RAM prüfen mit dem integrierten Tool, 4) testen Starten sauber ohne Drittanbietersoftware, die Hooks in Kernel/GUI einfügt, und 5) verwenden Sie Verifier für Drittanbietertreiber, wenn nichts klar ist.

Best Practices für Treiberentwickler

Wenn Sie bei der Entwicklung auf D1/A stoßen, überprüfen Sie, ob die Die laufende Routine ist nicht als auslagerbar markiert Rufen Sie keine auslagerbaren Funktionen auf, während Sie auf DISPATCH_LEVEL oder höher laufen. Vermeiden Sie dazu Verweise auf Daten in ausgelagerten Abschnitten und beachten Sie die im DDK beschriebenen IRQL-Einschränkungen für Kernel-Helper.

Um freigegebene Daten zu synchronisieren, Wenden Sie die Regel „Auf freigegebene Daten immer mit dem gleichen hohen IRQL zugreifen“ an. und verwenden Sie gegebenenfalls Spinlocks. Auf Multiprozessoren garantiert IRQL allein keinen Ausschluss zwischen verschiedenen CPUs; Spinlocks erhöhen den IRQL (auf DISPATCH_LEVEL) und koordinieren den Zugriff zwischen den Kernen. Wenn Sie sensible Hardwareregister bearbeiten müssen, KeSynchronizeExecution hilft Ihnen, kritische Abschnitte mit dem richtigen DIRQL auszuführen.

Wenn der Plan eine Erhöhung des IRQL erfordert, USA KeRaiseIrqlToDpcLevel für DISPATCH_LEVEL oder KeRaiseIrql vorsichtig, Speichern des vorherigen IRQL und Wiederherstellen genau mit KeLowerIrql. Unterschreiten Sie den Eingabe-IRQL, auch nur für einen Augenblick, Es handelt sich um einen schwerwiegenden Synchronisierungsfehler.

Beziehung zu Interrupts und Hardware

IRQL ist der Mechanismus, mit dem Windows Aufträge unterbrechen Prioritäten und bestimmte interne AufgabenAuf der Architekturebene ist es mit Konzepten wie "Interrupt", "Interrupt-Handler" oder "Interrupt-Prioritätsebene" verbunden und auf klassischen Plattformen mit der Programmierbarer Interrupt-Controller (PIC)In anderen Systemen wird die Prioritätssteuerung durch Mechanismen wie spl en Unix; die Grundidee ist die gleiche: Wer darf wen unterbrechen?

Erweiterte Debugging-Tipps

In Dumps, wo der Stapel auf win32kfull!xxxProcessNotifyWinEvent mit Fehlerprüfung 0xA/0xD1, Kontext prüfen mit .process y .thread (falls verfügbar), schauen Sie sich Prozesse an wie explorer.exe en !process 0 1 und überprüfen Sie Overlays und GUI-Interaktionstreiber. Oftmals das Problem Es handelt sich um einen durch Dritte beschädigten Speicher, der auf diesem Weg auftaucht.

Vergessen Sie nicht, den IRQL mit zu überprüfen !irqlund Kontrast: wenn Sie sich auf DISPATCH_LEVEL (2) befinden und Parameter 3 Lesen/Schreiben/Ausführen anzeigt auf einer paginierbaren Seite haben Sie bereits einen Hinweis darauf, warum es gefallen ist. Kreuzen Sie diesen Hinweis mit ln in Parameter 4, um die spezifische Funktion zu erhalten.

verstehen Was ist IRQL? und wie es in die Kernel-Ausführung passt, hilft, Rauschen von Signalen zu trennen. Wenn Sie ein Benutzer sind, konzentrieren Sie sich auf Treiber und Hardware (standardmäßig mit Verifier, Events und Tests). Beachten Sie bei der Entwicklung strikt die Regeln für IRQL, nicht ausgelagerten Speicher und die Synchronisation mit Spinlocks. Mit den richtigen Tools (WinDbg, Verifier) ​​und sorgfältigem Lesen der Parameter (1, 3 und 4) Diese Fehlerprüfungen sind kein Mysterium mehr und sie werden zu Problemen, die methodisch angegangen werden können.