Qu'est-ce que l'IRQL (Interrupt Request Level) dans Windows et quel est son rapport avec les BSOD ?

Si vous avez déjà vu un écran bleu avec des messages comme IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUAL, seguramente te habrás topado con un concepto poco conocido fuera del mundo de los drivers: el IRQL (Interrupt Request Level). En Windows, ce niveau de priorité d'interruption prend le pas sur la priorité du thread lorsque le système est au-dessus d'un certain seuil, ce qui a des conséquences directes sur la stabilité.

Dans les lignes suivantes vous trouverez un guide complet et en espagnol depuis l'Espagne sur ce qu'est l'IRQL, comment il fonctionne, pourquoi cela déclenche des écrans bleus, comment diagnostiquer le problème avec WinDbg et que faire si vous êtes un utilisateur confronté à l'erreur ou si vous développez des pilotes en mode noyau. Passons aux choses sérieuses.

Qu'est-ce que l'IRQL (Interrupt Request Level) dans Windows ?

Sous Windows, le IRQL définit la priorité de matériel auquel un processeur fonctionne À tout moment. Dans le modèle de pilote Windows (WDM), le code exécuté avec un IRQL faible peut être interrompu par du code exécuté avec un IRQL plus élevé. En effet, sur un même ordinateur multicœur, chaque processeur peut avoir un IRQL différent, ce qui complique la synchronisation.

Il y a une règle clé : Lorsqu'un processeur fonctionne à un IRQL supérieur à PASSIVE_LEVEL, il ne peut être préempté que par une activité à un IRQL encore plus élevé.Cela organise la coexistence entre le code utilisateur, les fonctions du noyau, les appelants différés (DPC) et les routines de service d'interruption de périphérique (ISR).

Niveaux et priorités : PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL et DIRQL

D'une manière générale, Sur x86, des valeurs IRQL comprises entre 0 et 31 sont utilisées ; sur x64, entre 0 et 15La signification pratique est la même : IRQL 0 (PASSIVE_LEVEL) est l'endroit où le code utilisateur normal et de nombreuses fonctions du pilote sont exécutés ; APC et défauts de page Ils sont généralement mappés sur l'IRQL 1 (APC_LEVEL) ; l'IRQL 2 (DISPATCH_LEVEL) englobe l'ordonnanceur de threads et les DPC. Au-dessus de DISPATCH_LEVEL se trouvent les niveaux réservés aux interruptions de périphérique (appelées DIRQL) et à d'autres utilisations internes telles que HIGH_LEVEL.

Dans l'écosystème des conducteurs, De nombreuses routines courantes s'exécutent au niveau DISPATCH_LEVELPar exemple, DPC et StartIo. Cette conception garantit que, lorsque l'une d'elles interagit avec des files d'attente internes ou d'autres ressources partagées, une autre routine du même niveau ne la préempte pas sur ce processeur, car la règle de préemption n'autorise que les interruptions de niveaux supérieurs.

Entre DISPATCH_LEVEL et les niveaux de profilage/élevés, il y a de la place pour le interruptions matérielles de chaque périphérique (DIRQL)L'IRQL d'un périphérique définit sa priorité par rapport aux autres périphériques. Un pilote WDM obtient cet IRQL lors d'une interruption IRP_MJ_PNP avec IRP_MN_START_DEVICE. Cet IRQL n'est pas une valeur fixe et globale, mais plutôt la valeur associée à une ligne d'interruption spécifique.

IRQL vs. Priorité des threads

Il convient de ne pas confondre les concepts : La priorité du thread détermine quand le planificateur préempte et quel thread s'exécuteL'IRQL contrôle le type d'activité exécutable et les interruptions masquées. Au-delà de DISPATCH_LEVEL, il n'y a pas de changement de thread : c'est l'IRQL qui contrôle, et non la priorité du thread.

IRQL et pagination : ce que vous ne devriez pas faire

Un effet immédiat de l'augmentation de l'IRQL est que le système ne peut pas gérer les défauts de pageRègle d'or : le code exécuté à un niveau DISPATCH_LEVEL ou supérieur ne peut pas provoquer de défauts de page. En pratique, cela signifie que ces routines et les données qu'elles utilisent doit résider dans une mémoire non paginée. De plus, certains assistants du noyau restreignent leur utilisation en fonction de l'IRQL : par exemple, KeWaitForSingleObject DISPATCH_LEVEL ne peut être appelé que si vous ne bloquez pas (délai d'expiration nul), et pour les délais d'expiration non nuls, vous devez être en dessous de DISPATCH_LEVEL.

Contrôle implicite et explicite de l'IRQL

Le plus souvent, le système lui-même appelle vos routines au bon IRQL Pour ce qu'ils doivent faire. Les routines de répartition des IRP s'exécutent au niveau PASSIVE_LEVEL (elles peuvent bloquer ou appeler n'importe quel assistant), StartIo et DPC s'exécutent au niveau DISPATCH_LEVEL pour protéger les files d'attente partagées, et les ISR s'exécutent au niveau DIRQL.

Si vous avez besoin de le contrôler explicitement, Vous pouvez augmenter et diminuer l'IRQL avec KeRaiseIrql y KeLowerIrqlIl existe un raccourci très utilisé : KeRaiseIrqlToDpcLevel() Renvoie l'IRQL précédent et vous laisse au DISPATCH_LEVEL. Important : Ne jamais abaisser l'IRQL en dessous de la valeur qu'il avait lorsque le système vous a appelé ; une interruption de cette synchronisation peut ouvrir des risques de conflit d'intérêts majeurs.

Erreurs d'écran bleu liées à IRQL : IRQL_NOT_LESS_OR_EQUAL et DRIVER_IRQL_NOT_LESS_OR_EQUAL

Deux vérifications de bogues classiques associées à ces problèmes sont IRQL_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Ces deux cas indiquent une tentative d'accès à une adresse paginable (ou invalide) avec un IRQL trop élevé. Cela est généralement dû à des pilotes utilisant des adresses incorrectes, déréférençant des pointeurs erronés ou exécutant du code paginable à des niveaux inappropriés.

Dans le cas spécifique de DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)Les paramètres sont très instructifs : 1) adresse mémoire référencée ; 2) IRQL à ce moment ; 3) type d’accès (0 lecture, 1 écriture, 2/8 exécution) ; 4) adresse de l’instruction ayant référencé la mémoire. Le débogueur permet d’utiliser ln sur le paramètre 4 pour répertoriez le symbole le plus proche et sachez quelle fonction était en cours d'exécution.

Causes courantes à garder à l'esprit

Au-delà du code spécifique, il existe des modèles qui se répètent. Déréférencement d'un pointeur non valide vers DISPATCH_LEVEL ou supérieur C'est une recette miracle. L'accès aux données paginables à ce niveau, ou l'exécution de code paginable (par exemple, une fonction marquée comme paginable), déclenche également la vérification des bogues.

D’autres cas courants incluent appeler une fonction dans un autre pilote qui a déjà été téléchargé (pointeur de fonction suspendu), ou invoqué indirectement via un pointeur de fonction invalide. Souvent, si le système parvient à identifier un module, son nom apparaît sur l'écran bleu et il est également enregistré dans KiBugCheckDriver, accessible avec dx KiBugCheckDriver de WinDbg.

Un détail pratique : Dans la plupart des D1/A, le véritable problème n’est pas l’IRQL lui-même, mais plutôt l'adresse mémoire référencée. C'est pourquoi les paramètres 1, 3 et 4 sont essentiels pour affiner le diagnostic.

Diagnostic avec WinDbg : commandes utiles et lecture des paramètres

Pour travailler sur ces cas, WinDbg est l'outil clé, et si le BSOD mentionne ntoskrnl.exe Ces informations fournissent de nombreuses indications pour déterminer si l'erreur se situe dans le sous-système du noyau. Commencez par !analyze -v pour obtenir un résumé de la vérification du bug, de la pile et, si vous avez de la chance, du module concerné. Si le dump inclut une image de capture, .trap vous met dans le contexte du CPU défaillant.

Les commandes de pile comme k, kb, kc, kd, kp, kP, kv Ils vous montrent différents niveaux de détail de la trace. Avec ln sur le paramètre 4, vous pouvez sauter à l'instruction qui référençait la mémoire et obtenir le symbole le plus proche. Et si vous suspectez le niveau de priorité avant l'interruption, !irql vous montre l'IRQL enregistré pour le processeur cible (par exemple DISPATCH_LEVEL).

Pour analyser la direction du paramètre 1, !pool Il vous indiquera s'il appartient à un pool paginé ; !address y !pte approfondir la cartographie mémoire de cette zone. Vous pouvez utiliser les commandes d'affichage de la mémoire pour inspecter le contenu auquel on a tenté d'accéder. Enfin, u, ub, uu permet de désassembler autour de l'adresse du paramètre 4.

Ne pas oublier lm t n pour lister les modules chargés y !memusage pour l'état général de la mémoire. Si KiBugCheckDriver a quelque chose, dx KiBugCheckDriver Il renverra le nom du module Unicode : dans un exemple typique, « Wdf01000.sys » a été vu comme le pilote impliqué lors de la vérification des bogues.

Outils système : Vérificateur de pilotes, Observateur d'événements et Diagnostics

El Vérificateur de pilote Analyse le comportement des pilotes en temps réel et génère des erreurs lorsqu'une utilisation incorrecte des ressources (comme le pool) est détectée, ce qui génère une exception pour isoler la zone problématique du code. L'exécution est effectuée avec verifier dès symbole du système et il est conseillé de sélectionner le plus petit ensemble de pilotes possible pour éviter d'ajouter trop de surcharge.

Si vous ne vous voyez pas avec WinDbg, appliquer des mesures de baseConsultez le journal système dans l'Observateur d'événements pour détecter les erreurs liées à un périphérique/pilote spécifique ; mettez à jour ou désactivez le pilote indiqué par l'écran bleu ; vérifiez la compatibilité matérielle avec votre version de Windows ; et utilisez le Diagnostic mémoire Windows si vous suspectez une défaillance de la RAM. Ces actions, bien que simples, ils résolvent un grand nombre de cas.

Cas réels : lorsque les BSOD semblent aléatoires

Un utilisateur avec Windows 10 Pro (processeur AMD Ryzen 5 3400G, GPU NVIDIA Carte graphique GeForce GTX 1660 Ti et Gigabyte B450 AORUS PRO WIFI(16 Go de RAM) rencontrait des écrans intermittents « IRQL_LESS_OR_NOT_EQUAL ». J'avais déjà mis à jour les pilotes essentiels (réseau, carte graphique), installé toutes les mises à jour Windows et exécuté l'outil de gestion de la mémoire, sans aucun problème détecté.

Dans des scénarios comme celui-ci, L'étape suivante consiste à analyser les vidages avec WinDbg et recherchez des modèles : des processus impliqués lorsqu'il tombe (par exemple, explorer.exe), modules d'interface graphique (win32kfull.sys) et des fonctions telles que xxxProcessNotifyWinEvent apparaissant dans la pile. Bien que ce module soit Windows, le déclencheur est souvent un pilote tiers (carte graphique, d'entrée, de superposition, de capture) qui utilise la mémoire à un niveau d'interruption (IRQL) inapproprié, et l'erreur survient dans win32k.

La recommandation pratique ici est désactiver temporairement le logiciel de superposition (capture, OSD GPU), pilotes de périphériques logiciels agressifs (souris/claviers avec macros) et versions bêta des pilotes graphiques, et affiner la recherche. Utiliser Driver Verifier sur les suspects peut aider à cerner le problème avec une pile plus claire.

Un modèle de réseau très courant : ndis.sys n'est pas toujours le coupable

Un autre cas typique : capture d'écran avec ndis.sys (la couche réseau Windows). Sur un ordinateur réel, le système plantait immédiatement au démarrage. La solution pratique consistait à démarrer dans Mode sans échec sans fonctions réseau, ouvrez le Administrateur de l'appareil et désactivez les adaptateurs sous « Adaptateurs réseau » pour isoler le problème.

Dans cette équipe, il y avait un Contrôleur de la famille Realtek PCIe GBE et un Atheros AR5007G. En désactivant les deux, il a été détecté que la véritable cause était la athrx.sys (Atheros), bien que l'écran bleu mentionné ndis.sysLe vidage a confirmé cela : la pile est passée à travers ndis!NdisFreeTimerObject mais le module coupable était athrx.sysLa correction finale a été désinstaller l'appareil et installer les pilotes officiels mis à jour Extrait du site web du fabricant d'Atheros. Moralité : le module cité dans l'écran bleu de la mort pourrait faire partie du sous-système affecté, et non de la source.

Réponse d'assistance typique et étapes rapides pour les utilisateurs

Lors d'un véritable échange d'assistance, un technicien a répondu : Veuillez nous excuser pour la gêne occasionnée. Il pourrait s'agir d'un problème de pilote, de mémoire ou d'antivirus. Veuillez mettre à jour vos pilotes et, si le problème persiste, exécutez le diagnostic mémoire.Il s'agit d'un conseil basique mais valable ; cependant, si les erreurs persistent, c'est une bonne idée d'aller plus loin avec Verifier et l'analyse du vidage.

Pour les utilisateurs non techniques, un protocole raisonnable serait : 1) Vérifier les événements système, 2) Mettre à jour les pilotes clés (chipset/réseau/graphiques), 3) Vérifier la RAM avec l'outil intégré, 4) test Botte nettoyer sans logiciel tiers qui insère des hooks dans le noyau/l'interface graphique, et 5) utiliser Verifier sur les pilotes tiers si rien n'est clair.

Bonnes pratiques pour les développeurs de pilotes

Si vous développez et que vous tombez sur D1/A, vérifiez que le la routine en cours d'exécution n'est pas marquée comme paginable N'appelez pas de fonctions paginables lors d'une exécution au niveau DISPATCH_LEVEL ou supérieur. Cela implique d'éviter les références aux données des sections paginées et de respecter les restrictions IRQL pour les assistants du noyau décrites dans le DDK.

Pour synchroniser les données partagées, appliquer la règle « toujours accéder aux données partagées au même IRQL élevé » et utilisez des verrous de rotation si nécessaire. Sur les multiprocesseurs, l'IRQL seul ne garantit pas l'exclusion entre les différents processeurs ; les verrous de rotation augmentent l'IRQL (à DISPATCH_LEVEL) et coordonnent l'accès entre les cœurs. Si vous devez opérer sur des registres matériels sensibles, KeSynchronizeExecution vous aide à exécuter les sections critiques au bon DIRQL.

Lorsque le plan nécessite d'augmenter l'IRQL, USA KeRaiseIrqlToDpcLevel pour DISPATCH_LEVEL ou KeRaiseIrql avec prudence, en sauvegardant l'IRQL précédent et en le restaurant exactement avec KeLowerIrql. Allez en dessous de l'IRQL d'entrée, même pour un instant, C'est une grave erreur de synchronisation.

Relation avec les interruptions et le matériel

IRQL est le mécanisme par lequel Windows les commandes interrompent les priorités et certaines tâches internesAu niveau architectural, il est lié à des concepts tels que « Interruption », « Gestionnaire d'interruption » ou « Niveau de priorité d'interruption » et, sur les plateformes classiques, à la Contrôleur d'interruption programmable (PIC)Dans d’autres systèmes, le contrôle des priorités s’exprime via des mécanismes tels que spl en Unix; l'idée générale est la même : qui peut interrompre qui.

Conseils de débogage avancés

Dans les vidages vers lesquels pointe la pile win32kfull!xxxProcessNotifyWinEvent avec vérification de bogue 0xA/0xD1, inspecter le contexte avec .process y .thread (si disponible), regardez des processus comme explorer.exe en !process 0 1 et vérifier les superpositions et les pilotes d'interaction de l'interface utilisateur graphique. Souvent, le problème C'est une mémoire corrompue par un tiers qui émerge sur cette route.

N'oubliez pas de vérifier l'IRQL avec !irql, et contraste : si vous êtes à DISPATCH_LEVEL (2) et que le paramètre 3 indique lecture/écriture/exécution Sur une page paginable, vous avez déjà un indice sur la raison de sa chute. Croisez cet indice avec ln dans le paramètre 4 pour obtenir la fonction spécifique.

comprendre Qu'est-ce que l'IRQL ? et la façon dont il s'intègre à l'exécution du noyau permet de distinguer le bruit des signaux. Si vous êtes un utilisateur, concentrez-vous sur pilotes et matériel (avec Verifier, événements et tests par défaut). Si vous développez, respectez scrupuleusement les règles d'IRQL, de mémoire non paginée et de synchronisation avec verrous rotatifs. Avec les bons outils (WinDbg, Verifier) ​​et une lecture attentive des paramètres (1, 3 et 4), Ces vérifications de bugs ne sont plus un mystère et ils deviennent des problèmes qui peuvent être traités méthodiquement.