Comment trouvez-vous quel processus maintient un fichier ouvert dans Windows?
Une chose qui m'ennuie sans fin à propos de Windows est l'ancienne erreur violation de partage. Souvent, vous ne pouvez pas identifier ce qui le maintient ouvert. Habituellement, ce n'est qu'un éditeur ou un explorateur pointant simplement vers un répertoire pertinent, mais parfois j'ai dû recourir au redémarrage de ma machine.
Des suggestions sur la façon de trouver le coupable?
J'ai eu du succès avec SysinternalsProcess Explorer . Avec cela, vous pouvez rechercher quel (s) processus ont un fichier ouvert, et vous pouvez l'utiliser pour fermer le (s) handle (s) si vous le souhaitez. Bien sûr, il est plus sûr de clore l'ensemble du processus. Faites preuve de prudence et de jugement.
Pour rechercher un fichier spécifique, utilisez l'option de menu Find->Find Handle or DLL... Tapez une partie du chemin d'accès au fichier. La liste des processus apparaîtra ci-dessous.
Si vous préférez la ligne de commande, Sysinternals Suite inclut l'outil de ligne de commande Handle , qui répertorie les poignées ouvertes. Quelques exemples d'utilisation:
c:\Program Files\SysinternalsSuite>handle.exe |findstr /i e:\- recherchez tous les fichiers ouverts à partir du lecteur E:c:\Program Files\SysinternalsSuite>handle.exe |findstr /i file-or-path-in-question
Vous pouvez utiliser le Moniteur de ressources pour cela qui vient intégré avec Windows 7, 8 et 10.
- Ouvrez le moniteur de ressources , qui se trouve
- En recherchant Resource Monitor ou resmon.exe dans le menu Démarrer, ou
- En tant que bouton sur l'onglet Performance de votre Gestionnaire des tâches
- Accédez à l'onglet [~ # ~] cpu [~ # ~]
- Utilisez le champ de recherche dans la section Poignées associées
- Voir la flèche bleue dans la capture d'écran ci-dessous
Lorsque vous avez trouvé la poignée, vous pouvez identifier le processus en consultant la colonne Image et/ou PID.
Vous pouvez ensuite essayer de fermer l'application comme vous le feriez normalement, ou, si ce n'est pas possible, faites simplement un clic droit sur la poignée et tuez le processus directement à partir de là. Peasy facile!
Copié de ma réponse d'origine: https://superuser.com/a/643312/62
Essayez la commande openfiles .
Soyez très prudent avec la fermeture des poignées; c'est encore plus dangereux que vous ne le pensez, à cause du recyclage de la poignée - si vous fermez la poignée de fichier et que le programme ouvre autre chose, cette poignée de fichier d'origine que vous avez fermée peut être réutilisée pour cette "autre chose". Et devinez maintenant ce qui se passe si le programme continue, pensant qu'il fonctionne sur le fichier (dont vous avez fermé le handle), alors qu'en fait, ce handle de fichier pointe maintenant vers autre chose.
voir article de Raymond Chen sur ce sujet
Supposons qu'un service d'index de recherche ait un fichier ouvert pour l'indexation mais qu'il se soit bloqué temporairement et que vous souhaitiez supprimer le fichier, vous forcez donc (imprudemment) la fermeture de la poignée. Le service d'index de recherche ouvre son fichier journal afin d'enregistrer certaines informations et le descripteur du fichier supprimé est recyclé en tant que descripteur du fichier journal. L'opération bloquée se termine enfin et le service d'index de recherche parvient enfin à fermer le handle qu'il avait ouvert, mais il finit par fermer involontairement le handle de fichier journal.
Le service d'index de recherche ouvre un autre fichier, par exemple un fichier de configuration pour l'écriture afin qu'il puisse mettre à jour un état persistant. Le handle du fichier journal est recyclé en tant que handle du fichier de configuration. Le service d'index de recherche souhaite enregistrer certaines informations, il écrit donc dans son fichier journal. Malheureusement, le descripteur du fichier journal a été fermé et le descripteur a été réutilisé pour son fichier de configuration. Les informations enregistrées vont dans le fichier de configuration, le corrompant.
Pendant ce temps, une autre poignée que vous avez forcée à fermer a été réutilisée comme poignée mutex, qui est utilisée pour empêcher la corruption des données. Lorsque le descripteur de fichier d'origine est fermé, le descripteur mutex est fermé et les protections contre la corruption de données sont perdues. Plus le service s'exécute, plus ses index sont corrompus. Finalement, quelqu'un remarque que l'index renvoie des résultats incorrects. Et lorsque vous essayez de redémarrer le service, il échoue car ses fichiers de configuration ont été corrompus.
Vous signalez le problème à la société qui effectue le service d'index de recherche et ils déterminent que l'index a été corrompu, le fichier journal a mystérieusement arrêté la journalisation et le fichier de configuration a été remplacé par des ordures. Un pauvre technicien se voit confier la tâche désespérée de comprendre pourquoi le service corrompt ses index et fichiers de configuration, sans savoir que la source de la corruption est que vous avez forcé la fermeture d'un handle.
J'ai utilisé Handle avec succès pour trouver de tels processus dans le passé.
Lockhunter ( http://lockhunter.com/ ) fonctionne sur les systèmes 32 et 64 bits.
Juste pour clarifier, cela est plus susceptible d'être le résultat d'un mauvais comportement des applications tierces n'utilisant pas correctement l'appel API CreateFile que ce ne soit quoi que ce soit dans Windows lui-même. C'est peut-être une conséquence de la conception de CreateFile, mais c'est fait et nous ne pouvons pas revenir en arrière.
Fondamentalement, lors de l'ouverture d'un fichier dans un programme Windows, vous avez la possibilité de spécifier un indicateur qui autorise l'accès partagé. Si vous ne spécifiez pas l'indicateur, le programme a un accès exclusif au fichier.
Maintenant, si Explorer semble être le coupable ici, il se peut que ce soit juste à la surface, et que le vrai coupable soit quelque chose qui installe une extension Shell qui ouvre tous les fichiers dans un dossier à ses propres fins, mais qui l'est aussi gung-ho en faisant cela, ou qui ne nettoie pas correctement après lui-même. Symantec AV est quelque chose que j'ai vu faire cela auparavant, et je ne serais pas surpris si d'autres programmes AV étaient également à blâmer. Les plug-ins de contrôle de source peuvent également être en cause.
Donc pas vraiment une réponse, mais juste quelques conseils pour ne pas toujours blâmer Windows pour ce qui peut être un programme tiers mal écrit (quelque chose qui peut aussi arriver sur n'importe quel autre OS qui a un verrouillage de fichier implicite, mais tout OS basé sur Unix a un accès partagé par défaut).
Who Lock Me fonctionne bien et garde les gens amusés avec le nom!
Apropos Explorer tenant un fichier ouvert: "Lorsque cela se produit sur un fichier que vous devez supprimer, vous avez le choix de forcer la fermeture de la poignée ou de redémarrer."
Vous pouvez simplement terminer Explorer.
Si c'est une chose unique (l'explorateur ne tient pas normalement ce fichier ouvert), je suppose que la déconnexion et la reconnexion feront l'affaire.
Sinon, tuez le processus de l'Explorateur de bureau et faites ce que vous voulez pendant qu'il est parti. Commencez d'abord une copie de cmd.exe (vous avez besoin d'une interface utilisateur pour effectuer le nettoyage prévu). Assurez-vous qu'aucun explorateur autre que le bureau n'est en cours d'exécution. Tuez ensuite le dernier explorateur avec, par exemple, le Gestionnaire des tâches. Faites ce que vous voulez dans l'invite de commande. Enfin, exécutez l'Explorateur à partir de l'invite de commandes et il deviendra le bureau.
Je suppose qu'il peut y avoir un certain désagrément résiduel si certains programmes systray ne peuvent pas gérer le redémarrage du shell.
Sur un serveur distant, lorsque vous vérifiez un partage réseau, quelque chose d'aussi simple que la console de gestion de l'ordinateur peut afficher ces informations et fermer le fichier.
Les fichiers peuvent être verrouillés par des processus locaux ( nlocker est l'outil à utiliser) et par l'accès aux fichiers qui passe par des partages.
Il y a une fonction intégrée dans Windows qui vous montre quels fichiers sur l'ordinateur local sont ouverts/verrouillés par un ordinateur distant (qui a le fichier ouvert via un partage de fichiers):
* Select "Manage Computer" (Open "Computer Management")
* click "Shared Folders"
* choose "Open Files"
Là, vous pouvez même fermer le fichier avec force.
Avec Process Hacker vous pouvez identifier facilement quels processus contiennent vos fichiers:
Il y a aussi NirSoft Affichage des fichiers ouverts .
Les réponses votées ci-dessus couvrent des situations où un processus de programme maintient le descripteur de fichier ouvert, ce qui (heureusement) est la plupart du temps - cependant dans certains cas (comme cela se produit actuellement sur ce système), le système lui-même contient un descripteur de fichier ouvert.
Vous pouvez identifier cette situation en suivant les instructions pour trouver le processus de conservation de descripteur de fichier avec Process Explorer ci-dessus, et en notant que le nom du processus est répertorié comme "système", ou en suivant les instructions à l'aide du moniteur de ressources et en notant qu'aucune image n'est affichée avoir un descripteur de fichier ouvert sur votre fichier d'intérêt (bien que, de toute évidence, quelque chose fait que vous ne pouvez pas modifier/supprimer le fichier, etc.).
Si cela se produit, votre option (pour autant que je sache) est de redémarrer - ou d'oublier de faire quoi que ce soit avec ce fichier.
Il existe un outil FILEMON et affiche les fichiers ouverts et les poignées. Il est difficile de suivre son affichage si vous le regardez en direct, il le fait rapidement. Mais vous pouvez l'empêcher d'afficher en direct et vous pouvez regarder toutes les activités d'ouverture/d'écriture de fichiers. Maintenant détenue par Microsoft mais à l'origine par Sysinternals
Je me suis tourné vers Exteneded Task Manager il y a quelque temps par le blog de Jeremy Zawodny, et c'est génial pour retrouver plus d'informations sur les processus. +1 pour Process Explorer comme ci-dessus également, en particulier pour tuer les processus que le gestionnaire de tâches standard ne terminera pas.