Plantages d’Explorer.exe : corriger les extensions shell comme un pro

février 8, 2026 • février 8, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Si Explorer.exe plante, vous n’avez pas un « problème Windows ». Vous avez un problème de plug‑in tant que l’inverse n’est pas prouvé. Explorer est le processus hôte pour la moitié de l’expérience bureau : navigation de fichiers, menus contextuels, aperçus, vignettes, onglets de propriétés. Et tout fournisseur proposant une intégration « utile » peut greffer du code dessus.

Résultat : une extension shell instable peut abattre votre gestionnaire de fichiers comme si c’était 1999 et qu’on découvrait les DLL. La bonne nouvelle : vous pouvez généralement corriger ça sans réinstaller Windows, sans prière, et sans « ne faites juste pas un clic droit ». Il vous faut une boucle de triage disciplinée : identifier la faute, isoler l’extension, la désactiver en sécurité, puis réactiver ce dont vous avez réellement besoin.

Comment Explorer.exe meurt réellement (et pourquoi les extensions shell sont des suspects de premier plan)

Explorer.exe est à la fois une interface utilisateur et une plateforme. Il affiche les dossiers et le bureau, mais il charge aussi une ménagerie d’objets COM qui implémentent des « extensions shell ». Ces extensions sont appelées pour :

Handlers de menu contextuel (entrées du menu clic droit)
Fournisseurs de vignettes (images, vidéos, PDF, fichiers CAO, formats propriétaires bizarres)
Handlers d’aperçu (volet d’aperçu à droite)
Handlers d’onglets de propriétés (onglets supplémentaires dans les propriétés de fichier)
Handlers de superposition d’icônes (badges d’état de synchronisation comme des coches)
Extensions d’espace de noms (dossiers virtuels, lecteurs cloud, vues spéciales)

Beaucoup de ces composants s’exécutent en processus. C’est‑à‑dire : Explorer charge la DLL de l’extension dans son propre espace mémoire. Si cette DLL déréférence des adresses invalides, fait un interblocage, corrompt les métadonnées du tas, ou lance une exception non gérée, Explorer en subit les conséquences.

Ceci est le modèle mental clé : le plantage d’Explorer est souvent « une DLL tierce qui plante à l’intérieur d’Explorer ». Vous ne réglez pas ça avec SFC et des prières. Vous le réglez en trouvant le module et en contrôlant ce qui est chargé.

Une citation à garder sous les yeux :

Idée paraphrasée — « L’espoir n’est pas une stratégie. » (largement attribuée en ingénierie et exploitation ; utilisez‑la comme rappel, pas comme référence)

Sachez aussi ces deux grandes classes d’échecs :

Plantage : Explorer se termine et redémarre (vous voyez la barre des tâches clignoter, les fenêtres disparaître puis revenir).
Blocage : Explorer devient non réactif (curseur en roue, « Ne répond pas », fenêtre de fichiers gelée). Parfois il se rétablit ; parfois il faut le tuer.

Les plantages sont généralement plus faciles : vous obtenez un module en faute, un code d’exception, et parfois un dump. Les blocages sont souvent liés aussi aux extensions shell, mais peuvent aussi venir de chemins réseau, lecteurs hors ligne, synchronisation cloud cassée ou pilotes de filtrage antivirus. Nous couvrirons les deux cas.

Mode d’intervention rapide

Ceci est l’ordre d’opérations « je veux mon gestionnaire de fichiers avant la prochaine réunion ». Ne partez pas en freestyle. Suivez le mode d’intervention.

1) Confirmer le déclencheur et isoler la surface affectée

Le plantage arrive‑t‑il au clic droit ? Suspectez les handlers de menu contextuel.
Le plantage survient‑il en sélectionnant un fichier (clic simple) ou en ouvrant un dossier ? Suspectez les fournisseurs de vignettes/handlers d’aperçu/onglets de propriétés.
Le plantage n’a lieu que dans un dossier spécifique ? Suspectez un handler lié au type de fichier, un cache de miniatures corrompu, ou une redirection réseau.
Le plantage n’affecte‑t‑il qu’un seul profil utilisateur ? Suspectez un enregistrement d’extension shell par utilisateur, une corruption de profil, ou une intégration par‑utilisateur d’une appli.

2) Lisez les preuves avant de « réparer » quoi que ce soit

Récupérez les dernières entrées Application Error pour Explorer.exe (Observateur d’événements). Identifiez le module en faute et le code d’exception.
Vérifiez les entrées Windows Error Reporting (WER) autour du même horaire ; elles nomment souvent le module plus clairement.

3) Prouvez que c’est une extension tierce avec un basculement propre

Démarrez en Mode sans échec, ou faites un Clean Boot, et voyez si Explorer se stabilise.
Si stable : poursuivez en désactivant les extensions shell non‑Microsoft et réactivez par lots.
Si instable : vous pourriez être face à une corruption du système, des problèmes de système de fichiers, des erreurs disque, ou un composant Windows central (moins fréquent, mais possible).

4) Désactivez d’abord les catégories les plus risquées

Handlers de menu contextuel
Fournisseurs de vignettes / handlers d’aperçu
Handlers de superposition d’icônes (surtout les clients de sync)

5) Capturez un dump de processus si le module n’est pas évident

Si l’Observateur d’événements est vague (souvent « ntdll.dll »), capturez un dump de l’instance Explorer qui plante et consultez la liste des modules chargés. Vous n’avez pas besoin de devenir un expert en débogage ; il s’agit d’identifier la DLL fournisseur qui n’a pas sa place.

Faits intéressants & courte histoire (la visite « pourquoi Windows est comme ça »)

Les extensions shell datent de l’ère Windows 95, quand Microsoft a poussé le shell comme plateforme extensible pour encourager l’intégration d’écosystème.
COM est le câblage : la plupart des extensions shell sont des objets COM enregistrés sous des clés ShellEx du registre, instanciés par Explorer à l’exécution.
Le mode in‑process de COM était un choix performance : charger des DLL dans Explorer évite le marshaling inter‑processus, rendant menus et vignettes instantanés. Cela signifie aussi qu’une mauvaise DLL peut écraser Explorer.
Les handlers de superposition d’icônes sont limités : Windows n’affiche qu’un petit nombre de superpositions à la fois, et plusieurs outils de sync se disputent ces emplacements, parfois dans un ordre imprévisible.
Le volet d’aperçu s’est généralisé sous Vista/Windows 7, entraînant une vague de bugs dans les handlers d’aperçu fournisseurs qui parseaient des formats complexes dans Explorer.
Les clients de synchronisation cloud ont banalisé les overlays et menus contextuels : OneDrive, Dropbox, Box, Google Drive et des outils d’entreprise injectent des intégrations—utiles jusqu’à la mise à jour qui casse tout.
Windows Error Reporting (WER) a changé la donne : après XP, le reporting de crash est devenu plus structuré, et les journaux d’événements ont commencé à afficher le « faulting module name » de manière exploitables pour les admins.
« Faulting module: ntdll.dll » est généralement un symptôme, pas la cause : ntdll est l’endroit où les exceptions remontent ; le vrai coupable est souvent la DLL tierce qui a corrompu la mémoire plus tôt.
Le comportement de redémarrage d’Explorer est intentionnel : Windows le relance pour garder le bureau utilisable, ce qui est bien—jusqu’à entrer en boucle de plantage et vous empêcher de cliquer quoi que ce soit.

Blague #1 : Explorer charge les extensions shell comme une conférence accueille des sponsors : un mauvais stand et soudain tout le monde est ruiné.

Tâches pratiques : commandes, sorties, décisions

Voici des tâches pratiques à exécuter depuis un terminal PowerShell élevé (les commandes montrées sont utilisables dans un environnement Windows typique). Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie et la décision à prendre.

Task 1: Confirm Explorer restarts and collect basic crash timing

cr0x@server:~$ tasklist /FI "IMAGENAME eq explorer.exe"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
explorer.exe                  6124 Console                    1     82,340 K

Ce que ça signifie : Explorer tourne actuellement avec le PID 6124. Si ce PID change après chaque plantage, vous êtes en boucle de redémarrage.

Décision : Si le PID change pendant le symptôme, passez immédiatement aux tâches Observateur d’événements/WER ; ne perdez pas de temps sur « peut‑être c’est le réseau ».

Task 2: Pull recent Explorer application errors from Event Log

cr0x@server:~$ wevtutil qe Application /q:"*[System[(EventID=1000)]] and *[EventData[Data='explorer.exe']]" /c:5 /f:text
Event[0]:
  Log Name: Application
  Source: Application Error
  Event ID: 1000
  Faulting application name: explorer.exe, version: 10.0.22621.1
  Faulting module name: acmecadthumbs.dll, version: 4.2.0.18
  Exception code: 0xc0000005
  Fault offset: 0x000000000001a2f0

Ce que ça signifie : Le crash s’est produit dans acmecadthumbs.dll (un fournisseur de vignettes). L’exception 0xc0000005 est une violation d’accès—du code natif buggy classique.

Décision : Désactivez d’abord les extensions de vignette/aperçu de ce fournisseur. Ne commencez pas par SFC.

Task 3: Pull Windows Error Reporting (WER) crash entries for Explorer

cr0x@server:~$ wevtutil qe "Microsoft-Windows-WER-SystemErrorReporting/Operational" /q:"*[System[(EventID=1001)]]" /c:5 /f:text
Event[0]:
  Log Name: Microsoft-Windows-WER-SystemErrorReporting/Operational
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Fault bucket: 1234567890123456789, type 5
  Event Name: APPCRASH
  P1: explorer.exe
  P4: acmecadthumbs.dll

Ce que ça signifie : WER confirme le même module en faute. Quand les journaux Application Error sont vagues, WER est souvent plus clair.

Décision : Si WER pointe systématiquement vers une DLL, considérez‑la comme le principal suspect et isolez‑la.

Task 4: Check if the crash is tied to Preview Pane

cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Modules\GlobalSettings\Sizer" /v PreviewPaneSizer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Modules\GlobalSettings\Sizer
    PreviewPaneSizer    REG_BINARY    2a000000...

Ce que ça signifie : Le volet d’aperçu est configuré (ce n’est pas la preuve qu’il est activé en ce moment), mais c’est un indice que l’utilisateur l’utilise. Beaucoup de handlers d’aperçu sont fragiles.

Décision : Si les plantages surviennent lors de la sélection de fichiers, désactivez temporairement le volet d’aperçu et testez ; si stable, concentrez‑vous sur les handlers d’aperçu pour les types de fichiers impliqués.

Task 5: Clean boot to separate shell extensions from startup chaos

cr0x@server:~$ bcdedit /enum {current}
Windows Boot Loader
-------------------
identifier              {current}
path                    \Windows\system32\winload.efi
safeboot                Minimal

Ce que ça signifie : Ce système est configuré pour démarrer en Mode sans échec (Minimal). (Vous le mettriez intentionnellement ; ne le laissez pas activé indéfiniment.)

Décision : Si Explorer se comporte correctement en Mode sans échec, vous poursuivez presque certainement la piste d’un composant tiers. Planifiez la boucle désactiver/réactiver.

Task 6: Turn off Safe Mode when you’re done testing

cr0x@server:~$ bcdedit /deletevalue {current} safeboot
The operation completed successfully.

Ce que ça signifie : Le prochain redémarrage sera normal. Les gens oublient cela et se demandent ensuite pourquoi le VPN ne démarre pas.

Décision : Retirez toujours le flag safeboot après avoir confirmé le comportement. Gardez votre environnement de test sous contrôle.

Task 7: Enumerate non-Microsoft Explorer shell extensions via PowerShell registry scan

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved' | Select-Object -First 5"
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
PSChildName  : {0E5AAE11-A475-4C5B-AB00-C66DE400274E}
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Ce que ça signifie : Cette clé est un endroit où les extensions shell approuvées sont listées (ce n’est pas le seul). Vous devrez résoudre les CLSID vers des DLL/éditeurs.

Décision : Utilisez‑la comme inventaire de départ ; puis mappez les CLSID vers les chemins DLL InprocServer32 et identifiez les fournisseurs.

Task 8: Map a CLSID to its in-process DLL

cr0x@server:~$ reg query "HKCR\CLSID\{0E5AAE11-A475-4C5B-AB00-C66DE400274E}\InprocServer32" /ve
HKEY_CLASSES_ROOT\CLSID\{0E5AAE11-A475-4C5B-AB00-C66DE400274E}\InprocServer32
    (Default)    REG_SZ    C:\Program Files\AcmeCloud\acmeshellext.dll

Ce que ça signifie : Ce CLSID est implémenté par acmeshellext.dll provenant de « AcmeCloud » (hypothétique). C’est une extension shell tierce chargée dans Explorer.

Décision : Si ce fournisseur correspond au déclencheur du plantage (clic droit, overlays, aperçus), désactivez‑le ensuite.

Task 9: List modules loaded into Explorer (when it’s stable long enough)

cr0x@server:~$ powershell -NoProfile -Command "(Get-Process explorer).Modules | Select-Object -First 10 | Format-Table ModuleName,FileName -Auto"
ModuleName        FileName
----------        --------
explorer.exe      C:\Windows\explorer.exe
ntdll.dll         C:\Windows\SYSTEM32\ntdll.dll
shell32.dll       C:\Windows\SYSTEM32\shell32.dll
acmeshellext.dll  C:\Program Files\AcmeCloud\acmeshellext.dll

Ce que ça signifie : Vous pouvez voir des DLL tierces chargées en processus. C’est brut mais efficace quand vous pouvez corréler « module chargé » avec « le plantage survient quand je fais un clic droit ».

Décision : Si une DLL fournisseur suspecte apparaît et correspond à votre déclencheur, désactivez cette extension et retestez.

Task 10: Check system file integrity (only after extension triage)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.
Windows Resource Protection did not find any integrity violations.

Ce que ça signifie : Les fichiers système semblent corrects. Cela n’efface pas les extensions tierces ; cela signifie juste que Windows n’est pas manifestement corrompu.

Décision : Si SFC est propre et que vous avez un module tiers en faute, arrêtez. Ne continuez pas à « réparer Windows » sans raison.

Task 11: Repair component store (when SFC reports issues it can’t fix)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
The restore operation completed successfully.
The operation completed successfully.

Ce que ça signifie : Le magasin de composants a été réparé. Cela aide si Explorer plante à cause de composants système corrompus (plus rare que les bugs d’extensions shell, mais ça arrive).

Décision : Si vous plantez encore après DISM+SFC, revenez à l’isolation des extensions shell. La corruption n’est pas votre bouc émissaire par défaut.

Task 12: Check the disk quickly for obvious trouble

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
Windows has scanned the file system and found no problems.
No further action is required.

Ce que ça signifie : Les métadonnées de base du système de fichiers ont l’air correctes. Si vous voyez des erreurs ici, les problèmes d’Explorer peuvent en être des dégâts collatéraux.

Décision : Si des erreurs sont trouvées, planifiez une fenêtre de réparation. N’ignorez pas les problèmes disque en traquant des gremlins d’UI.

Task 13: Identify slow network dependencies that look like “Explorer is frozen”

cr0x@server:~$ net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           Z:        \\fileserver01\design      Microsoft Windows Network
Unavailable  Y:        \\oldnas\archive           Microsoft Windows Network

Ce que ça signifie : Les lecteurs mappés incluent une cible indisponible. Explorer adore sonder ces cibles et « geler » en énumérant des dossiers ou « Ce PC ».

Décision : Supprimez ou corrigez les mappings indisponibles (surtout les NAS legacy). Si votre symptôme est un blocage, pas un plantage, c’est à forte valeur ajoutée.

Task 14: Remove a dead mapped drive cleanly

cr0x@server:~$ net use Y: /delete
Y: was deleted successfully.

Ce que ça signifie : Explorer cessera d’essayer de résoudre ce chemin, ce qui peut éliminer des blocages ou de longues attentes dans les boîtes de dialogue de fichiers.

Décision : Si cela améliore la stabilité, votre problème n’était pas « Explorer » mais l’E/S et les timeouts.

Task 15: Check for third-party filter drivers (AV/DLP) that can destabilize Explorer file operations

cr0x@server:~$ fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------    --------    -----
WdFilter                        10               328010      0
acmeavflt                        6               321900      0

Ce que ça signifie : Les minifiltres du système de fichiers sont dans la pile. La plupart sont corrects. Certains ne le sont pas. Ils peuvent provoquer des blocages pendant l’énumération ou des plantages liés aux intégrations shell associées.

Décision : Si votre crash/blocage est corrélé à l’accès fichier (ouverture de dossiers, vignettes), envisagez de désactiver temporairement le produit de sécurité tiers dans un test contrôlé—ou au moins mettez‑le à jour.

Task 16: Capture a quick “what changed” list (recent installs/updates)

cr0x@server:~$ wmic qfe get HotFixID,InstalledOn | more
HotFixID  InstalledOn
KB5034765 1/12/2026
KB5034204 1/28/2026

Ce que ça signifie : Affiche les mises à jour installées. Pas parfait pour les installations d’applications, mais utile pour corréler « Explorer a commencé à planter mardi » avec le calendrier de patch.

Décision : Si le plantage a commencé juste après une mise à jour d’un fournisseur (client de sync, archiver, visionneuse CAO), priorisez cette extension même si des mises à jour Windows ont aussi eu lieu.

Stratégie d’isolation qui ne vous fera pas perdre l’après‑midi

Voici l’erreur que je vois en environnement réel : les gens désactivent une chose, redémarrent, testent, réactivent, redémarrent, testent… jusqu’à la mort thermique de l’univers. Il vous faut une mentalité de recherche binaire et une préférence pour les catégories les plus susceptibles de planter.

Step 1: Classify the trigger

Écrivez‑le comme un rapport d’incident :

Action déclenchante : « Clic droit sur n’importe quel fichier » vs « Ouvrir Téléchargements » vs « Sélectionner un PDF »
Portée : « Tous les dossiers » vs « Un partage » vs « Un type de fichier »
Portée utilisateur : « Seulement moi » vs « tout le service »
Timing : « Après l’installation de X » vs « Après une mise à jour Windows »

Step 2: Confirm with Safe Mode or Clean Boot

Le Mode sans échec est un gros marteau, mais il est définitif. Si Explorer est stable en Mode sans échec, vous pouvez cesser de remettre en question la réalité.

Blague #2 : Le Mode sans échec, c’est comme le café décaféiné : moins fun, mais c’est ainsi que vous découvrez ce qui cause vraiment les secousses.

Step 3: Disable non-Microsoft shell extensions (but do it with control)

Sur le terrain, deux outils sont courants : Sysinternals Autoruns et NirSoft ShellExView. Utilisez ce que votre organisation autorise. Le principe est le même :

Trier par Company et masquer les entrées Microsoft.
Désactiver par lots (par ex. 5–10 à la fois), puis redémarrer Explorer (pas tout le système sauf si nécessaire).
Quand la stabilité revient, réactiver la moitié du dernier lot pour affiner.

Si vous ne pouvez pas utiliser d’outils tiers (endpoints verrouillés), vous pouvez encore faire beaucoup via le mapping de registre et la désinstallation du produit parent. Mais en entreprise, la résolution la plus rapide est généralement : « désactiver l’extension d’abord, puis décider de mettre à jour, rétrograder ou supprimer le produit ».

Step 4: Restart Explorer safely between tests

Explorer a besoin d’un redémarrage pour décharger les extensions en processus. Vous pouvez soit vous déconnecter/reconnecter, soit redémarrer le processus. Le redémarrage est plus rapide :

cr0x@server:~$ taskkill /F /IM explorer.exe
SUCCESS: The process "explorer.exe" with PID 6124 has been terminated.

cr0x@server:~$ start explorer.exe

Ce que ça signifie : Vous forcez un rechargement propre d’Explorer et de ses extensions.

Décision : Faites cela entre chaque itération désactiver/réactiver pour tester l’ensemble d’extensions effectif.

Step 5: If logs blame ntdll.dll, don’t panic—raise your observability

Quand le module en faute est ntdll.dll ou KERNELBASE.dll, c’est souvent l’endroit où le crash est rapporté, pas l’endroit où se trouve le bug. La correction consiste à capturer plus de contexte :

Regardez WER pour des indices supplémentaires « P4 ».
Listez les modules chargés dans Explorer et comparez aux extensions connues.
Capturez un dump et examinez la liste de modules (souvent suffisant sans analyse profonde de la pile).

Trois micro‑récits en entreprise

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Le helpdesk a escaladé un ticket « Windows est cassé » d’une équipe de design. Explorer plantait chaque fois qu’ils ouvraient un dossier de projet. Pas « parfois ». Pas « rarement ». À chaque fois. L’admin de garde a fait ce que beaucoup font sous pression : SFC, DISM, reboot, et préparation d’une réimage.

Mais le plantage était ciblé : seulement cette équipe, seulement les dossiers de projet, seulement sur des machines avec une suite de plug‑ins CAO particulière. L’hypothèse erronée était subtile : « si Explorer plante, c’est la corruption de l’OS ». C’est narratif et ça autorise à re‑flasher la machine.

Quelqu’un a finalement extrait l’événement Application Error et a vu que le module en faute n’était pas Windows. C’était un fournisseur de vignettes pour le type de fichier CAO. Le dossier de projet contenait des milliers de ces fichiers ; Explorer essayait de leur faire des vignettes au fur et à mesure que l’utilisateur naviguait. Bim.

La correction fut ennuyeuse : désactiver ce handler de vignette et pousser un plugin mis à jour par le fournisseur. Pas de réimage. Pas d’interruption majeure. Le rapport d’incident a gardé une ligne importante : « Nous avons supposé que l’hôte était en faute plutôt que le plugin chargé dedans. » Cette phrase a évité les trois incidents suivants.

Mini‑récit 2 : L’optimisation qui a mal tourné

Une équipe desktop voulait améliorer la performance perçue sur des partages de fichiers. Ils ont piloté un « accélérateur » tiers ajoutant actions au menu contextuel, overlays et cache agressif. En démo c’était génial : clic droit pour uploader, badges partout, prélecture « intelligente ».

Puis la contrepartie est arrivée. Explorer ne plantait pas toujours—il se bloquait. Les boîtes de dialogue de fichiers se figeaient par intermittence. Les utilisateurs ne pouvaient plus attacher des fichiers aux emails. Le fournisseur de l’accélérateur criait « problème réseau ». Le réseau criait « problème desktop ». Tout le monde avait raison et tort.

Procmon montrait qu’Explorer attendait le handler de l’accélérateur, qui attendait à son tour un appel réseau vers un endpoint de service qui parfois se bloquait. Comme l’extension s’exécutait en processus, le thread UI était bloqué. L’optimisation rendait le système plus rapide quand ça marchait et inutilisable quand ça ne marchait pas. Ce n’est pas de la performance ; c’est du hasard.

Le plan de retour arrière fut la solution : désactiver overlays et handlers contextuels via une politique, en ne laissant que la fonctionnalité core de sync. La « valeur ajoutée » du produit était la fragilité. Une fois retirée, Explorer est redevenu ennuyeux—au meilleur sens du terme.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un service finance avait une pratique stricte : toute appli desktop qui installait des intégrations shell devait d’abord passer par un petit ring pré‑production. Rien d’extraordinaire—juste quelques utilisateurs multiservices et une revue hebdo des métriques de crash. La pratique était moquée comme une « cérémonie », jusqu’à ce qu’elle empêche un gros bordel.

Un outil de compression populaire a livré une mise à jour ajoutant de nouveaux handlers de menu contextuel et un composant d’aperçu. Dans le ring pilote, Explorer a commencé à planter au clic droit dans des dossiers avec beaucoup d’archives. Les journaux d’événements pointaient la nouvelle DLL handler. Le ring l’a détecté avant que la mise à jour n’atteigne la flotte entière.

La correction fut simple et chirurgicale : geler la mise à jour, désactiver le nouveau handler via la configuration d’entreprise, et attendre le patch du fournisseur. Pas d’intervention héroïque. Pas de réimages d’urgence. Pas de « utilisez juste l’app web pendant une semaine ».

C’est le genre de pratique qui a l’air terne sur une diapositive et brillante en production. Le but n’est pas d’être astucieux. C’est d’éviter des indisponibilités prévisibles.

Erreurs fréquentes : symptôme → cause racine → fix

Cette section est volontairement spécifique. Si vous reconnaissez le symptôme, sautez le débat philosophique et appliquez le correctif.

1) Le clic droit provoque un plantage instantané d’Explorer

Symptôme : Explorer redémarre dès que vous faites un clic droit sur un fichier/dossier/espace vide.
Cause racine : Handler de menu contextuel buggy (souvent archivers, clients de sync, contrôle de source, outils de sécurité).
Correction : Désactivez les handlers de menu contextuel non‑Microsoft par lots ; redémarrez Explorer entre les tests ; mettez à jour ou désinstallez l’application parent une fois identifiée.

2) Le plantage survient en sélectionnant des fichiers (sans les ouvrir)

Symptôme : Un clic simple sur un fichier ou le déplacement de la sélection provoque un plantage ; l’ouverture du fichier depuis l’application peut fonctionner.
Cause racine : Handler d’aperçu ou fournisseur de vignette qui plante en parsant les métadonnées/contenu du fichier.
Correction : Désactivez le volet d’aperçu ; videz le cache de vignettes ; désactivez les extensions de vignette/aperçu pour le type de fichier ; mettez à jour le visualiseur/plugin.

3) Explorer se bloque 30–120 secondes à l’ouverture de « Ce PC » ou des boîtes de dialogue

Symptôme : Ne répond pas, puis finit par récupérer. Les boîtes de dialogue de sélection de fichiers sont aussi lentes.
Cause racine : Lecteurs mappés hors ligne, partages réseau inaccessibles, profils home obsolètes, ou une extension shell faisant des I/O réseau sur le thread UI.
Correction : Supprimez les mappings morts ; corrigez les cibles DFS ; désactivez les overlays de sync ; vérifiez la résolution de noms ; utilisez Procmon pour confirmer l’appel bloquant.

4) Les rapports de crash d’Explorer incriminent ntdll.dll

Symptôme : L’Observateur d’événements montre le module en faute ntdll.dll ou KERNELBASE.dll.
Cause racine : Corruption mémoire antérieure par une extension chargée en processus ; Windows rapporte juste l’endroit où ça a planté.
Correction : Utilisez les logs WER ; listez les modules chargés ; désactivez les extensions tierces suspectes ; capturez un dump si nécessaire.

5) Les plantages n’arrivent que dans un dossier

Symptôme : Naviguer dans un dossier spécifique déclenche le plantage ; les autres dossiers vont bien.
Cause racine : Un type de fichier problématique (vignette/aperçu), un fichier corrompu, ou les paramètres d’affichage du dossier invoquant un handler particulier.
Correction : Changez l’affichage du dossier en « Détails » et désactivez les vignettes ; déplacez les fichiers par moitiés pour trouver le type/fichier en faute ; puis traitez le handler responsable.

6) Un seul profil utilisateur voit le problème

Symptôme : Même machine, autre utilisateur se connecte, Explorer est stable.
Cause racine : Intégration shell par‑utilisateur, paramètres Explorer corrompus, enregistrement COM par‑utilisateur, ou add‑ins configurés par profil.
Correction : Testez avec un nouveau profil ; réinitialisez les paramètres d’Explorer ; supprimez les intégrations par utilisateur ; réinstallez l’application fautive pour cet utilisateur si nécessaire.

7) Explorer plante en visualisant des ZIPs ou archives comme des dossiers

Symptôme : Cliquer sur des archives ou faire un clic droit dessus provoque un plantage.
Cause racine : Conflit d’extensions shell d’outils d’archivage avec la gestion des dossiers compressés de Windows ou avec un autre archiver.
Correction : Désactivez l’intégration shell d’un des archivers ; conservez un seul « propriétaire » des menus contextuels ; mettez à jour vers une version stable.

Checklists / plan pas à pas

Checklist A: Triage sur une machine (15–45 minutes)

Notez le déclencheur (clic droit vs sélection vs ouverture vs dossier spécifique).
Collectez les preuves : Event ID 1000 (Application Error) + WER 1001 autour de l’heure du plantage.
Test Mode sans échec : confirmez si c’est tiers.
Désactivez les extensions shell non‑Microsoft dans la catégorie probable (menu contextuel d’abord pour les plantages au clic droit).
Redémarrez Explorer après chaque jeu de changements.
Recherche binaire en réactivation pour identifier l’extension spécifique.
Décidez du correctif : mise à jour du fournisseur, rétrogradation, ou désinstallation de l’intégration.
Vérifiez sur plusieurs déclencheurs : boîtes de dialogue fichiers, clic droit, volet d’aperçu, partages réseau.
Documentez le coupable : nom de la DLL, application parent, version, et action déclenchante.

Checklist B: Réponse d’incident d’équipe (1–2 jours, mais contrôlée)

Confirmez la portée : quel service, quelle version OS, quelles versions d’application.
Choisissez deux machines sacrifiables : une « connue bonne », une « connue mauvaise ».
Standardisez la repro : même dossier, même action, même timing.
Centralisez des extraits de logs : nom et version du module en faute depuis plusieurs machines.
Mitigez rapidement : désactivez l’extension shell via outils d’entreprise ou désinstallez l’app parent si nécessaire.
Stabilisez : stoppez le déploiement, bloquez la mise à jour, ou poussez une build corrigée.
Prévenez la récurrence : placez les apps intégrant le shell derrière un ring pilote et suivez le taux de crash d’Explorer.

Checklist C: Quand vous suspectez stockage/réseau, pas les extensions

Vérifiez les lecteurs mappés indisponibles (net use).
Vérifiez une résolution de noms bloquée (les problèmes DNS se manifestent comme « Explorer se bloque »).
Identifiez les pilotes de filtrage dans la pile fichiers (fltmc).
Confirmez rapidement la santé disque (chkdsk /scan).
Si le blocage est reproductible, tracez avec Procmon et cherchez de longues attentes sur des chemins réseau ou des filtres de sécurité.

FAQ

1) Est‑ce sûr de désactiver des extensions shell ?

Oui, si vous désactivez les extensions tierces et le faites contrôlément. Au pire, vous perdez une entrée de menu clic droit ou une icône d’overlay jusqu’à la réactivation. Le système d’exploitation ne s’effondrera pas.

2) Pourquoi une extension de menu contextuel plante tout le processus Explorer ?

Parce que la plupart des extensions shell sont des DLL COM en processus. Elles s’exécutent dans l’espace mémoire d’Explorer. Si elles plantent, Explorer plante. C’est rapide quand ça marche et brutal quand ça casse.

3) L’Observateur d’événements indique que le module en faute est ntdll.dll. Cela signifie‑t‑il que Windows est cassé ?

Pas automatiquement. ntdll est l’endroit où les exceptions remontent. La corruption mémoire provient souvent d’une extension tierce plus tôt. Utilisez les logs WER, les listes de modules chargés et les tests d’isolation.

4) Quelle est la façon la plus rapide de prouver que c’est une extension ?

Le Mode sans échec. Si Explorer est stable là‑dessus, vous avez presque certainement du code tiers en cause (extensions, pilotes ou composants injectés).

5) Dois‑je vider le cache de vignettes ?

Cela vaut le coup quand le déclencheur est « ouvrir un dossier avec beaucoup de médias/CAO/PDF » ou « sélectionner des fichiers plante Explorer ». Mais vider le cache traite le symptôme ; vous devez toujours corriger le handler buggy.

6) Pourquoi les plantages n’apparaissent‑ils que dans un dossier ?

Ce dossier contient probablement des fichiers qui déclenchent un chemin handler spécifique : génération de vignettes pour un format propriétaire, parsing d’aperçu, ou extraction de propriétés. Ou la vue du dossier force la génération de vignettes/aperçus.

7) L’antivirus ou le DLP peut‑il causer des plantages d’Explorer ?

Oui. Pas toujours sous forme de « faulting module name: antivirus.dll » (même si c’est possible), mais via des pilotes de filtrage qui interceptent les opérations fichiers, plus des intégrations shell optionnelles pour actions de scan. Si des blocages coïncident avec l’accès fichier, incluez les filtres dans votre hypothèse.

8) Si la désactivation des extensions corrige le problème, dois‑je désinstaller toute l’application ?

Ça dépend. Si l’application est nécessaire (client de sync, agent DLP), conservez‑la et désactivez uniquement l’intégration shell si c’est supporté. Si c’est optionnel (un archiver supplémentaire), la désinstallation est souvent la solution la plus propre à long terme.

9) Pourquoi les boîtes de dialogue Ouvrir/Enregistrer se bloquent aussi ?

Ces boîtes de dialogue utilisent souvent les mêmes composants shell et la même logique d’énumération qu’Explorer. Si Explorer se bloque sur des chemins réseau ou des handlers, les boîtes de dialogue héritent du problème.

10) Comment prévenir cela dans une entreprise ?

Mettez les applications intégrant le shell derrière un ring pilote, suivez le taux de crash d’Explorer via la télémétrie d’événements, et standardisez sur moins d’outils « auxiliaires ». Aussi : ne laissez pas trois clients de sync se battre pour les emplacements d’overlay.

Conclusion : prochaines étapes qui tiennent

Les plantages d’Explorer.exe ne sont pas mystiques. Ils sont généralement un mauvais invité vivant dans la maison d’Explorer. Votre travail est d’identifier l’invité (module en faute), confirmer le motif (déclencheur), et le mettre dehors (désactiver l’extension) sans expulser tout le voisinage (réinstaller Windows).

Faites ceci ensuite :

Récupérez les 5 derniers événements de plantage d’Explorer et notez le module en faute et le code d’exception.
Testez en Mode sans échec pour prouver l’implication d’un tierce.
Désactivez les extensions non‑Microsoft dans la catégorie correspondant à votre déclencheur (menu contextuel vs aperçu/vignette).
Redémarrez Explorer, retestez, puis recherchez de façon binaire jusqu’au coupable unique.
Mettez à jour/rétrogradez/désinstallez le produit parent et documentez la correction pour que la prochaine personne n’« arrange pas Windows » pendant trois heures.

Si vous opérez à grande échelle, traitez les extensions shell comme des pilotes kernel : privilégiées, dangereuses, et dignes d’un ring de déploiement. Parce qu’elles le sont effectivement. Explorer se contente de les rendre conviviales.