Fichier en cours d'utilisation : Microsoft explique enfin ce vieux problème de Windows
Un responsable technique de Microsoft s'est penché sur le fameux message d'erreur prétendant qu'un fichier serait "en cours d'utilisation" quand on veut le supprimer. Un bug agaçant qui persiste pourtant depuis des décennies.
Tout utilisateur de Windows a déjà rencontré le problème. On quitte une application, on tente de supprimer ou de renommer un fichier qu'elle utilisait, et Windows répond invariablement la même chose : "Opération impossible, le fichier est en cours d'utilisation par un autre programme". Un message d'erreur agaçant, frustrant, et surtout incompréhensible dans la mesure où le logiciel qui avait ouvert ledit fichier est bel et bien fermé ! Et si le message a quelques variantes en faisant parfois allusion à un dossier, le problème reste le même. Il n'est pas nouveau : on le rencontre depuis des décennies, avec différentes versions de Windows. Et il ne se limite pas à l'Explorateur : on a parfois droit à un message similaire au sein d'une application, y compris celles de Microsoft comme Word ou Office !
Comme le rapporte Windows Latest, Mark Russinovich, aujourd'hui directeur technique d'Azure et Technical Fellow chez Microsoft, vient d'apporter une explication détaillée à ce bug qu'il a lui-même rencontré pour la première fois dans les années 1990 – et auquel il a consacré plusieurs outils de diagnostic devenus des références, à commencer par Handle et Process Explorer.
Fichier en cours d'utilisation : un mystère vieux comme Windows
Pour comprendre l'origine du problème, il faut revenir à un mécanisme fondamental de Windows : le handle de fichier, une sorte de jeton numérique. Chaque fois qu'un programme ouvre un fichier, Windows crée cette référence, qui permet au système de savoir précisément quel programme accède à quel fichier à un instant donné. Windows refuse de supprimer ou de renommer un fichier tant qu'un handle ouvert existe sur celui-ci, car cela pourrait corrompre des données encore manipulées par le programme.
En théorie, fermer une application libère automatiquement tous ses handles. En pratique, ce n'est pas toujours le cas : un processus en arrière-plan peut continuer à détenir le fichier sans que rien, à l'écran, ne le laisse deviner. D'où ce message qui semble mentir à l'utilisateur.
Russinovich identifie trois raisons courantes qui expliquent qu'un fichier reste verrouillé alors que le programme semble pourtant fermé. La première, et la plus fréquente, concerne l'antivirus. Lorsqu'un logiciel de sécurité analyse un fichier, il ouvre lui-même un handle au niveau système. Même si Word ou un lecteur multimédia s'est complètement fermé, l'antivirus peut continuer de scanner ce même fichier en arrière-plan, et le maintenir verrouillé sans que rien ne le laisse deviner.
La deuxième cause concerne les environnements en réseau. Si un autre appareil connecté au même réseau a effectué une opération qui a ouvert le fichier, ce processus distant peut encore détenir un handle actif sur celui-ci – un cas fréquent dans les entreprises où plusieurs postes partagent des dossiers communs.
La troisième cause, la plus délicate à diagnostiquer selon Russinovich, concerne les bibliothèques DLL. Si le fichier en question est chargé dans un processus en tant que DLL, il n'apparaît pas comme un handle de fichier classique, mais comme une référence en mémoire. Aucun outil standard ne signale alors de handle ouvert, mais le fichier reste verrouillé car il est cartographié dans l'espace d'adressage d'une application. Dans ce cas précis, fermer le handle ne suffit pas : il faut fermer entièrement l'application concernée pour libérer le verrou.
Fichier en cours d'utilisation : des solutions pour contourner le problème
Face à ce diagnostic, Russinovich propose plusieurs solutions, de la plus technique à la plus accessible, certaines étant déjà bien connues des bidouilleurs et des utilisateurs avertis (voir notre article pratique). Dans les années 1990, déjà confronté au problème, il avait développé Handle, un utilitaire en ligne de commande qui liste tous les handles ouverts sur le système, avec le nom et l'identifiant du processus responsable de chacun – une recherche par nom de fichier permet d'aller directement à la source du blocage.
Process Explorer, son équivalent graphique, reste aujourd'hui l'outil de référence pour les utilisateurs avancés. Le raccourci Ctrl + Maj + F ouvre la fenêtre de recherche de handle ou de DLL : taper le nom du fichier verrouillé indique immédiatement quel processus le détient, avec la possibilité de fermer directement ce handle ou de forcer la fermeture du processus avant de retenter la suppression.
Pour les utilisateurs qui veulent éviter la ligne de commande, Microsoft propose une solution plus accessible directement dans PowerToys, sa boîte à outils gratuite : la fonction File Locksmith. Un simple clic droit sur le fichier récalcitrant, puis "Déverrouiller avec File Locksmith", affiche immédiatement la liste des processus qui le détiennent, avec la possibilité de les fermer depuis la même fenêtre, sans jamais toucher à une ligne de commande.
Enfin, Russinovich partage une astuce de contournement simple : si l'on ne peut pas immédiatement fermer le processus responsable, il suffit de renommer le fichier plutôt que de tenter de le supprimer. Windows autorise en effet le renommage d'un fichier même lorsqu'il est ouvert dans certains contextes. Il suffit ensuite de déposer une nouvelle copie du fichier portant le nom original au même emplacement – tout processus qui en a besoin utilisera automatiquement cette nouvelle version. L'ancienne copie renommée peut alors être supprimée une fois que le processus qui la détenait finit par libérer son handle.
Cette explication tardive illustre une réalité plus large sur l'architecture de Windows : le système d'exploitation repose encore largement sur Win32, une couche logicielle datant du début des années 1990, devenue selon les mots de Russinovich une véritable fondation sur laquelle reposent d'innombrables technologies et écosystèmes. Un bug vieux de plusieurs décennies, enfin documenté par celui-là même qui en a fait l'expérience il y a trente ans – et qui continue, encore aujourd'hui, à concevoir les outils nécessaires pour le contourner.