Écran bleu WORKER_THREAD_RETURNED_AT_BAD_IRQL

L’écran bleu WORKER_THREAD_RETURNED_AT_BAD_IRQL signale qu’un thread de travail du noyau s’est terminé sans avoir remis le niveau de priorité du processeur là où il l’avait trouvé. Autrement dit, un pilote a laissé le système dans un état incohérent, et Windows préfère s’arrêter que continuer.

Points clés

• Code d’arrêt : 0x000000E1, libellé WORKER_THREAD_RETURNED_AT_BAD_IRQL.
• Condition exacte : un thread worker s’est terminé et a retourné avec un IRQL supérieur ou égal à DISPATCH_LEVEL.
• Les 4 paramètres du bug check donnent l’adresse de la routine de travail, l’IRQL au retour, le paramètre et l’adresse de l’élément de travail.
• Le coupable est un pilote, presque jamais le matériel. Le vérificateur de pilotes le nomme.
• Microsoft indique de rechercher le pilote fautif avec la commande de débogueur ln appliquée à l’adresse du paramètre 1.

Ce que le code 0xE1 veut dire

Windows entretient une réserve de threads système, appelés threads de travail, que les pilotes utilisent pour exécuter des tâches trop longues pour être traitées dans une interruption. Ces threads sont recyclés : quand un pilote a fini, le thread retourne à la file et repart pour un autre travail.

Le contrat est simple. Le pilote reçoit le thread à un niveau de priorité donné, PASSIVE_LEVEL, et doit le rendre au même niveau. S’il élève l’IRQL, par exemple en prenant un verrou tournant, et oublie de le rabaisser, le thread revient dans la file à DISPATCH_LEVEL ou au-dessus. Le prochain utilisateur du thread hériterait alors d’un environnement où il n’a plus le droit d’accéder à de la mémoire paginable. Le noyau coupe court.

La même famille de fautes produit d’autres codes bien connus, comme IRQL_NOT_DISPATCH_LEVEL ou SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD. Le point commun : un pilote qui ne respecte pas les règles des niveaux de priorité matérielle décrites par Microsoft.

Les quatre paramètres, et ce qu’on en tire

• Paramètre 1 : adresse de la routine de travail. C’est celui qui compte, il mène au pilote.
• Paramètre 2 : IRQL auquel le thread de travail a retourné.
• Paramètre 3 : paramètre de l’élément de travail.
• Paramètre 4 : adresse de l’élément de travail.

Un paramètre 2 égal à 2 correspond à DISPATCH_LEVEL, la valeur la plus courante sur ce code. Une valeur plus haute indique un verrou d’interruption resté acquis, ce qui restreint encore le champ des pilotes possibles.

Solution 1 : remonter au dernier changement

Cherchez ce qui a été installé ou mis à jour avant le premier plantage. Trois familles reviennent constamment : les pilotes de stockage et de contrôleur, les filtres de sécurité des antivirus tiers, les clients VPN qui installent un adaptateur virtuel.

Restaurez la version précédente depuis les propriétés du périphérique dans le Gestionnaire de périphériques, onglet Pilote, bouton Restaurer le pilote. Pour un logiciel, désinstallez-le entièrement, puis redémarrez et observez pendant au moins deux jours d’usage normal.

Si l’écran bleu revient avant même l’ouverture du bureau, démarrez sur les options de récupération et choisissez le mode sans échec, qui charge un jeu minimal de pilotes.

Solution 2 : le vérificateur de pilotes

Le vérificateur de pilotes applique des contrôles renforcés aux pilotes que vous désignez et déclenche un arrêt dès qu’un pilote viole une règle. Le nom du module apparaît alors directement, ce qui transforme une chasse au hasard en réparation ciblée.

1. Créez un point de restauration.
2. Ouvrez une invite de commandes en administrateur et lancez verifier.
3. Sélectionnez la création de paramètres personnalisés, puis les pilotes non signés par Microsoft.
4. Redémarrez et travaillez normalement jusqu’au plantage suivant.
5. Relevez le nom du pilote affiché, puis désactivez l’outil avec verifier /reset suivi d’un redémarrage.

Attendez-vous à un système plus lent et à des arrêts plus fréquents pendant cette phase. Si Windows refuse de démarrer une fois le vérificateur actif, le mode sans échec permet d’exécuter la commande de réinitialisation.

Solution 3 : ouvrir le vidage mémoire

Les minidumps se trouvent dans C:\Windows\Minidump. Les outils de débogage Windows, livrés avec le SDK Windows, ouvrent ces fichiers. La commande !analyze -v donne un premier verdict, et ln suivi de l’adresse du paramètre 1 renvoie le symbole le plus proche, c’est-à-dire le pilote propriétaire de la routine de travail. C’est la méthode indiquée par Microsoft pour ce code précis.

Sans minidump, rien de tout cela ne fonctionne. Vérifiez dans les paramètres système avancés que la récupération système est configurée pour écrire au moins un vidage mémoire réduit, et laissez assez d’espace libre sur le disque système.

Solution 4 : mettre à jour proprement, puis figer

Téléchargez les pilotes chez le fabricant du composant ou de la machine, pas sur un portail générique. Si la dernière version plante aussi, revenez à la version antérieure qui tenait et empêchez sa remise à jour automatique.

Appliquez ensuite les mises à jour Windows en attente, puis contrôlez les fichiers système avec sfc /scannow. Si des fichiers restent irréparables, enchaînez avec DISM /Online /Cleanup-Image /RestoreHealth avant de relancer la vérification.

Quand Windows n’atteint plus le bureau

Si l’écran bleu s’affiche avant l’ouverture de session, il faut sortir du système pour le réparer. Après deux échecs de démarrage consécutifs, Windows bascule de lui-même sur l’environnement de récupération. Sinon, démarrez sur une clé d’installation et choisissez la réparation de l’ordinateur.

1. Dans le menu Dépannage, ouvrez les options avancées, puis les paramètres de démarrage, et lancez le mode sans échec avec mise en réseau.
2. Depuis ce mode, désinstallez le pilote ou le logiciel suspect, ou exécutez verifier /reset si le vérificateur avait été activé.
3. Si le mode sans échec échoue aussi, utilisez la restauration du système sur un point antérieur au problème.
4. En dernier ressort, l’outil de réparation du démarrage corrige les fichiers de configuration de l’amorçage, sans toucher aux données.

Ces étapes n’effacent rien. Elles servent surtout à retrouver un système exploitable assez longtemps pour appliquer les solutions décrites plus haut.

Sauvegarder avant d’intervenir

Un ordinateur qui s’arrête sur ce code peut redevenir non démarrable à tout moment. Avant de toucher aux pilotes, mettez les données à l’abri sur un support externe, puis créez une image système ou un point de restauration. Le menu Sauvegarde et restauration de Windows produit encore une image complète du disque, utilisable depuis l’environnement de récupération si le système refuse de démarrer.

Gardez aussi une clé d’installation de Windows sous la main. Elle donne accès aux outils de réparation du démarrage sans dépendre de la partition de récupération, parfois endommagée par les arrêts brutaux à répétition.

Cas particuliers à connaître

• Ordinateur portable et sorties de veille : sur un portable, le crash se produit très souvent au réveil. Les pilotes de gestion d’alimentation et les cartes réseau Wi-Fi sont les premiers suspects, et un fichier .sys du constructeur est fréquemment en cause.
• Après une mise à jour Windows : une montée de version remplace certains pilotes par des versions génériques. Réinstaller le paquet du fabricant règle une partie des cas.
• Après l’ajout d’une carte : carte graphique, carte de capture ou contrôleur USB supplémentaire introduisent un pilote neuf. Retirez la carte pour trancher.
• Avec un antivirus tiers : les filtres de fichiers de ces logiciels s’insèrent dans la pile de stockage. Une désinstallation temporaire, via l’outil de suppression officiel de l’éditeur, est plus concluante qu’une simple mise en pause.

Dans tous ces cas, la démarche reste la même : isoler un seul changement à la fois, puis observer. Traiter plusieurs problèmes en parallèle empêche d’attribuer l’amélioration à la bonne action.

Quand ce n’est pas le pilote

Le code 0xE1 décrit un défaut logiciel, mais une mémoire défaillante peut fausser l’état d’un thread. Deux contrôles rapides ferment la porte.

• Testez la RAM, la marche à suivre est détaillée dans notre article sur le test de la mémoire.
• Coupez tout overclocking, profils mémoire XMP ou EXPO inclus, et repassez aux réglages par défaut.

Si les codes d’arrêt varient d’un plantage au suivant, suivez la méthode de l’écran bleu aléatoire plutôt que de traiter chaque code séparément. Le guide des écrans bleus Windows resitue 0xE1 parmi les autres codes, et DPC_WATCHDOG_VIOLATION reste le voisin le plus proche côté pilotes de stockage.

Dernier recours

Une réinstallation propre de Windows, sans réinstaller aussitôt les utilitaires du constructeur, sert de test décisif. Si le système neuf tient plusieurs jours, le pilote retiré était bien la cause. Sauvegardez avant, les applications installées disparaissent.

Questions fréquentes

Quelle différence avec IRQL_NOT_LESS_OR_EQUAL ?

IRQL_NOT_LESS_OR_EQUAL survient quand un pilote accède à de la mémoire interdite au niveau où il se trouve. Le code 0xE1 constate autre chose : un thread de travail rendu au noyau avec un niveau trop élevé.

Le code 0xE1 peut-il venir d’un jeu ou d’une application ?

Pas directement. Une application en espace utilisateur ne fixe pas l’IRQL. En revanche, un anti-triche ou un pilote installé par le logiciel travaille bien au niveau noyau.

Faut-il changer de barrette mémoire ?

Seulement si un test mémoire remonte des erreurs. Sur ce code, la RAM n’est qu’une hypothèse secondaire.

Le vérificateur de pilotes est-il risqué ?

Il multiplie volontairement les arrêts, donc il faut un point de restauration et savoir démarrer en mode sans échec. Une fois verifier /reset exécuté, le système retrouve son comportement normal.

Combien de temps observer après une correction ?

Deux à trois jours d’usage représentatif, en incluant les mises en veille et les sorties de veille, qui rechargent des pilotes et déclenchent souvent ce type d’arrêt.

_{Photo d’en-tete : ecran bleu Windows 10 photographie par Snoopy1964, licence CC BY-SA 4.0 via Wikimedia Commons. Il s’agit d’un ecran bleu Windows 10 generique, pas d’une capture du code 0xE1.
Sources : Microsoft Learn, Bug Check 0xE1 WORKER_THREAD_RETURNED_AT_BAD_IRQL · Microsoft Learn, Managing Hardware Priorities · Microsoft Learn, Driver Verifier · Microsoft Learn, outils de débogage Windows · Microsoft Learn, résolution des erreurs d’arrêt · Support Microsoft, résoudre les erreurs d’écran bleu}