Ever since I started using Windows 7 this problem has been bothering me. From time to time I see similar questions popping up on misc forums, but never did I see an answer. Here are two scenarios that nearly always reproduce it:
The explorer way
- With explorer, navigate to a directory containing at least one exe file
- Go one directory up immediately
- Delete the directory just navigated to
- Yields Folder Access Denied dialog stating You need permission to perform this action You require permission from Administrators to make changes to this folder, with the buttons try Again and Cancel
- Hitting Try Again never works immediately. Waiting a minute or so and then clicking it again does work
Note: If in step 2 and waiting a minute or more before going up one directory, the problem does not occur and the folder can be deleted
The Visual Studio way
- Build a project producing an exe file
- run the executable then close it
- Immediately build the project again (by changing a single character in a source file for example)
- Yields fatal error LNK1168: cannot open /path/to/the.exe for writing
Note: If in step 2 and waiting a minute or more before building again, the problem does not occur.
Some specs
- Happens both on Windows 7 32 and 64 bit, with VS2008/2010/2011
- Happens on 3 different machines
- I do not have a virus scanner of any kind
- I do have a bunch of services disabled, but nothing that prevents Windows from running normally, UAC is disabled as well
- Happens on any type of disc
- I always use a user account that is in the Administrators group
Obviously both scenarios are very similar and extremely reproducible. So I figured some process must have the file open for some reason, and release it again later. However, using sysinternals
handle -a
the exe file in question never shows up. (that is the correct way to use handle, right?) So while explorer/VS are reporting they cannot access the file, handle.exe says it's not in use anywhere. This leaves me rather clueless, so I'm wondering if someone can come up with a solution: why does this happen, and how to solve it?
Update in response to the questions asked:
- I could not reproduce the problem in Safe Mode
- A bunch of shell extensions are installed. From SellExView, here are the non-microsoft ones that are common to all machines: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. I would find the Tortoise ones most suspicious, though for both the 'Status Cache' option is set to 'Status cache only for one folder, no recursive overlays' i.e. there is no TortoiseCache.exe running.
- With the explorer problem, ProcessExplorer does not show the executable. It does show the directory of the executable though, but keeps on showing it even after it was deleted so that seems not really related
- With the VS problem, it does happen with VS even when no explorer window is open on the target directory. And again, ProcessExplorer does not show the executable, nor the directory the executable is in. Note that in this 'mode' with VS, the problem only occurs when running the executable. If not running it, I can build it without problems time after time.
- In 'VS mode' and an explorer window open on the executable's directory (tested with a C# exe only), it gets weirder: I cannot build again because VS complains the exe is being used by another process. However, if I delete the exe from the open explorer window, this works, and consequently building succeeds. Again, no references in ProcessExplorer whatsoever. Which seems to match my findings with handle.exe (don't PE and handle use the same API internally anyway?)
Update 2 It cannot be just explorer: after killing explorer.exe, the VS problem is still there.
Update 3 Using Process Monitor as Asher suggests reveals interesting facts: for the explorer mode, there are 10 calls to IRP_MJ_CREATE upon opening the directory. However only 9 calls to IRP_MJ_CLEANUP. All this calls originate from within shell32.dll, so it is definitely not a 3rd party install problem. And it is obviously the one missing IRP_MJ_CLEANUP that causes the problem: exactly 1 minute after opening the directory, the System process itself issues the IRP_MJ_CLEANUP call and the file is released, and an be deleted.
However, I still couldn't figure out why this happens. Is it an explorer bug triggered by some change I made?
Solution! Looking through the services I have disabled, I noticed the description for Application Experience says, and I quote, Processes application compatibility cache requests for applications as they are launched. Sounds familiar. And indeed, after starting the service I cannot reproduce any of the problems anymore and the output of ProcMon is different and shorter. Funny though, because after stopping the service again, everything is still fine and the output of procmon is still shorter.
I tried this on two machines, with all 3rd party stuff happily running and all is still fine.
I'm not sure if this is a real bug (one could say 'what do you expect with disabling services'), but it's not exactly normal that the problem goes away simply by starting a service and then stopping it again.
Bounty goes to anyone who can provide a deeper insight in this, else to @Asher for pointing me to ProcMon which eventually led me in the right direction.
