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.
la source
Réponses:
Je pense que le problème que vous voyez est lié à thumbs.db créé par l'explorateur Windows. Essayez de désactiver cela, redémarrez et voyez si le problème se reproduit.
Pour désactiver thumbs.db, ouvrez l'éditeur de stratégie de groupe (gpedit.msc), accédez à Configuration utilisateur - Panneau de configuration> Modèles d'administration - Options des dossiers> onglet Composants Windows-Viev> Explorateur Windows. recherchez l'option "Désactiver la mise en cache des vignettes dans les fichiers thumbs.db cachés" et activez-la Ne pas mettre en cache les vignettes.
Si cela ne fonctionne pas, j'essaierais d'enquêter à l'aide de Sysinternals Process Monitor. utilisez-le pour voir qui accède au dossier lorsque vous obtenez un accès refusé. voir s'il s'agit en fait d'un accès refusé ou d'une violation de partage, ce qui signifie que quelqu'un détient le fichier.
la source
%userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), sauf si la ressource est distante (comme sur un partage réseau), auquel cas elle utilisera une mémoirethumbs.dbstockée dans l'emplacement distant (cela peut être désactivé par le GP).Êtes-vous sûr de ne disposer d'aucun produit de sécurité installé?
Les scénarios que vous décrivez sont compatibles avec la théorie selon laquelle certains produits accèdent à tous les fichiers exécutables auxquels vous accédez de quelque manière que ce soit, ce qui rend leur accès exclusif impossible. Il n'est pas nécessaire que ce soit un antivirus, il peut s'agir par exemple d'un indexeur pour une recherche rapide ou autre (même un virus).
On peut tester cette théorie en démarrant en mode sans échec où aucun produit à l'exception de Windows n'est lancé du tout.
Le meilleur outil pour suivre les accès aux fichiers est Process Monitor . Autoruns est un autre excellent outil pour trouver tous les produits de démarrage et les désactiver puis les réactiver .
la source
Le fichier ou le répertoire peut être ouvert en mode noyau, puis
ne l'affichera pas et ProcMon affichera les demandes IRP de / vers le processus système.
Il existe une partie du noyau Windows qui est mappée à tous les processus et une autre partie du noyau Windows qui s'exécute dans un processus distinct. Ce dernier s'appelle Windows Executive.
Cela est donc dû au fichier ou au répertoire ouvert depuis le mode noyau dans le processus Windows Executive.
la source
Il peut s'agir d'Explorer lisant des icônes et des métadonnées de l'exe.
la source