Explorateur Windows arrête de fonctionner clic droit sur fichier

Voici un problème très étrange qui m'est arrivé sur mon portable au travail.  Tout à débuté avec mon retour d'une semaine de vacance.  Le clic droit sur un fichier pour afficher le menu contextuel ne s'affichait pas, l'explorateur Windows arrêtait de fonctionner et restait complètement figé.

Le fameux menu.

Après plusieurs recherches et vérifications, je me suis rendu compte que le problème ne se produisait pas si j'utilisais un fichier avec une extension .exe.  Étrange... J'ai donc utilisé mon ami Procmon.exe  pour avoir plus de détail sur ce que l'explorateur Windows effectuait comme travail.  J'ai seulement remarqué qu'il semblait y avoir un vérification du type d'extension du fichier...

Rien de vraiment concluant.

J'ai fait des recherches sur internet pour voir s'il n'y avais pas d'autres usagers qui semblaient avoir le même problème.  Je suis tombé sur un site qui identifiait peut-être un conflit avec l'extension du fichier et que ceci pouvait être corrigé avec ShellExView de NirSoft.  Après avoir exécuté l'application, je n'ai rien vu de concluant.

Après une rage de désinstallation de logiciel non essentiel :o)  Le problème était toujours présent, donc le problème ne venait pas d'un logiciel qui venait d'être installé.

Et puis, par hasard en faisant mes tests, j'ai débranché le portable du réseau... Comme par magie, maintenant le menu fonctionne et sur tout les fichiers.  Donc, j'en ai conclu que l'explorateur devait chercher quelque chose sur le réseau, mais quoi?  J'ai donc démarré Wireshark.  J'ai remarqué qu'il y avait des requêtes qui étaient envoyés vers un serveur de fichiers qui avait été mis hors service depuis quelques temps.  Dans l'image suivante, #1 On peut voir que le DNS a toujours une entrée pour le serveur.  #2 La station essaie de communiquer avec le serveur, requête Ping et broadcast Netbios.

Communication réseau vers l'ancien serveur.

Donc, pourquoi ma station cherche-t-elle le vieux serveur sur le réseau?  Une recherche dans la base de registre Windows m'a permis de voir qu'il y avait toujours des traces du serveur dans la section HKEY_CLASSES_ROOT\applications\4eDimension.  La clé de registre Shell\(Par Défaut) était configurée à \\nomduserveur\path vers application 4D.  L'application 4eDimension n'était pas installée localement sur le poste mais était lancée à partir du partage. 

Exemple du registre car j'ai effacé la clé...

Le problème serait donc possiblement lié à une extension de fichier qui est associée à un logiciel sur un partage qui n'est plus disponible...  Pour vérifier, j'ai ouvert l'explorateur Windows -> Outils -> Options des dossiers -> Types de fichiers.  J'ai identifié l'extension .4DB qui était associée à l'application 4eDimension, j'ai effacé l'extension de fichier. Et Voilà! Problème résolu.

 

Dans la section "S'ouvre avec:" On pouvait voir 4eDimension.

Par la suite j'en ai profité pour effacer tout les clés en lien avec l'ancien serveur dans la base de registre.

Pourquoi ce problème est donc présent?  Si le partage n'était pas accessible, il semble que le "timeout" est étrangement long.  J'ai donc essayé de faire un test de connexion à un port du serveur avec Telnet et j'ai une connexion...??!?!?!  Une connexion sur une adresse IP qui ne répond pas au ping ?!?!?  Ça semble être un problème de Firewall, j'ai donc désactiver TrendMicro qui est installé sur mon poste et maintenant je suis incapable de me brancher au port.  Est-ce que le problème est dû à ceci? Je ne pourrais le dire pour l'instant mais il semble que ceci pourrait être dû à la combinaison de plusieurs éléments ensemble.

1- Le DNS a toujours l'entrée pour le serveur qui n'est plus en fonction.

2- Un type de fichier était associé à une application disponible sur un partage qui n'était plus accessible.

3- Le serveur n'était plus accessible mais je peux toujours faire une connexion à un port sur celui-ci.