Depuis que j'ai commencé à utiliser Windows 7, ce problème me dérange. De temps en temps, je vois des questions similaires surgir sur divers forums, mais je n'ai jamais vu de réponse. Voici deux scénarios qui le reproduisent presque toujours:
La voie de l'explorateur
- Avec l'explorateur, accédez à un répertoire contenant au moins un fichier exe
- Montez un répertoire immédiatement
- Supprimer le répertoire que vous venez de parcourir
- Les rendements du dossier Accès refusé indiquant dialogue Vous devez avoir l' autorisation d'effectuer cette action Vous avez besoin d'une autorisation d'administrateurs pour apporter des modifications à ce dossier , avec les boutons d' essayer à nouveau et Annuler
- Frapper Try Again ne fonctionne jamais immédiatement. Attendre une minute environ, puis cliquer à nouveau fonctionne
Remarque: si à l'étape 2 et que vous attendez une minute ou plus avant de remonter dans un répertoire, le problème ne se produit pas et le dossier peut être supprimé
La manière Visual Studio
- Construire un projet produisant un fichier exe
- exécutez l'exécutable puis fermez-le
- Reconstruisez immédiatement le projet (en changeant un seul caractère dans un fichier source par exemple)
- Donne LNK1168 d'erreur fatale: ne peut pas ouvrir /path/to/the.exe pour l' écriture
Remarque: Si à l'étape 2 et que vous attendez une minute ou plus avant de reconstruire, le problème ne se produit pas.
Quelques spécifications
- Se produit à la fois sur Windows 7 32 et 64 bits, avec VS2008 / 2010/2011
- Se produit sur 3 machines différentes
- Je n'ai aucun antivirus d'aucune sorte
- J'ai un tas de services désactivés, mais rien n'empêche Windows de fonctionner normalement, l'UAC est également désactivé
- Se produit sur tout type de disque
- J'utilise toujours un compte d'utilisateur qui se trouve dans le groupe Administrateurs
Évidemment, les deux scénarios sont très similaires et extrêmement reproductibles. J'ai donc pensé qu'un processus devait ouvrir le fichier pour une raison quelconque, et le relâcher plus tard. Cependant, en utilisant sysinternals
handle -a
le fichier exe en question ne s'affiche jamais . (c'est la bonne façon d'utiliser handle, non?) Donc, alors que l'explorateur / VS signale qu'ils ne peuvent pas accéder au fichier, handle.exe dit qu'il n'est utilisé nulle part. Cela me laisse un peu ignorant, alors je me demande si quelqu'un peut trouver une solution: pourquoi cela se produit-il et comment le résoudre?
Mise à jour en réponse aux questions posées:
- Je n'ai pas pu reproduire le problème en mode sans échec
- Un tas d'extensions de shell sont installées. De SellExView, voici les non-microsoft qui sont communs à toutes les machines: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Je trouverais les tortues les plus suspectes, mais pour les deux, l'option 'Status Cache' est définie sur 'Status Cache uniquement pour un dossier, pas de superpositions récursives', c'est-à-dire qu'il n'y a pas TortoiseCache.exe en cours d'exécution.
- Avec le problème de l'explorateur, ProcessExplorer n'affiche pas l'exécutable. Cependant, il affiche le répertoire de l'exécutable, mais continue de l'afficher même après sa suppression, ce qui ne semble pas vraiment lié
- Avec le problème VS, cela se produit avec VS même lorsqu'aucune fenêtre d'explorateur n'est ouverte sur le répertoire cible. Et encore une fois, ProcessExplorer n'affiche pas l'exécutable, ni le répertoire dans lequel l'exécutable se trouve. Notez que dans ce «mode» avec VS, le problème se produit uniquement lors de l'exécution de l'exécutable. Si je ne le lance pas, je peux le construire sans problème à chaque fois.
- En `` mode VS '' et une fenêtre d'explorateur ouverte sur le répertoire de l'exécutable (testé avec un exe C # uniquement), cela devient plus étrange: je ne peux pas reconstruire car VS se plaint que l'exe est utilisé par un autre processus. Cependant, si je supprime l'exe de la fenêtre ouverte de l'explorateur, cela fonctionne et, par conséquent, la construction réussit. Encore une fois, aucune référence dans ProcessExplorer que ce soit. Ce qui semble correspondre à mes résultats avec handle.exe (PE et handle n'utilisent-ils pas la même API de toute façon?)
Mise à jour 2 Il ne peut pas être simplement un explorateur: après avoir tué explorer.exe, le problème VS est toujours là.
La mise à jour 3 L' utilisation de Process Monitor comme Asher le suggère révèle des faits intéressants: pour le mode explorateur, il y a 10 appels à IRP_MJ_CREATE lors de l'ouverture du répertoire. Cependant, seulement 9 appels à IRP_MJ_CLEANUP. Tous ces appels proviennent de shell32.dll, il ne s'agit donc certainement pas d' un problème d'installation tiers. Et c'est évidemment celui qui manque IRP_MJ_CLEANUP qui cause le problème: exactement 1 minute après l'ouverture du répertoire, le processus système lui-même émet l'appel IRP_MJ_CLEANUP et le fichier est libéré et supprimé.
Cependant, je n'arrivais toujours pas à comprendre pourquoi cela se produisait. Est-ce un bug d'explorateur déclenché par une modification que j'ai apportée?
Solution! En parcourant les services que j'ai désactivés, j'ai remarqué que la description d' Application Experience indique, et je cite, Traite les demandes de cache de compatibilité des applications pour les applications lors de leur lancement . Sonne familier. Et en effet, après avoir démarré le service, je ne peux plus reproduire aucun des problèmes et la sortie de ProcMon est différente et plus courte. C'est drôle, car après avoir à nouveau arrêté le service, tout va bien et la sortie de procmon est encore plus courte.
J'ai essayé cela sur deux machines, avec tous les trucs de tiers fonctionnant avec bonheur et tout va toujours bien.
Je ne suis pas sûr que ce soit un vrai bug (on pourrait dire `` qu'attendez-vous avec la désactivation des services ''), mais il n'est pas tout à fait normal que le problème disparaisse simplement en démarrant un service puis en l'arrêtant à nouveau.
Bounty s'adresse à tous ceux qui peuvent fournir un aperçu plus approfondi à ce sujet, à @Asher pour m'avoir dirigé vers ProcMon qui m'a finalement conduit dans la bonne direction.