Un écran bleu qui désigne usbxhci sys pointe vers le pilote du contrôleur hôte USB 3.0 de la machine, pas vers un fichier abîmé qu’il faudrait remplacer. Ce pilote est fourni par Windows, signé par Microsoft, et la cause réelle se trouve presque toujours ailleurs : firmware de carte mère, pilote de chipset USB, périphérique branché ou alimentation du port.
Points clés
- Usbxhci.sys est le pilote du contrôleur hôte USB 3.0 (xHCI), écrit avec les interfaces KMDF et chargé par Windows comme objet de périphérique de fonction dans la pile du contrôleur hôte.
- Windows charge la pile de pilotes USB 3.0 dès qu’un appareil est attaché à un contrôleur xHCI, et la pile USB 2.0 pour les contrôleurs eHCI, oHCI ou uHCI.
- Le fichier n’est pas à télécharger ni à remplacer. Le remplacer par une copie récupérée ailleurs casse la pile USB au lieu de la réparer.
- Sur un arrêt BUGCODE_USB_DRIVER (0x000000FE) avec un premier paramètre à 0x3, la documentation Microsoft indique un bug check généré par le pilote miniport USB, généralement en réponse à une défaillance matérielle.
- L’ordre utile : débrancher les périphériques USB, mettre à jour chipset et BIOS, puis seulement isoler le coupable avec le Vérificateur de pilotes.
À quoi sert usbxhci.sys
La documentation Microsoft sur les pilotes côté hôte USB décrit une pile à plusieurs étages. En bas, le pilote xHCI, soit Usbxhci.sys, initialise les registres du contrôleur et les structures de données en mémoire, traduit les demandes de transfert venues des couches supérieures en blocs de requête de transfert, les envoie au matériel puis propage les événements de fin de transfert vers le haut de la pile.
Juste au-dessus, l’extension du contrôleur hôte USB, Ucx01000.sys, valide les requêtes et les met en file d’attente avant qu’elles n’atteignent le pilote xHCI. Plus haut encore, Usbhub3.sys gère les hubs, énumère les appareils branchés sur leurs ports et crée un objet de périphérique pour chacun.
Cette architecture explique le symptôme. Usbxhci.sys est le dernier maillon logiciel avant le silicium : quand le contrôleur matériel répond de travers, c’est ce pilote qui se trouve sur la pile d’appels au moment de l’arrêt, donc c’est son nom qui s’affiche. Il est désigné par sa position, pas par sa faute.
Lire le code d’arrêt avant de toucher au matériel
Le nom de fichier ne suffit pas : c’est le code d’arrêt qui l’accompagne qui oriente le diagnostic. Notez-le sur l’écran bleu, ou relisez-le après coup dans l’Observateur d’événements.
Si ce code est BUGCODE_USB_DRIVER, sa valeur est 0x000000FE et son premier paramètre identifie le type de violation. La table officielle en liste plusieurs, dont trois parlantes pour ce cas :
- 0x1 : une erreur interne s’est produite dans la pile USB.
- 0x3 : le pilote miniport USB a généré un bug check, généralement en réponse à une défaillance matérielle.
- 0x5 : défaillance matérielle due à une adresse physique incorrecte trouvée dans une structure de données matérielles, avec l’identifiant PCI du contrôleur en deuxième paramètre.
Trois de ces valeurs désignent le matériel. Cela suffit à écarter la piste du fichier corrompu dès le départ. Le détail de ce code d’arrêt est traité dans l’article dédié à l’écran bleu BUGCODE_USB_DRIVER.
Solution 1 : débrancher pour isoler le périphérique
La pile USB 3.0 ne se réveille que pour les appareils attachés à un contrôleur xHCI. Un seul périphérique défaillant suffit à faire tomber le contrôleur entier.
Débranchez tout, sauf le clavier et la souris. Si l’écran bleu ne revient pas, rebranchez un appareil à la fois, en laissant plusieurs minutes d’usage entre chacun. Les suspects habituels sont les docks et hubs alimentés, les disques externes, les cartes de capture et les dongles de station d’accueil, parce qu’ils sollicitent le contrôleur en continu et tirent le plus de courant.
Testez aussi les ports directement sur la carte mère à l’arrière du boîtier plutôt que ceux de la façade, qui passent par un connecteur interne supplémentaire.
Solution 2 : mettre à jour le pilote de chipset et le BIOS
Le contrôleur xHCI fait partie du chipset ou d’une puce additionnelle de la carte mère. Son comportement dépend donc du pilote de chipset et du firmware, deux éléments que Windows Update ne remplace pas toujours.
Récupérez le pilote de chipset et la dernière version du BIOS sur la page de support du modèle exact de la carte mère ou du portable, pas sur un agrégateur de pilotes. Sur un portable, branchez l’alimentation avant une mise à jour de firmware et ne l’interrompez pas.
Pour la partie pilotes, Microsoft documente la mise à jour manuelle depuis le Gestionnaire de périphériques, section Contrôleurs de bus USB. Attention toutefois : sur un contrôleur xHCI géré par le pilote Microsoft en boîte, l’option de recherche automatique ne trouvera rien de plus récent, puisque le pilote vient de Windows lui-même.
Solution 3 : désinstaller les entrées USB et laisser Windows réénumérer
Quand une mise à jour de pilote s’est mal passée, la pile garde une configuration incohérente. La faire reconstruire est une opération réversible.
- Ouvrez le Gestionnaire de périphériques, puis développez Contrôleurs de bus USB.
- Faites un clic droit sur les entrées de contrôleur hôte extensible USB, puis Désinstaller l’appareil. Ne cochez pas la suppression du logiciel pilote.
- Redémarrez. Windows redétecte les contrôleurs et recharge la pile complète au démarrage.
Prévoyez un clavier PS/2 ou l’accès à distance si toutes les entrées disparaissent d’un coup sur une machine sans clavier interne. Les erreurs du Gestionnaire de périphériques qui suivent parfois cette opération sont décrites dans l’article sur le code 24, périphérique absent ou pilote mal installé.
Solution 4 : gestion de l’alimentation et suspension sélective
Les arrêts qui tombent à la sortie de veille méritent un test simple. Dans le Gestionnaire de périphériques, ouvrez les propriétés de chaque contrôleur hôte extensible USB et de chaque concentrateur USB racine, onglet Gestion de l’alimentation, puis décochez l’autorisation donnée à l’ordinateur d’éteindre ce périphérique pour économiser l’énergie.
Cette modification augmente légèrement la consommation. Elle sert de test : si les écrans bleus cessent, le problème se situe dans les transitions d’alimentation du contrôleur, ce qui renvoie au firmware de la carte mère plutôt qu’à Windows.
Solution 5 : identifier le vrai pilote fautif avec le Vérificateur de pilotes
Si les écrans bleus persistent, il reste à savoir quel pilote tiers déclenche la faute pendant que usbxhci.sys exécute son travail. C’est exactement l’objet de Driver Verifier, que Microsoft présente comme un outil de test surveillant en temps réel les pilotes en mode noyau pour détecter les appels de fonction non conformes.
Deux avertissements figurent dans cette documentation et ne sont pas facultatifs : l’exécution de l’outil peut provoquer le blocage de l’ordinateur, et il ne doit être lancé que sur des machines de test et de débogage. Sur un poste de travail utile, créez d’abord un point de restauration, activez la vérification sur les pilotes non signés par Microsoft uniquement, et sachez redémarrer en mode sans échec pour tout désactiver avec verifier /reset.
La méthode générale d’analyse d’un écran bleu, vidage mémoire inclus, est détaillée dans le guide des écrans bleus Windows 10 et 11. Le cas voisin du framework de pilotes en mode noyau est traité dans l’article sur l’écran bleu wdf01000.sys.
Quand ça ne vient pas de là
Deux pistes restent ouvertes après ces étapes. Une carte d’extension USB en PCIe défectueuse produit les mêmes arrêts et se teste en la retirant. Et une alimentation insuffisante, sur une machine où plusieurs disques externes tirent sur les ports, fait décrocher le contrôleur sans qu’aucun pilote soit en cause.
Si l’arrêt survient avant l’ouverture de session, le guide officiel de dépannage des erreurs d’écran bleu de Microsoft décrit le parcours de récupération à suivre, options de démarrage avancées comprises.
FAQ
Peut-on remplacer usbxhci.sys par une copie saine ?
Non. Le fichier est livré avec Windows et signé ; une copie d’origine inconnue échoue à la vérification de signature ou déstabilise la pile USB. Les réparations légitimes sont sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth.
Le pilote xHCI concerne-t-il aussi les périphériques USB 2.0 ?
Oui, dès qu’ils sont branchés sur un contrôleur xHCI : la documentation Microsoft indique que Windows charge la pile USB 3.0 en fonction du contrôleur, pas de la vitesse de l’appareil. Seuls les contrôleurs eHCI, oHCI et uHCI utilisent la pile USB 2.0.
Désactiver l’USB 3 dans le BIOS règle-t-il le problème ?
Cela peut faire disparaître l’écran bleu, en privant la machine de ses ports rapides. C’est un test de confirmation, pas une solution à garder.
Faut-il désinstaller le logiciel du fabricant de la carte mère ?
Oui, si un utilitaire de gestion USB ou d’overclocking est installé. Ces outils chargent leurs propres pilotes en mode noyau, et le Vérificateur de pilotes les désigne régulièrement.
Le problème peut-il venir d’un câble ?
Oui pour les liaisons USB 3, très sensibles à la qualité du câble et à sa longueur. Un câble non conforme dégrade la liaison et multiplie les erreurs de transfert que le contrôleur doit traiter.
Photo d’en-tête : Razor512, Wikimedia Commons, CC BY 2.0. La photo montre un contrôleur hôte xHCI sur carte d’extension ; sur la plupart des machines, ce contrôleur est intégré au chipset.
Sources : Microsoft Learn, pilotes côté hôte USB dans Windows · Microsoft Learn, bug check 0xFE BUGCODE_USB_DRIVER · Microsoft Learn, Driver Verifier · Microsoft Learn, dépannage des erreurs d’arrêt · Support Microsoft, mettre à jour les pilotes
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
