Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

  1. With explorer, navigate to a directory containing at least one exe file
  2. Go one directory up immediately
  3. Delete the directory just navigated to
  4. 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
  5. 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

  1. Build a project producing an exe file
  2. run the executable then close it
  3. Immediately build the project again (by changing a single character in a source file for example)
  4. 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.

share|improve this question
A few questions. Does the explorer issue occur in safe mode? Do you have any shell extensions installed? With your Visual studio issue, if you run process monitor and filter down to your exe does it show anything accessing the file? – sgmoore Nov 26 '11 at 16:34
Weird, both scenarios you suggest work as expected for me (no errors). Like sgmoore suggests, bust out Process Monitor and monitor the folders/files. – Ƭᴇcʜιᴇ007 Nov 26 '11 at 17:17
@sgmoore see update – stijn Nov 27 '11 at 11:15
Are you 100% sure that just because the calls originate from shell32.dll that this rules out 3rd party installs? I don't know enough about what goes on at an extremely low level to be sure whether that is true or not, but it is certainly not an assumption that I would have made. – sgmoore Nov 28 '11 at 10:04
@sgmoore 100% no, but 99%, yes. My conclusion is not just based on what I wrote here; I have the symbols for all system dlls so I see full function names in procmon's callstack. All calls made by explorer when opening the directory come from classes with names like CLoadIconTask, names which have written 'Microsoft' all over it. I'm a programmer so I have some knowledge on interpreting callstacks. Everything non-microsoft is still disabled in AutoRuns. On another machine it's not, yet the entire procmon output is the same. All these + intuition make me strongly believe it's MS only. – stijn Nov 28 '11 at 11:01
up vote 7 down vote accepted

I think the issue you are seeing is related to the thumbs.db that Windows explorer creates. Try to disable this, reboot and see if the problem reproduces.

To disable thumbs.db open Group Policy editor (gpedit.msc), go to User Configuration -Control Panel > Administrative Templates-Folder Options > Windows Components-Viev tab > Windows Explorer. find the "Turn off the caching of thumbnails in hidden thumbs.db files" and enable itDo Not Cache Thumbnails.

If it does't work I would try investigating it using Sysinternals Process Monitor. use it to watch who is accessing the folder when you get an access denied. see if it is actually an access denied or a sharing violation which means someone is holding the file.

share|improve this answer
Thumbs.db does not exist in win7. – kinokijuf Nov 26 '11 at 17:59
yes it does. go to Folder Options and enable "show hidden files, folder and drives" – Asher Nov 26 '11 at 18:04
Windows 7 uses the local thumbnail cache (%userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), unless the resource is remote (like on a network share) at which point it will use a thumbs.db stored in the remote location (this can be disabled by GP). – Ƭᴇcʜιᴇ007 Nov 26 '11 at 20:26
upvoted: although I do not have a Do Not Cache Thumbnails option, using ProcMon finally got me somewhere, as it provides evidence of the problem, unlike ProcessExplorer or handle: exactly 1 minute after opening the directory or running the exe, there is an IRP_MJ_CLEANUP operation from the System process which seems to release the file: right after that event I can delete the directory again. I'll investiagate this further, if I can make sense from what ProcMon provides. – stijn Nov 27 '11 at 17:07
@kinokijuf I just noticed you've been messing with Ahser's answer. I have no idea why you are doing it, but it does not make sense: first you say, in bold, that there is no thumbs.db. Then you edit Asher's answer so the part where he says how to disable thums.db, making it unusable ("Do Not Cache Thumnbnails" is for XP). Please don't do such things. – stijn Nov 28 '11 at 11:19

Are you sure that you do not have any security product installed of any kind ?

The scenarios you describe are compatible with the theory that some product is accessing every executable file that is accessed by you in any possible way, making exclusive access to it impossible. This does not have to be an antivirus, it could be for example be an indexer for fast search or whatever (even a virus).

One can test this theory by booting in Safe mode where no products except for Windows are launched at all.

The best tool for tracing file accesses is Process Monitor. Another excellent tool for finding all startup products and turning them off and on again is Autoruns.

share|improve this answer
indexing is of, windows search is off as well. I have no 3rd party security or search tools of any kind; basically your suggestion is disable any 3rd party tools in autoruns, then enable one by one? – stijn Nov 27 '11 at 11:16
If this is not happening in Safe mode boot, then it is absolutely sure that some installed product is responsible. You could use Autoruns to disable startup items in batches and reboot, until you find it. The advantage of Autoruns is that you can easily re-enable items, as well as save/restore/compare the current situation. But still better create first a system restore point, just in case. – harrymc Nov 27 '11 at 12:17
disabled everything non-microsoft under Logon, Explorer, Internet Explorer and services. Problem still exists. Is there a way to compare what's loaded in normal mode vs in safe mode? – stijn Nov 27 '11 at 12:56
Basically, everything you see in Autoruns is loaded only in normal mode. – harrymc Nov 27 '11 at 13:03
Well, except for Services, Network etc. – harrymc Dec 1 '11 at 11:56

File or directory can be opened from kernel mode, then

handle -a

won't show it and ProcMon will show IRP requests from/to System process.

There's a part of Windows Kernel which is mapped to all processes and there's another part of Windows Kernel which runs in separate process. The latter is called Windows Executive.

So this caused by file or directory opened from kernel mode in Windows Executive process.

share|improve this answer

It may be Explorer reading icons and metadata from the exe.

share|improve this answer
This is a possible explanation for Explorer, but not for visual studio unless Explorer is displaying this folder at the same time. @stijn: Does this happen in visual studio without Explorer? – harrymc Nov 26 '11 at 20:45
@harrymc see update, does happen without explorer (well, explorer.exe is still running, but is not on the directory of the exe) – stijn Nov 27 '11 at 11:17
And how does one fix this issue? – Simon Sheehan Nov 27 '11 at 16:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.