Pourquoi la barre des tâches se fige et l'Explorateur redémarre tout seul — et comment dénicher le coupable

La barre des tâches n'est pas une application à part

Tout ce que vous voyez du shell du bureau — la barre des tâches, la zone de notification, les icônes du bureau, chaque fenêtre de l'Explorateur Windows — vit dans un seul processus : explorer.exe. L'architecture héritée de Windows 95 est commode et fragile à la fois : un blocage, et toute la surface se fige ; un plantage, et tout disparaît d'un coup. Quand l'Explorateur meurt, Windows lance silencieusement une nouvelle instance, et la barre s'éteint une seconde avant de revenir propre : les applications ouvertes survivent, mais les icônes de la zone de notification se réenregistrent souvent mal, laissant des fantômes qui gèlent au clic.

Un gel sans redémarrage est le jumeau calme : le thread d'interface de l'Explorateur est bloqué en attente de quelque chose qui ne reviendra jamais. Les classiques : une extension de shell qui bloque à l'interrogation, une application de notification dont l'icône ne répond plus, un lecteur réseau devenu inaccessible et — sur les machines aux pilotes graphiques capricieux — une réinitialisation du pilote d'affichage (TDR) qui paralyse le shell entier pendant des secondes. Sous Windows 11, le menu Démarrer a reçu son propre processus hôte, mais la barre des tâches vit toujours dans l'Explorateur : la vieille méthode de diagnostic s'applique sans changement.

Coincer le coupable en dix minutes

Bonne nouvelle : l'Explorateur consigne presque tout ce qu'il fait de travers, dans deux endroits que presque personne n'ouvre. Dix minutes avec l'Observateur d'événements et un démarrage propre désignent généralement le coupable nommément ; deviner coûte plus cher.

• Gestionnaire des tâches > Explorateur Windows > Redémarrer — la solution en 10 secondes qui rend la barre sans redémarrer la machine
• Observateur d'événements > Journaux Windows > Application : événements 1000 (plantage) et 1002 (blocage) d'explorer.exe — le module fautif nomme le coupable
• ShellExView (NirSoft) — désactivez toutes les extensions de shell non Microsoft, puis réactivez-les par moitiés jusqu'au retour du gel
• Événement 4101, « le pilote d'affichage a cessé de répondre » — pointe le pilote GPU, pas l'Explorateur
• net use */delete — déconnectez les lecteurs réseau morts que le shell continue d'interroger
• Démarrage propre (msconfig) — si le gel disparaît, réactivez les éléments de démarrage par moitiés

Des réparations qui tiennent

Une fois le module fautif nommé, la réparation est généralement ennuyeuse. Un plantage dans un gestionnaire de menu contextuel tiers ou une icône de superposition meurt au moment où vous mettez à jour ou désinstallez l'application propriétaire — les overlays de synchronisation cloud et les archiveurs sont des habitués. Si l'Observateur d'événements montre des réinitialisations du pilote graphique, faites une réinstallation propre du pilote GPU au lieu d'accuser l'Explorateur : téléchargez-le chez le fabricant, désinstallez l'actuel, installez le neuf, et seulement après remettez les panneaux constructeur que vous utilisez vraiment.

Pour les gels sans aucun événement d'erreur, soupçonnez les logiciels voisins du métal : utilitaires exotiques qui s'injectent dans l'Explorateur, suites clavier-souris à crochets de shell et vieilles versions de programmes populaires. Gardez aussi la zone de notification honnête — chaque application au démarrage qui pose une icône est du code avec lequel l'Explorateur devra parler pour toujours : raccourcir la liste de démarrage prévient les gels autant que les boots lents. Et si les gels ont commencé juste après une mise à jour de fonctionnalités de Windows, vérifiez d'abord chez les éditeurs les mises à jour de leurs intégrations avant tout geste radical : ce que la mise à jour casse, c'est l'intégration, rarement Windows.

Questions et réponses

À lire ensuite