Vision irql ni inférieur ni égal dans Windows 10/11, cela signifie généralement qu'un pilote du noyau (ou Windows lui-même) a essayé de toucher à la mémoire qu'il n'avait pas à toucher alors qu'il s'exécutait à un niveau de priorité trop « élevé » pour ce type d'accès à la mémoire.
En termes simples, un conducteur s'est impatienté, a fouillé dans le mauvais tiroir et Windows a freiné avec un BSOD. Pour la plupart des gens, le correctif est axé sur le pilote (réseau, GPU, chipset, VPN, logiciel de sécurité), avec une vérification rapide de la réalité de la RAM et de l'état des fichiers système. Les propres conseils de Microsoft en cas d'erreur 0xA désigne les conducteurs et la mémoire comme les suspects habituels.
Ce que signifie le code d'arrêt : IRQL ni signification inférieure ni égale
Windows dispose d'un système de priorité pour les interruptions appelé IRQL (Niveau de demande d'interruption). Avec un IRQL plus élevé, Windows bloque certaines actions car elles ne peuvent pas faire de pause en toute sécurité, paginer la mémoire à partir du disque ou attendre.
Ainsi, si un conducteur tente d'accéder paginé mémoire lors de l'exécution avec un IRQL élevé, Windows le traite comme si quelqu'un essayait de s'arrêter au milieu d'une autoroute. Ce n’est pas seulement lent, c’est dangereux pour le système, donc vous vous arrêtez.
Microsoft décrit la vérification des bogues 0xA comme Windows ou un pilote de noyau accédant à la mémoire paginée à une adresse non valide alors que l'IRQL est élevé, généralement en raison d'un mauvais pointeur ou d'un problème de pagination. La propre liste de contrôle 0xA de Microsoft est un bon contrôle de cohérence si vous voulez la référence officielle.
Deux points pratiques à retenir pour irql ni inférieur ni égal:
- Un pilote est le coupable préféré, même si la ligne « Qu'est-ce qui a échoué » pointe vers quelque chose qui semble appartenir à Microsoft.
- Les problèmes de RAM peuvent imiter des problèmes de pilote, nous testons donc la mémoire, mais nous ne commençons pas par acheter de nouvelles clés.
Liste de contrôle de tri rapide pour IRQL ni inférieur ni égal à Windows 10 et 11
Avant les balles, tu devrais savoir que irql pas moins ou égal à Windows les plantages ont tendance à être déclenchés par un chemin de pilote actif en cas de charge, de jeu, de téléchargements volumineux, d'activité USB importante, d'utilisation d'un VPN ou de sortie de veille.
Cette liste de contrôle est le chemin « obtenir d'abord la stabilité » pour irql ni inférieur ni égal, et il couvre également le cousin commun, 0xD1. Assurez-vous de le faire dans l'ordre.
Faites ceci maintenant (dans l'ordre) :
- Débranchez le matériel USB non essentiel (dock, interface audio, carte de capture, contrôleur, disque externe), puis redémarrez et essayez de reproduire le crash.
- Annulez tout profil d'overclocking, d'undervolt, de réglage XMP/EXPO ou de « turbo de jeu » dans le BIOS/UEFI, puis testez à nouveau.
- Mettez entièrement à jour Windows, y compris Mises à jour facultatives dans Windows Update, car ceux-ci contiennent souvent des mises à jour de pilotes liées à votre matériel.
- Mettez à jour le pilote GPU du fournisseur du GPU et mettez à jour le pilote Wi-Fi/Ethernet du fournisseur de l'ordinateur portable/de la carte mère.
- Exécutez le diagnostic de la mémoire Windows et, si vous le pouvez, effectuez ultérieurement un test de RAM plus long (détails ci-dessous).
- Si l'écran de crash indique DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1), passez directement à Correction des étapes pour 0xD1 section et concentrez-vous sur l’isolement du conducteur fautif.
Cela vous sort du piège des « changements aléatoires » et vous engage dans un processus reproductible, ce qui est important car la prochaine étape consiste à collecter des indices.
Obtenez des indices utiles avant de changer des choses
Les vraies personnes qui dépannent ces BSOD sur les forums ont tendance à demander tout de suite la même chose : « Avez-vous des fichiers de vidage ? parce que les suppositions coûtent cher.
Pour irql ni inférieur ni égal et bsod irql_not_less_or_equal, les indices résident généralement dans :
- C:\Windows\Minidump
- C:\Windows\MEMOIRE.DMP (plus grand, pas toujours présent)
Commencez par les petits.
Étapes (rapides et sûres) :
- Presse Gagner + R, taper C:\Windows\Minidump, appuyez sur Entrée.
- Copiez le plus récent .dmp fichiers sur votre bureau.
- Zippez-les.
- Ouvrir Observateur d'événements → Journaux Windows → Système et recherchez les entrées critiques autour du moment du crash (ce n'est souvent pas « la réponse », mais cela aide à confirmer les tendances).
Si WinDbg n’est pas déjà installé, Page d'installation de Microsoft est le chemin le plus rapide.
Une note sur la ligne « Qu'est-ce qui a échoué » : des fichiers comme Wdf01000.sys apparaissent souvent dans les rapports de la communauté, mais cela peut être le cadre sur lequel repose le véritable pilote de buggy. Les gens voient cela et supposent que « Windows est en panne », puis ils réinstallent et le crash revient.
Désormais, une fois que vous avez au moins un vidage et une idée approximative du moment où cela se produit, les correctifs ciblent votre problème exact.
Étapes de correction pour 0xA : IRQL ni correction inférieure ni égale dans un ordre sûr
Cette section est le runbook principal pour irql ni inférieur ni égal (0xA). C’est aussi une base solide pour irql pas moins ou égal à Windows des crashs qui ne nomment pas de pilote clair.
Étape 1 : annuler la dernière modification ayant touché les pilotes ou le matériel
Commencez par énumérer ce qui a changé au cours des 1 à 2 dernières semaines :
- Nouveau périphérique USB, station d'accueil, casque, contrôleur
- Nouveau GPU, carte Wi-Fi, RAM
- Nouveau VPN, antivirus, « mise à jour du pilote », utilitaire RVB
Ensuite, supprimez ou désinstallez cette modification et testez à nouveau. Si vous pouvez reproduire le crash (même jeu, même téléchargement, même veille/réveil), vous le faites correctement.
Étape 2 : Mettre à jour les pilotes comme les gens l’oublient
Une réponse très courante sur les forums est « ne mettez pas à jour via le Gestionnaire de périphériques ». Ce n’est pas du snobisme. Le Gestionnaire de périphériques indique souvent « meilleur pilote déjà installé » alors que vous utilisez un pilote de fournisseur obsolète.
Pour irql ni inférieur ni égal, priorisez :
- Jeu de puces pilote (fournisseur de carte mère/ordinateur portable)
- Wi-Fi/Ethernet pilote (site fournisseur, non générique)
- GPU pilote (option d'installation propre du fournisseur si disponible)
- Stockage pilotes (mises à jour du contrôleur NVMe si votre OEM les fournit)
Si le crash a commencé juste après une mise à jour du pilote, il est juste de restaurer ce pilote spécifique, mais faites-le de manière chirurgicale. Une restauration complète du système peut masquer le déclencheur réel.
Étape 3 : utiliser correctement Windows Update (y compris les mises à jour facultatives)
Microsoft appelle explicitement la mise à jour des pilotes et l'installation des mises à jour comme étapes de première ligne en cas d'erreur 0xA.
Windows 11 (mises à jour facultatives du pilote) :
- Démarrer → Paramètres → Mise à jour Windows
- Options avancées
- Sous « Options supplémentaires », sélectionnez Mises à jour facultatives
- Ouvrir Mises à jour des pilotes, cochez ce que vous voulez, sélectionnez Téléchargez et installez
- Retourne à Mise à jour Windows et courir Vérifier les mises à jour
Windows 10 (mises à jour facultatives du pilote) :
- Démarrer → Paramètres → Mise à jour et sécurité → Mise à jour Windows
- Sélectionner Afficher les mises à jour facultatives (cela apparaît lorsque des mises à jour facultatives existent)
- Ouvrir Mises à jour des pilotes, cochez ce que vous voulez, sélectionnez Téléchargez et installez
Les mises à jour facultatives contiennent une quantité surprenante de correctifs de pilotes « silencieux ». Si les plantages se calment après les mises à jour, nous effectuons généralement une passe de nettoyage rapide afin que la machine n'exécute pas cinq plateaux et superpositions de fournisseurs au démarrage. Cette liste de contrôle est solide : Comment accélérer Windows 10.
Étape 4 : Vérifiez la mémoire sans tirer de conclusions hâtives
Oui, la mémoire peut déclencher irql ni inférieur ni égal, et Microsoft pointe vers les vérifications de la RAM dans le cadre du chemin du correctif.
Faites cela en couches :
- Courir Diagnostic de la mémoire Windows d'abord.
- Si le problème persiste, effectuez un test de RAM plus long plus tard (la nuit est idéale) à l'aide d'un testeur amorçable fiable.
Aussi : si XMP/EXPO était activé, désactivez-le pendant les tests. De nombreux profils à la limite de la stabilité échouent uniquement dans des conditions spécifiques nécessitant de nombreuses interruptions.
Étape 5 : Réparer les fichiers système
Les fichiers système corrompus peuvent rendre le dépannage du pilote bruyant. C'est ici SFC et DISM aide.
Exécutez-les dans Invite de commandes (administrateur):
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
Si DISM échoue ou nécessite une source ISO, notre guide sur la réparation des images Windows avec DISM est une bonne référence étape par étape : Commande DISM RestoreHealth : réparer l'image Windows.
Si vous recevez un mélange de codes d'arrêt pendant que vous dépannez les pilotes, ce runbook utilise la même boîte à outils de réparation et est pratique à conserver à proximité : Comment réparer l'échec du contrôle de sécurité du noyau.
Cette étape chevauche également le type de nettoyage qui peut aider à l'instabilité générale, pas seulement irql ni inférieur ni égal.
Étape 6 : Démarrage propre pour détecter les effets secondaires des pilotes tiers
Si vous soupçonnez un outil en arrière-plan (VPN, antivirus, RGB, contrôle des ventilateurs, « optimiseur de réseau ») :
- Courir msconfig
- Masquer les services Microsoft
- Désactivez le reste
- Désactivez les applications de démarrage dans le Gestionnaire des tâches
- Redémarrer et retester
Si le crash disparaît, réactivez-le par lots jusqu'à ce que le délinquant se manifeste.
Étape 7 : mise à jour du BIOS/UEFI, mais seulement après ce qui précède
Les mises à jour du BIOS peuvent corriger de véritables bugs de compatibilité, mais elles peuvent également ajouter du bruit au dépannage. Faites-les après avoir exclu les gains faciles.
À ce stade, la plupart irql ni inférieur ni égal les cas s’arrêtent complètement ou se limitent à une seule catégorie de conducteurs. Si votre écran bleu est 0xD1, la section suivante est votre itinéraire le plus rapide.
0xA vs 0xD1 : pourquoi DRIVER_IRQL ni moins ni égal semble similaire
Si vous avez vu les deux irql ni inférieur ni égal et DRIVER_IRQL_NOT_LESS_OR_EQUAL, vous ne l'imaginez pas. Ils partagent le même thème « mauvaise mémoire avec un mauvais IRQL », mais 0xD1 est plus explicitement en forme de pilote, et Microsoft documente 0xD1 en détail ici.
Microsoft 0xD1 La définition est simple : un pilote en mode noyau a tenté d'accéder à la mémoire paginable avec un IRQL trop élevé.
Voici la différence détaillée et orientée vers les correctifs que vous devrez effectuer :
| Vérification des bogues | Ce que vous voyez habituellement | Ce à quoi cela indique habituellement | Meilleur premier coup |
| 0xA (IRQL_NOT_LESS_OR_EQUAL) | « Ce qui a échoué » peut être vague | Bogue du pilote, instabilité de la RAM ou corruption au niveau du système | Mises à jour des pilotes + suppression du matériel récent + test de mémoire |
| 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) | Nomme souvent un fichier de pilote spécifique | Un chemin de pilote tiers spécifique se comporte mal | Identifiez le pilote à partir des dumps, puis mettez à jour/restaurez, puis Driver Verifier |
En d’autres termes : traiter irql ni inférieur ni égal comme « le conducteur d'abord, puis la mémoire » et traitez 0xD1 comme « quel pilote, en particulier ? »
Étapes de correction pour 0xD1 : DRIVER_IRQL_NOT_LESS_OR_EQUAL
Il s’agit de la piste « le conducteur est coupable jusqu’à preuve du contraire ». Si votre écran ou votre dump indique code d'arrêt irql_not_less_or_equal mais la vérification des bugs est 0xD1, traitez-le comme un travail d'isolation du conducteur.
Microsoft 0xD1 le texte est clair : un pilote a accédé à la mémoire paginable avec un IRQL trop élevé, et les conseils pratiques incluent la vérification de l'Observateur d'événements et la mise à jour ou la désactivation du pilote identifié.
Étape 1 : Identifiez le fichier du pilote à partir des vidages
Recherchez des modèles tels que :
- Netwtw10.sys (Les chemins des pilotes Wi-Fi apparaissent souvent)
- Pilotes Ethernet du fournisseur comme l1c63x64.sys dans les exemples de communauté
- Fichiers framework comme Wdf01000.sys c'est peut-être "le messager", pas la vraie cause
Si vous disposez d'un pilote tiers nommé, votre prochaine étape consiste à mettre à jour ou à restaurer ce pilote, et non à une réinstallation complète.
Étape 2 : Réinstallez proprement le pilote suspect
Pour les pilotes GPU et réseau, une réinstallation propre vaut souvent la « mise à jour sur place ».
- Désinstaller à partir des applications et fonctionnalités ou du Gestionnaire de périphériques
- Redémarrer
- Installez le pilote le plus récent du fournisseur/OEM
- Testez à nouveau la charge de travail exacte qui déclenche le crash
Étape 3 : utilisez Driver Verifier avec précaution (et uniquement sur les pilotes tiers)
Driver Verifier est mentionné comme un outil dans Références de vérification des bogues de Microsoft, mais cela ajoute une surcharge et peut pousser un système fragile vers des pannes plus rapides. C'est bien, tant que vous pouvez toujours démarrer.
Manière sûre de l'exécuter :
- Créez un point de restauration.
- Ouvrez l'invite de commande (administrateur), tapez vérificateur, appuyez sur Entrée.
- Sélectionner Paramètres standards.
- Au lieu de sélectionner des pilotes « non signés » ou « Windows plus anciens », ciblez un petit ensemble de suspects probables. Dans Driver Verifier Manager, choisissez Sélectionnez les noms de pilotes dans une liste, puis cochez-en quelques-uns non-Microsoft pilotes liés au crash (ou récemment installés/mis à jour). La vérification de chaque pilote peut ralentir le PC et provoquer des BSOD supplémentaires qui ajoutent du bruit.
- Redémarrez et reproduisez le crash.
Si vous êtes bloqué dans une boucle de démarrage :
- Démarrez dans Mode sans échec (détails ci-dessous)
- Ouvrir l'invite de commande (administrateur)
- Courir:
verifier /reset
C'est la différence entre « Le vérificateur a aidé » et « Le vérificateur a gâché ma soirée ».
Une fois que vous pouvez redémarrer de manière fiable, vous pouvez utiliser le même processus de mise à jour du pilote que la piste 0xA, mais vous disposez désormais d'une liste de suspects beaucoup plus courte. C'est également là que le mode sans échec et WinRE deviennent utiles.
Si vous ne pouvez pas démarrer : WinRE et le mode sans échec fonctionnent
If irql ni inférieur ni égal au démarrage, vous n’avez pas le luxe de tester une modification à la fois dans Windows. Utilisez l'environnement de récupération Windows (WinRE) :
- Allumez, puis interrompez le démarrage (mise hors tension) lorsque Windows commence à se charger, répétez 2 à 3 fois.
- Tu devrais atterrir Récupération.
- Aller à Dépannage → Options avancées.
À partir de là, les meilleures options de « retour » sont :
- Paramètres de démarrage → Mode sans échec
- Restauration du système (si vous avez créé des points de restauration)
- Désinstaller les mises à jour (si cela a commencé juste après une mise à jour)
Si vous utilisiez Driver Verifier, Mode sans échec + vérificateur/réinitialisation est généralement la sortie propre.
Une fois de retour dans Windows, revenez au runbook précédent et conservez vos modifications petites et testables. C’est aussi le moment où une solution de contournement temporaire peut vous sauver la semaine.
Raisons typiques pour lesquelles vous voyez l'erreur irql pas moins ou égale
Ce code d'erreur n'est pas aléatoire ; vous le verrez soit en cas de crash lors de gros téléchargements, soit en cas de crash après le sommeil, soit en cas de crash lorsque le Wi-Fi disparaît, ou juste après une mise à jour du pilote GPU, etc.
Voici les récidivistes liés à irql ni inférieur ni égal et pilote irql ni inférieur ni égal cas :
Pilotes réseau sous charge (Wi-Fi et Ethernet)
Déclenchement de gros téléchargements Steam/Epic ou de mises à jour Windows 0xD1, et les points de vidage sur un pilote réseau comme Netwtw10.sys (Intel Wi-Fi) ou un pilote Ethernet du fournisseur. Si vos plantages se concentrent autour des téléchargements et de la pile réseau, nous aimons également exclure les bizarreries de réseau côté Windows qui peuvent brouiller les tests, comme une mauvaise configuration du proxy et une détection bloquée.
Cette procédure pas à pas couvre les vérifications et réinitialisations rapides : Windows n'a pas pu détecter automatiquement les paramètres proxy de ce réseau.
Chemins des pilotes GPU (jeux, multi-moniteurs, lecture vidéo)
Les gens le signaleront comme « aléatoire », mais cela est souvent lié au changement rapide de fenêtre, à la fermeture d’applications ou à l’onglet Alt d’un jeu. Les pilotes GPU s'exécutent selon des chemins compliqués, et une mauvaise installation ou une incompatibilité peut apparaître comme irql ni inférieur ni égal, même si vous avez annulé une fois.
USB, stations d'accueil et « trop de choses branchées »
Les hubs USB, les interfaces audio, les cartes de capture et certaines stations d'accueil peuvent déclencher des interactions désagréables avec le pilote. Si le fait de débrancher l’équipement modifie la fréquence des accidents, c’est une véritable piste.
Outils de sécurité, VPN et « assistants réseau »
Les pilotes de pare-feu/VPN sont profondément ancrés dans la pile réseau. Si votre crash a commencé juste après l’installation d’un client VPN, d’un outil de capture de paquets ou d’une suite de sécurité tierce, vous n’êtes pas paranoïaque.
Instabilité du BIOS/XMP qui ressemble à un bug de pilote
Un profil de mémoire légèrement trop agressif peut réussir des vérifications rapides mais échouer malgré certaines charges de travail lourdes en interruptions. C'est pourquoi nous réinitialisons XMP/EXPO tôt lors d'un irql pas moins ou égal correctif.
Continuez à travailler pendant que vous réparez le crash
Si votre PC lance irql ni inférieur ni égal et que vous avez encore besoin de travailler aujourd'hui, l'option la plus rapide pour « continuer à avancer » consiste à utiliser une machine Windows distante pendant quelques jours. De cette façon, vous pouvez terminer vos tâches, télécharger des pilotes, exécuter des tests et maintenir votre système principal hors tension pendant le dépannage.
C'est aussi là que notre VPS Windows Cloudzy les options s’adaptent bien. Vous pouvez lancer un Windows 10 VPS or Windows 11 VPS, connectez-vous via RDP et continuez avec un environnement propre pendant que votre boîte locale est réglée. Nos services VPS Windows 10 et Windows 11 offrent 40 Gbps réseautage et un 99,95 % de disponibilité, ce qui est suffisant pour les flux de travail de bureau à distance et les gros téléchargements.
Pour une utilisation à court terme, la flexibilité des prix compte plus que les grandes promesses, c'est pourquoi nous nous appuyons sur la facturation et les remboursements :
- Facturation horaire PAYG : annulez à tout moment, payez uniquement les heures utilisées.
- Fenêtre de remboursement de 14 jours, plus jours 8 à 14, remboursements des crédits inutilisés si vous n'avez finalement pas besoin du serveur.
Vous pouvez vérifier les détails du produit ici : VPS Windows Cloudzy, Cloudzy Windows 10 VPS, et Cloudzy Windows 11 VPS.
Si vous vous inquiétez au sujet des fichiers alors que votre installation locale continue de planter, voici comment récupérer vos données en premier : Récupérer des fichiers à partir d'un VPS Windows corrompu (le même processus fonctionne pour un système d'exploitation Windows normal).
Une fois que vous êtes sorti de la zone de panique, il devient beaucoup plus facile d’éviter des accidents répétés.
Comment nous empêchons IRQL ni moins ni égal de revenir
Après un irql ni inférieur ni égal le crash s’arrête enfin, il est tentant de célébrer et de passer à autre chose. Nous aimons toujours faire une petite « passe de stabilité », car ce code d’arrêt adore revenir juste après le prochain changement de pilote, le cycle de veille ou la frénésie de plug-in USB.
Avant d’énumérer quoi que ce soit, une règle à garder à l’esprit est de modifier une chose, puis de tester le même déclencheur. Si le crash se produisait lors des téléchargements, effectuez un téléchargement long. Si cela se produit pendant le sommeil, effectuez quelques cycles de sommeil et de réveil. De cette façon, nous ne devinons pas.
Les habitudes qui réduisent les accidents répétés :
- Créez un point de restauration avant les modifications du chipset, du GPU, du Wi-Fi, du VPN ou de l'antivirus.
- Gardez XMP/EXPO désactivé jusqu'à ce que le système reste stable pendant quelques jours, puis réactivez-le uniquement après des tests de mémoire plus longs.
- Évitez d'empiler les outils de pilotes et les suites « d'assistance », en particulier les boosters de réseau, les packs de superposition et les plateaux des fournisseurs qui s'insèrent dans le chemin du noyau.
- En cas de pannes liées à la mise en veille ou à l'arrêt, désactivez le démarrage rapide pendant une semaine et testez à nouveau. C’est une simple bascule et il est facile à annuler.
- Traitez les stations d'accueil et les hubs USB comme de vrais suspects. Si la stabilité s'améliore avec moins de périphériques, mettez à jour le micrologiciel de la station d'accueil et les pilotes USB avant de tout rajouter.
Une fois que les choses seront stables, nous pourrons réintroduire les plus gentils, un à la fois. Cela garde irql ni inférieur ni égal de devenir une surprise mensuelle.
