Comment corriger l’erreur BSOD « IRQL_NOT_LESS_OR_EQUAL » causée par ntoskrnl.exe

Lorsqu’un système Windows plante avec l’écran bleu IRQL_NOT_LESS_OR_EQUAL (stop code irql_not_less_or_equal), les équipes IT font face à bien plus qu’une simple interruption de la journée de travail. Selon IDC, les temps d’arrêt non planifiés déclenchés par une instabilité système peuvent coûter aux organisations jusqu’à 300 000 $ par heure en perte de productivité. Lorsque ntoskrnl.exe apparaît comme module en cause (ntoskrnl.exe blue screen), la situation est encore plus critique, car cette erreur au niveau du noyau ne se contente pas de forcer un redémarrage : elle peut corrompre les systèmes de fichiers en cours d’écriture, endommager l’état des pilotes et dégrader silencieusement l’intégrité des données à chaque crash. Sur Windows 11, ce type de BSOD Windows 11 est particulièrement problématique dans les environnements professionnels.

Le problème est que le noyau Windows (ntoskrnl.exe) est souvent simplement le « témoin » du problème, et non le véritable responsable. Alors, comment le corriger réellement ? Ce guide vous accompagne à travers un processus de diagnostic et de remédiation systématique pour identifier le véritable fautif et corriger le problème de manière durable, sans affaiblir votre posture de sécurité ni risquer d’autres pertes de données.

Quelles sont les causes des erreurs IRQL_NOT_LESS_OR_EQUAL

Le code d’arrêt IRQL_NOT_LESS_OR_EQUAL (0x0000000A) (stop code irql_not_less_or_equal) se produit lorsqu’un processus ou pilote en mode noyau tente d’accéder à la mémoire à un niveau de priorité incorrect. En termes simples, un logiciel a tenté d’accéder à des données auxquelles il n’était pas autorisé à ce moment-là, et Windows a immédiatement tout stoppé pour éviter une corruption.

Dans des environnements IT réels, cette erreur apparaît généralement après des changements système subtils, tels que :

• Un pilote réseau mis à jour automatiquement pendant la nuit
• Un module mémoire se dégradant sous stress thermique
• Un contrôleur graphique « certifié » tentant d’écraser une adresse mémoire protégée par le noyau

Lorsque ntoskrnl.exe est indiqué comme module en cause (ntoskrnl.exe blue screen), ce n’est presque jamais lui le véritable problème. Le noyau est simplement le composant qui détecte la violation et la signale, comme un agent de sécurité qui alerte d’une intrusion sans en être l’auteur. Les pilotes de périphériques sont responsables de la majorité des défaillances du système d’exploitation, souvent autour de 70 %, les pilotes tiers étant particulièrement sujets aux erreurs.

Tous les codes en mode noyau ne présentent pas le même niveau de risque. Certains pilotes comme la carte réseau (NIC) et le processeur graphique (GPU) sont parmi les plus fréquents responsables. Ces composants effectuent d’importants transferts de données asynchrones à haute vitesse, ce qui les rend particulièrement vulnérables aux conflits d’accès mémoire.

De plus, un léger décalage dans une interface firmware peut provoquer des boucles d’écrans bleus sur tout un parc de machines, car le pilote tente d’accéder à une mémoire pageable à un niveau de priorité interdit.

Guide étape par étape pour corriger l’erreur IRQL_NOT_LESS_OR_EQUAL

La résolution de cette erreur au niveau du noyau nécessite plusieurs étapes, allant de la préparation sécurisée au diagnostic, puis à la remédiation ciblée. Sauter des étapes ou passer directement aux « correctifs » conduit souvent à perdre du temps sur une mauvaise cause ou à introduire de nouvelles instabilités.

Étape 1 : Préparer le système pour un diagnostic sécurisé

Avant toute intervention, il est essentiel de configurer le système pour capturer les données de diagnostic et de s’assurer que des options de récupération sont disponibles en cas de problème. L’objectif est de créer un filet de sécurité permettant une investigation approfondie sans risque de perte de données ou d’impossibilité de démarrer le système.

Configurer des vidages mémoire complets

Windows crée par défaut des fichiers de type minidump, mais ces rapports de crash simplifiés ne contiennent souvent pas suffisamment de détails pour une analyse approfondie.

Suivez ces étapes :

1. Appuyez sur Win + Pause/Attn pour ouvrir les paramètres système (ou clic droit sur Ce PC > Propriétés > Paramètres système avancés)

2. Dans l’onglet Avancé, cliquez sur « Démarrage et récupération »

3. Dans le menu déroulant « Écriture des informations de débogage », sélectionnez « Vidage mémoire complet » et assurez-vous que l’emplacement du fichier de vidage indique %SystemRoot%\MEMORY.DMP.

4. Cliquez sur OK pour enregistrer, puis à nouveau sur OK pour fermer les Propriétés système.

Cela garantit que lors du prochain crash, vous disposerez d’un instantané complet de la mémoire noyau à analyser avec WinDbg.

Vérifier le périmètre de sauvegarde et l’accès à la récupération

Avant de modifier des pilotes ou d’exécuter des outils de diagnostic susceptibles de provoquer d’autres plantages, assurez-vous de disposer de sauvegardes à jour des données critiques et d’un moyen de récupération vérifié.

Suivez ces étapes pour vérifier la couverture des sauvegardes :

Ouvrez votre solution de sauvegarde (Windows Backup, logiciel de sauvegarde tiers ou système de sauvegarde d’entreprise)

Vérifiez que la date du dernier backup réussi est récente (dans les 24 heures pour les systèmes critiques).

3. Vérifiez que la sauvegarde inclut les données de l’état système, et pas uniquement les fichiers utilisateurs.

4. Si vous travaillez à distance, assurez-vous de disposer d’un accès hors bande (out-of-band) qui ne dépend pas de la stabilité du système d’exploitation.

Dans les environnements IT d’entreprise, assurez-vous que votre solution de sauvegarde dispose de snapshots récents et que les procédures de restauration ont été testées. Vous ne voulez pas découvrir une défaillance de sauvegarde au moment de récupérer un système après un incident de diagnostic.

Créer un point de restauration système

Bien que la restauration du système ne soit pas efficace pour les problèmes matériels, elle fournit une option rapide de retour arrière si des mises à jour de pilotes ou des réparations de fichiers système introduisent de nouveaux problèmes.

Suivez ces étapes pour créer un point de restauration :

1. Tapez « Créer un point de restauration » dans la barre de recherche Windows et appuyez sur Entrée

2. Dans l’onglet Protection du système, sélectionnez votre lecteur C: et cliquez sur Configurer.

3. Assurez-vous que l’option « Activer la protection du système » est sélectionnée.

4. Ajustez le curseur d’utilisation de l’espace disque à au moins 5 % à 10 % de la capacité du disque.

5. Cliquez sur OK, puis sur le bouton Créer en bas de la fenêtre.

6. Ajoutez une description claire, par exemple : « Pre-IRQL Diagnostics – [Date du jour] »

7. Cliquez sur Créer et attendez la confirmation.

Étape 2 : Analyser les dumps mémoire pour identifier le responsable

Une fois la préparation terminée, la phase suivante consiste à identifier quel composant est réellement à l’origine de la violation IRQL. Rappelez-vous que ntoskrnl.exe blue screen (ecran bleu) n’est presque jamais le véritable problème, votre objectif est donc de trouver ce qui a déclenché l’erreur.

Installer et configurer WinDbg

WinDbg (Windows Debugger) est l’outil standard de l’industrie pour l’analyse des crashs noyau liés aux BSOD Windows 11. Vous devez le télécharger et l’installer avant d’analyser les fichiers de dump :

1.Ouvrez le Microsoft Store et recherchez « WinDbg », puis cliquez sur Obtenir

2. Ouvrez l’outil depuis le Microsoft Store ou le menu Démarrer.

3. Cliquez sur File > Start debugging > Open dump file

4. Accédez à C:\Windows\MEMORY.DMP (ou C:\Windows\Minidump\ si vous utilisez des minidumps) et sélectionnez le fichier .dmp le plus récent.

5. Cliquez sur Open et attendez que WinDbg charge le dump (cela peut prendre plusieurs minutes pour les vidages mémoire complets).
6. Une fois le chargement terminé, tapez !analyze -v dans la fenêtre de commande en bas et appuyez sur Entrée.
7. Attendez la fin de l’analyse automatique.

NOTE : S’il n’existe aucun fichier de dump, cela signifie que votre système n’a pas encore capturé de données de crash, ou que les fichiers ont été automatiquement supprimés. Passez à la section « Tester une défaillance de la mémoire physique » et continuez les autres étapes de diagnostic.

La sortie de !analyze -v fournit des informations détaillées sur la cause du crash. Vous devez identifier les pilotes tiers dans la trace de pile.

Identifier le responsable

Suivez ces étapes pour identifier le composant en cause :

1. Faites défiler les résultats de l’analyse pour trouver la section STACK_TEXT
2. Recherchez des fichiers .sys tiers (tout ce qui n’appartient pas à Microsoft) dans la pile. Les causes fréquentes incluent :

• nvlddmkm.sys (pilote graphique NVIDIA)
• rt640x64.sys ou rtwlane.sys (pilotes réseau Realtek)
• igdkmd64.sys (pilote graphique Intel)
• e1d68x64.sys (pilote réseau Intel)
• Pilotes d’antivirus ou de VPN

3. Notez le nom exact du fichier du pilote ainsi que les informations du fabricant affichées
4. Recherchez en ligne “[nom du pilote] IRQL_NOT_LESS_OR_EQUAL” pour voir si d’autres utilisateurs ont rencontré le même problème

Étape 3 : Utiliser Driver Verifier pour tester les pilotes suspects

Une fois les pilotes potentiellement problématiques identifiés via l’analyse des minidumps, Driver Verifier force ces pilotes à fonctionner sous surveillance renforcée, révélant des défauts qui peuvent ne se produire qu’occasionnellement en conditions normales.

Driver Verifier est un outil Windows intégré qui met sous stress les pilotes en mode noyau afin de détecter les bugs. Il est très efficace pour identifier les violations IRQL, mais peut rendre le système instable s’il est mal configuré.

Suivez ces étapes pour activer Driver Verifier :

1.Appuyez sur Win + R, tapez verifier.exe, puis appuyez sur Entrée

2. Sélectionnez « Créer des paramètres personnalisés (pour développeurs de code) » et cliquez sur Suivant.

3. Cochez les options suivantes, puis cliquez sur Suivant :

• Deadlock Detection
• Special Pool
• Force IRQL Checking
• Pool Tracking

4. Sélectionnez « Sélectionner les noms des pilotes dans une liste » et cliquez sur Suivant.

Avertissement important : ne sélectionnez PAS « Sélectionner automatiquement tous les pilotes installés sur cet ordinateur » ni « Sélectionner automatiquement les pilotes conçus pour des versions plus anciennes de Windows ». Vérifier tous les pilotes en même temps peut rendre le système complètement instable et difficile à récupérer.

5. Dans la liste des pilotes, recherchez et cochez uniquement le(s) pilote(s) spécifique(s) identifié(s) lors de votre analyse WinDbg (par exemple, si vous avez identifié nvlddmkm.sys, sélectionnez uniquement les pilotes NVIDIA).

6. Cliquez sur Terminer
7. Redémarrez votre ordinateur lorsque vous y êtes invité

Avec Driver Verifier activé, utilisez votre ordinateur normalement pour vérifier si le pilote problématique déclenche un crash avec une attribution claire.

Étapes de test

Suivez ces étapes pour effectuer les tests :

1. Après le redémarrage avec Driver Verifier activé, utilisez votre ordinateur comme d’habitude
2. Reproduisez les actions qui déclenchaient auparavant des crashs (jeux, lecture vidéo, forte utilisation réseau, cycles veille/réveil)
3. Si le pilote présente une faille IRQL, Driver Verifier déclenchera un crash immédiat avec le pilote fautif clairement indiqué sur l’écran bleu
4. Si le système reste stable pendant 24 à 48 heures avec Verifier activé, il est probable que le pilote ne soit pas en cause

Une fois les tests terminés, vous devez désactiver Driver Verifier, sinon votre système continuera de fonctionner en mode de vérification stricte, ce qui peut impacter les performances.

Étape 4 : Vérifier les conflits dans le Gestionnaire de périphériques

Le Gestionnaire de périphériques permet d’identifier rapidement les pilotes problématiques et les changements récents pouvant être liés aux plantages.

Suivez ces étapes pour vérifier les problèmes de pilotes :

1.Appuyez sur Win + X et sélectionnez Gestionnaire de périphériques

2. Recherchez les appareils affichant un point d’exclamation jaune (⚠️), indiquant un problème de pilote.

3. Développez les catégories suivantes pour les inspecter plus en détail :

• Cartes réseau
• Cartes graphiques
• Contrôleurs de stockage
• Périphériques système

4. Pour chaque appareil de ces catégories, faites un clic droit et sélectionnez Propriétés.

5. Cliquez sur l’onglet Pilote et notez la date du pilote

Si les crashs ont commencé après une date précise, les pilotes mis à jour autour de cette période sont des suspects principaux. Faites particulièrement attention aux appareils affichant des erreurs « Code 43 » ou à ceux qui semblent fonctionner correctement mais dont les pilotes ont récemment été mis à jour via Windows Update plutôt que via les versions du fabricant.

6. Si vous identifiez un pilote problématique, cliquez sur « Restaurer le pilote » si l’option n’est pas grisée.

7. Sélectionnez une raison dans la liste et cliquez sur Oui pour confirmer.

8. Redémarrez votre ordinateur une fois le retour en arrière terminé.

Remarque : la restauration du pilote n’est disponible que si Windows a conservé la version précédente. Si le bouton « Restaurer le pilote » est grisé, vous devrez télécharger manuellement une ancienne version depuis le site du fabricant.

De plus, si possible, envisagez de mettre à jour vos pilotes, car des pilotes obsolètes peuvent également provoquer de nombreux problèmes. Si nécessaire, consultez notre guide de mise à jour des pilotes et notre liste des meilleurs logiciels de mise à jour de pilotes.

Étape 5 : Effectuer un démarrage propre pour isoler les logiciels tiers

Un démarrage propre permet de déterminer si des services ou programmes tiers déclenchent l’erreur IRQL, en aidant à distinguer les problèmes de pilotes en mode noyau des conflits logiciels en mode utilisateur.

Suivez ces étapes :

1.Appuyez sur Win + R, tapez msconfig, puis appuyez sur Entrée

2. Cliquez sur l’onglet Services.

3. Cochez la case « Masquer tous les services Microsoft » en bas, puis cliquez sur « Désactiver tout » pour désactiver tous les services non-Microsoft.

4. Cliquez sur l’onglet Démarrage > Ouvrir le Gestionnaire des tâches.

5. Dans l’onglet Démarrage du Gestionnaire des tâches, faites un clic droit sur chaque élément de démarrage activé et cliquez sur Désactiver.

6. Fermez le Gestionnaire des tâches.

7. Dans la fenêtre Configuration du système, cliquez sur OK.

8. Cliquez sur Redémarrer lorsque vous y êtes invité.

Après le démarrage en mode minimal (clean boot), testez si les crashs IRQL persistent en suivant ces étapes :

1. Utilisez votre ordinateur normalement pendant plusieurs heures ou reproduisez les actions qui déclenchaient les crashs
2. Si les crashs cessent, un service tiers ou un programme de démarrage est en cause
3. Si les crashs continuent, le problème provient d’un pilote de démarrage en mode noyau (comme les pilotes disque ou réseau), et non d’un service utilisateur
4. Pour identifier le service responsable, ouvrez à nouveau msconfig
5. Dans l’onglet Services, masquez les services Microsoft, puis activez la moitié des services désactivés
6. Redémarrez et testez
7. Si les crashs réapparaissent, le problème se trouve dans la moitié activée. Désactivez ensuite la moitié de celle-ci et testez à nouveau
8. Si les crashs ne réapparaissent pas, le problème se trouve dans la moitié encore désactivée. Activez-en la moitié et testez
9. Continuez ce processus de recherche binaire jusqu’à isoler le service spécifique

Limitation importante : le mode minimal ne teste que les services et programmes de démarrage en mode utilisateur. Il ne désactive pas les pilotes noyau de démarrage (comme les contrôleurs disque ou réseau). Si les crashs persistent en mode minimal, il s’agit probablement d’un problème plus profond lié à un pilote en mode noyau.

Étape 6 : Vérifier les paramètres de sécurité Windows pour les tests de compatibilité

Les fonctionnalités Core Isolation et Memory Integrity de Windows Security protègent le noyau, mais peuvent entrer en conflit avec d’anciens pilotes qui ne respectent pas les standards modernes de gestion mémoire.

Suivez ces étapes pour vérifier si les fonctionnalités VBS causent des conflits :

1.Accédez à Confidentialité et sécurité > Sécurité Windows

2. Appuyez sur Win + I pour ouvrir les Paramètres

3. Cliquez sur Sécurité de l’appareil.

4. Cliquez sur Détails de l’isolation du noyau.

5. Vérifiez si l’option « Intégrité de la mémoire » est activée ou désactivée.

6. Si elle est activée et que vos crashs ont commencé après une mise à jour récente de Windows, désactivez-la en la passant sur Désactivé.

7. Redémarrez votre ordinateur.

8. Testez le système pendant plusieurs heures.

Si les crashs persistent, l’intégrité de la mémoire n’est pas en cause. Réactivez-la pour conserver la protection du noyau et passez aux étapes suivantes. Si les crashs cessent après la désactivation de l’intégrité de la mémoire, cela signifie que le pilote n’est pas compatible avec les standards de sécurité modernes.

À partir de là, plusieurs options s’offrent à vous :

• Contacter le fabricant du matériel pour obtenir un pilote mis à jour compatible VBS
• Remplacer le matériel par un équipement disposant de pilotes compatibles
• Prendre une décision basée sur le risque et laisser l’intégrité de la mémoire désactivée sur ce système spécifique (non recommandé en environnement de production)

Étape 7 : Réparer les fichiers système avec SFC et DISM

La corruption des fichiers système peut déclencher des violations IRQL si des composants du noyau sont endommagés. Ces outils en ligne de commande permettent de réparer les fichiers Windows à l’aide de sources officielles Microsoft.

DISM (Deployment Image Servicing and Management) doit être exécuté en premier, car il répare le magasin de composants utilisé comme référence par SFC. Suivez ces étapes :

1.Ouvrez l’Invite de commandes en tant qu’administrateur

2. Entrez la commande suivante : DISM /Online /Cleanup-Image /RestoreHealth

3. Attendez que le processus se termine (cela peut prendre entre 15 et 30 minutes selon votre vitesse Internet et l’état du système).

4. Ensuite, entrez la commande suivante : SFC /scannow

5. Attendez la fin de l’analyse (généralement 10 à 20 minutes).

6. Lisez les résultats finaux :

• « Windows Resource Protection did not find any integrity violations » = aucun fichier corrompu détecté
• « Windows Resource Protection found corrupt files and successfully repaired them » = les corruptions ont été corrigées
• « Windows Resource Protection found corrupt files but was unable to fix some of them » = une intervention manuelle est nécessaire

Si SFC a détecté des fichiers corrompus sans pouvoir tous les réparer, vous devez analyser le journal pour identifier les fichiers problématiques. Suivez ces étapes :

1.Dans l’Invite de commandes, entrez la commande suivante :
findstr /c:”[SR]” %windir%\Logs\CBS\CBS.log > “%userprofile%\Desktop\sfcdetails.txt”

2. Accédez à votre Bureau et ouvrez sfcdetails.txt avec le Bloc-notes.

3. Recherchez les lignes contenant « [SR] Cannot repair » afin d’identifier les fichiers système endommagés.

4. Notez ces noms de fichiers pour un remplacement manuel éventuel à partir de systèmes sains ou du support d’installation Windows.

» Vous avez des difficultés ? En savoir plus sur l’utilisation correcte de la commande DISM

Étape 8 : Utiliser PowerShell pour auditer et corriger les pilotes à grande échelle

Pour les organisations gérant plusieurs endpoints, PowerShell permet d’auditer l’état des pilotes sur un parc et d’appliquer des actions correctives à distance.

Suivez ces étapes :

1.Ouvrez PowerShell en tant qu’administrateur

2. Collez la commande suivante :
Get-WindowsDriver -Online -All | Export-Csv -Path “$env:USERPROFILE\Desktop\AllDrivers.csv” -NoTypeInformation

3. Attendez la fin de l’exécution de la commande, puis ouvrez le fichier CSV sur votre Bureau avec Excel ou une autre application de feuille de calcul.

4. Faites défiler la sortie et recherchez les entrées affichant « FALSE » dans la colonne IsSigned.

Remarque : cette commande peut se bloquer sur des systèmes plus lents. Si vous attendez longtemps sans obtenir de résultats, essayez plutôt la commande suivante :
driverquery /FO CSV /SI > “C:\Users\Public\Desktop\AllDrivers.csv”

5. Consultez la colonne Driver pour voir tous les pilotes installés, leurs versions, dates et fournisseurs.

6. Identifiez les pilotes non signés ou anciens (car ils sont souvent des suspects principaux dans les violations IRQL, n’ayant pas subi de tests rigoureux de gestion mémoire) avec la commande :
driverquery /SI /FO TABLE

7. Notez le nom du module (Module Name) et le nom INF (Inf Name) de tous les pilotes non signés.

8. Croisez ces informations avec votre analyse WinDbg précédente ou votre inspection du Gestionnaire de périphériques afin de prioriser les suspects.

Par exemple, les entrées non signées provenant de périphériques gaming (comme les pilotes de récepteurs sans fil), de logiciels VPN ou de matériel ancien sont des cas fréquents et des causes courantes d’erreurs IRQL. Comparez toute entrée marquée FALSE avec la chronologie des crashs que vous avez documentée à l’étape 1 afin de déterminer s’il s’agit de suspects probables.

9. Ensuite, récupérez l’InstanceId exact du périphérique associé au pilote problématique :
Get-PnpDevice | Where-Object {$_.FriendlyName -like “[nom partiel du périphérique]”}

Remplacez [nom partiel du périphérique] par une partie du nom du pilote identifié lors de votre analyse précédente (« Realtek » ou « lightspeed », par exemple).

10. Désactivez le périphérique à l’aide de son InstanceId avec la commande suivante :
Disable-PnpDevice -InstanceId “[collez l’InstanceId ici]” -Confirm:$false

Étape 9 : Suppression hors ligne des pilotes (lorsque le système ne démarre plus

Lorsque Windows plante avant même que vous puissiez vous connecter, vous devez identifier et supprimer le pilote problématique depuis l’extérieur du système d’exploitation en utilisant l’environnement de récupération Windows (WinRE).

Accéder à WinRE si vous disposez d’un support d’installation :

1. Insérez la clé USB ou le DVD et redémarrez votre ordinateur
2. Appuyez sur une touche lorsqu’il vous est demandé de démarrer depuis le support
3. Sélectionnez vos paramètres de langue puis cliquez sur Suivant
4. Cliquez sur « Réparer votre ordinateur » en bas à gauche

Accéder à WinRE sans support d’installation :

1. Accédez à Dépannage > Options avancées > Invite de commandes

2. Forcez l’arrêt de votre ordinateur trois fois rapidement pendant le démarrage pour déclencher WinRE automatiquement

3. Attendez l’apparition de « Préparation de la réparation automatique »

4. Cliquez sur « Options avancées » lorsque l’écran de récupération apparaît

Dans l’environnement de récupération, les lettres de lecteur sont souvent différentes de celles de Windows. Vous devez identifier le lecteur contenant votre installation Windows.

Suivez ces étapes pour identifier le lecteur Windows :

1. Entrez la commande suivante : diskpart

2. Dans l’outil de gestion des partitions, tapez : list volume

3. Notez la lettre du lecteur correspondant au volume intitulé « Windows » ou à celui dont la taille correspond à votre installation Windows (généralement entre 100 Go et 500 Go pour la partition système).

4. Tapez : exit

5. Puis entrez la commande suivante (remplacez « D » par la lettre correcte du lecteur) :
dism /image:D:\ /get-drivers

6. Appuyez sur Entrée et attendez que la liste soit générée.

7. Analysez la sortie pour retrouver le pilote identifié lors de votre analyse WinDbg précédente.

8.Notez le « Published Name » (qui ressemble à oem##.inf, où ## est un numéro).

9. Ensuite, supprimez le pilote avec la commande suivante (remplacez « D » par la lettre de votre lecteur Windows et « oem##.inf » par le nom réel du pilote) :
dism /image:D:\ /remove-driver /driver:oem##.inf

10. Une fois le processus terminé, redémarrez votre ordinateur.

Étape 10 : Ajuster les paramètres du firmware BIOS/UEFI

Si vous avez épuisé les mises à jour de pilotes, les réparations des fichiers système et les diagnostics en mode minimal sans résoudre les crashs, le problème peut se situer au niveau de l’interface matériel-firmware. Ne poursuivez les modifications du firmware qu’après avoir confirmé l’échec des correctifs logiciels.

Suivez ces étapes :

Si vous arrivez sur l’écran du système d’exploitation, cela signifie que vous avez appuyé sur la mauvaise touche ou trop tard. Le menu BIOS devrait ressembler à ceci :

1. Accédez au BIOS/UEFI en redémarrant votre PC, puis en appuyant de manière répétée sur la touche BIOS pendant le démarrage (la touche varie selon le fabricant, mais il s’agit généralement de : Delete, F2, F10, F12 ou Échap)

Après chaque étape, enregistrez les modifications et quittez le BIOS, puis testez le système pour vérifier si les crashs ont cessé. S’ils persistent, passez au réglage BIOS suivant.

Désactivez les profils mémoire XMP / DOCP / EXPO

Les profils XMP (Extreme Memory Profile) et DOCP (Direct Overclocking Profile) permettent de pousser la RAM au-delà des spécifications standard et peuvent être plus instables, ce qui peut provoquer des violations IRQL si le contrôleur mémoire ne parvient pas à maintenir une stabilité correcte.

Suivez ces étapes :

1. Passez-le de « Activé » ou « Profile 1 » à « Désactivé » ou « Par défaut »

2. Dans le BIOS, accédez à la section Overclocking, Advanced ou AI Tweaker (selon le fabricant)

3. Recherchez le paramètre nommé « XMP », « DOCP », « EOCP » ou « Memory Profile »

4. Vérifiez que la fréquence mémoire affiche les vitesses standard JEDEC (DDR4-2133, DDR4-2400 ou DDR5-4800).

Si les crashs continuent, alors la RAM n’était pas en cause et vous pouvez réactiver XMP ou DOCP.

Désactiver la virtualisation matérielle

Des conflits entre les fonctions de virtualisation du processeur et certains pilotes peuvent déclencher des erreurs IRQL, notamment avec d’anciennes cartes réseau ou des pilotes GPU. Suivez ces étapes pour désactiver la virtualisation (si vous n’utilisez pas de machines virtuelles comme Hyper-V ou Windows Sandbox) :

1. Accédez à la section CPU Configuration, Advanced ou Security

2. Recherchez « Intel Virtualization Technology » (VT-x) ou « SVM Mode » (AMD-V).

3. Passez cette option sur Désactivé.

4. Désactivez également « Intel VT-d » ou « AMD IOMMU » si l’option est disponible.

Ajuster la gestion de l’alimentation PCIe (ASPM)

Une gestion agressive de l’alimentation peut entraîner des réveils matériels incohérents depuis des états basse consommation, ce qui peut provoquer des violations IRQL lorsque les pilotes tentent de communiquer avec un matériel qui n’est pas encore totalement initialisé.

Suivez ces étapes pour la désactiver :

1. Passez l’option de « Auto » ou « L1 » à « Désactivé »

2. Accédez à Advanced > PCIe Configuration ou Chipset Configuration

3. Recherchez « ASPM » (Active State Power Management)

4. Testez les cycles veille/réveil du système

Désactiver les C-States du processeur pour les tests

Les états d’économie d’énergie du CPU peuvent provoquer des problèmes de synchronisation au réveil, ce qui peut déclencher des violations IRQL.

Suivez ces étapes pour désactiver les C-States :

1. Passez l’option sur Désactivé

2. Accédez à Advanced > CPU Configuration ou Power Management

3. Recherchez « CPU C-States », « Enhanced C-States » ou « Global C-state Control »

Mettre à jour le firmware BIOS/UEFI (dernier recours)

Un firmware de carte mère obsolète peut provoquer des défaillances de communication entre le système d’exploitation et le matériel.

Avertissement critique : les mises à jour du BIOS comportent un risque. Si le processus est interrompu pendant le flash (coupure de courant, crash système), la carte mère peut devenir inutilisable. N’effectuez une mise à jour du BIOS que si vous avez épuisé toutes les autres options et que les notes de version indiquent explicitement des problèmes de stabilité correspondant à vos symptômes.

Consultez également nos guides complets sur la mise à jour du BIOS afin de vous assurer de bien comprendre la procédure.

Prenez le contrôle des erreurs BSOD avec Atera

Corriger les erreurs IRQL_NOT_LESS_OR_EQUAL causées par ntoskrnl.exe est rarement simple, mais cela devient plus gérable lorsqu’on adopte une approche d’investigation systématique plutôt que du dépannage au hasard. Cela implique une préparation correcte, un diagnostic méthodique et une progression du plus simple au plus complexe.

Pour les équipes IT qui gèrent des dizaines ou des centaines de endpoints, répéter ces étapes manuellement sur chaque machine affectée n’est pas réaliste. La plateforme tout-en-un d’Atera donne aux techniciens les outils pour traiter les problèmes IRQL à grande échelle, notamment :

• Génération de scripts PowerShell complets via l’IA Copilot à partir de requêtes en langage naturel
• Exécution à distance d’audits de pilotes PowerShell sur l’ensemble du parc via le RMM
• Suivi des versions BIOS pour corréler les firmwares avec les schémas de crash
• Configuration d’alertes de seuil pour détecter les anomalies d’interruptions avant qu’elles ne provoquent des écrans bleus

Lorsque l’instabilité au niveau du noyau touche plusieurs endpoints simultanément, disposer d’une plateforme centralisée regroupant diagnostic, accès à distance et remédiation automatisée fait la différence entre une réponse maîtrisée et une crise à grande échelle.

» Essayez Atera gratuitement pour voir comment elle peut simplifier vos opérations