Dell Vostro 3520 sous Windows 11 25H2, les périphériques USB fantômes
Une souris USB alimentée, reconnue par le BIOS, correctement énumérée par Windows, et pourtant totalement muette.
Une clé USB qui n'apparaît nulle part.
Le touchpad, lui, fonctionne.
Retour sur un diagnostic où les pistes classiques mènent toutes à une impasse, et où la cause réelle est la suspension sélective USB.
Le contexte
Poste concerné : Dell Vostro 3520, Windows 11 version 25H2, BIOS et pilotes à jour.
Aucun antivirus tiers, seul Microsoft Defender est présent.
Poste non rattaché à un domaine, non géré par Intune, sans agent de sécurité tiers.
Les symptômes
La souris USB s'allume une fois branchée. Dans le BIOS, elle est parfaitement fonctionnelle.
Une fois Windows démarré, le curseur reste immobile et les clics sont sans effet.
Le comportement est identique sur les trois ports USB testés, et identique sur l'écran de connexion, avant même l'ouverture de session.
Une clé USB branchée n'apparaît ni dans l'explorateur, ni dans le gestionnaire de périphériques.
Le touchpad intégré fonctionne normalement, ce qui permet de piloter le poste pendant tout le diagnostic.
La même souris fonctionne sans problème sur un autre ordinateur.
Les pistes écartées
Plusieurs causes habituelles ont été vérifiées et éliminées d'emblée.
Le matériel. La souris fonctionne dans le BIOS et sur un autre poste. Les ports délivrent bien le 5 volts. Trois ports différents produisent le même symptôme, ce qui exclut un port isolé défectueux.
Les filtres de classe. Aucun LowerFilters ni UpperFilters n'était présent sur les classes concernées. C'est la cause la plus souvent citée pour ce type de panne, et elle ne s'appliquait pas ici.
Les stratégies de blocage. Aucune restriction sous RemovableStorageDevices ni sous DeviceInstall\Restrictions. Le poste n'étant ni en domaine ni géré, aucune stratégie d'entreprise ne pouvait s'appliquer.
Un logiciel tiers. Aucun antivirus autre que Defender, aucun agent de contrôle de périphériques.
La panne connue de Windows 11 25H2. Une régression documentée par Microsoft empêche effectivement les périphériques USB de fonctionner, mais uniquement dans l'environnement de récupération WinRE. Microsoft précise que les périphériques continuent de fonctionner normalement dans Windows. Elle ne correspondait donc pas au cas présent.
L'étape qui a tout changé, la lecture des journaux
Plutôt que de continuer à tester des correctifs au hasard, l'étape décisive a été de lire ce que Windows raconte lui-même au moment du branchement.
Deux sources ont été exploitées. D'abord le journal des événements Kernel-PnP, dans sa vue Configuration. Ensuite le fichier setupapi.dev.log, qui trace toute installation de périphérique.
Commande utilisée, à lancer dans PowerShell en administrateur juste après avoir branché la souris :
Get-WinEvent -LogName 'Microsoft-Windows-Kernel-PnP/Configuration' -MaxEvents 20 | Select-Object TimeCreated, Id, @{N='Message';E={$_.Message -replace "`r`n",' '}} | Format-Table -AutoSize -Wrap
Et pour le journal d'installation :
Get-Content C:\Windows\INF\setupapi.dev.log -Tail 40
Le résultat a contredit l'hypothèse de départ. Loin d'être ignorée, la souris était traitée normalement de bout en bout.
L'événement 400 montre le périphérique configuré via input.inf avec le service HidUsb, puis via msmouse.inf avec le service mouhid.
L'événement 410 confirme le démarrage du périphérique, avec des champs de filtres inférieurs et supérieurs vides. Le fichier setupapi.dev.log se termine par un statut de sortie SUCCESS.
Autrement dit, la pile USB, le contrôleur, le hub racine, la pile HID et le pilote souris fonctionnaient tous.
Le raisonnement qui isole la cause
Trois constats suffisent à cerner le problème.
La panne existe avant l'ouverture de session.
Elle ne vient donc ni du compte utilisateur, ni d'un programme lancé au démarrage.
Le touchpad fonctionne. Il n'utilise pas l'USB, mais il emprunte la même chaîne que la souris pour transmettre ses mouvements à Windows. Cette chaîne est donc intacte.
La souris est bien reconnue et démarrée. Windows a réussi à lire ses informations d'identification, sinon il n'aurait jamais pu la classer comme souris.
Reste une seule explication : le périphérique est reconnu, mais il n'envoie plus rien.
La souris ne transmet aucun mouvement, et la clé USB ne va jamais jusqu'à se présenter comme un disque. Un seul mécanisme produit ces deux effets à la fois.
Ce mécanisme, c'est la mise en veille automatique des périphériques USB. Le périphérique est reconnu, démarré, puis endormi dans la foulée, et il ne se réveille jamais.
La vérification
Une commande suffit à confirmer :
powercfg /query SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3
Le retour affichait un index à 0x00000001 sur secteur comme sur batterie, pour le paramètre de suspension sélective USB. La fonctionnalité était donc active.
La correction
Deux actions, complémentaires, ont été nécessaires. La première seule n'a pas suffi.
Première action, désactiver la suspension sélective dans le mode de gestion de l'alimentation actif. Dans PowerShell en administrateur :
powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setdcvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setactive SCHEME_CURRENT
Il faut ensuite compléter dans le gestionnaire de périphériques.
Sur chaque entrée de la section Contrôleurs de bus USB, ouvrir les propriétés, aller dans l'onglet Gestion de l'alimentation, et décocher l'option autorisant l'ordinateur à éteindre le périphérique pour économiser l'énergie.
Si l'onglet n'apparaît pas sur une entrée, passer à la suivante.
Deuxième action, forcer la désactivation au niveau du pilote USB lui-même, ce qui prime sur le réglage du mode d'alimentation :
reg add "HKLM\SYSTEM\CurrentControlSet\Services\USB" /v DisableSelectiveSuspend /t REG_DWORD /d 1 /f
Un redémarrage est nécessaire après cette seconde action.
Après redémarrage, la souris et la clé USB fonctionnaient normalement.
Revenir en arrière
Les deux modifications sont réversibles.
Pour la suspension sélective, rejouer les deux premières commandes powercfg en remplaçant la valeur 0 finale par 1, puis relancer powercfg /setactive SCHEME_CURRENT.
Pour la clé de registre :
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\USB" /v DisableSelectiveSuspend /f
Contrepartie
Désactiver la suspension sélective USB empêche la mise en veille des périphériques inactifs.
Sur un portable, cela se traduit par une consommation légèrement plus élevée et une autonomie un peu réduite.
Sur un poste de travail principalement branché sur secteur, l'impact reste marginal et le gain en fiabilité le justifie largement.
Ce qu'il faut retenir
Lorsqu'un périphérique USB est visiblement détecté mais reste inerte, la tentation est grande d'enchaîner les correctifs génériques, réinstallation des pilotes, sfc, suppression des filtres de classe, voire réinstallation complète du système.
La bonne démarche est inverse. Il faut d'abord déterminer à quel étage la chaîne casse.
Un périphérique peut échouer à l'énumération, échouer à l'installation, ou bien réussir les deux et échouer au transfert des données.
Ces trois cas ont des causes totalement différentes et des corrections sans rapport entre elles.
Le journal Kernel-PnP et le fichier setupapi.dev.log permettent de trancher en quelques minutes.
Dans ce cas précis, ils ont évité une réinstallation de Windows.
Le fait que le touchpad continue de fonctionner, souvent perçu comme un simple détail rassurant, était en réalité une information de diagnostic majeure : il prouvait que toute la partie haute de la chaîne d'entrée était intacte, et réduisait d'autant le champ des causes possibles.