MSB3021 is back (file locked by other process), with added weirdness!

I remember seeing this issue years ago. I think there were two separate cases where it somehow crept up, one around the scenario of configuring several projects in VS to build into the same output directory, the other to do with the “Visual Studio hosting process”. Maybe I’m wrong about the second. Anyway.

Now I’m seeing this issue with some regularity in VS 2010 RTM. There doesn’t seem to be a common denominator to the projects that bring this up – I’ve seen it in large-ish Windows Forms apps as well as in several different small demo projects from my presentations (which are usually command line programs).

What happens is quite odd. Usually I’m in full flow, running the app, seeing something odd, exiting and correcting the problem in code, hitting Ctrl-F5 and boom! VS claims it can’t copy the output exe file to its target location because it is locked by another application. Not true, quite obviously, since there is really no other application on my system interested in the file.

There doesn’t seem to be a reliable workaround at this point – usually I try to rebuild the program a few times, and after a little while (usually exactly a second after I’ve hit Shift-Ctrl-B eight times and I’m now off looking for Process Explorer in the hope of finding the offending locker) it suddenly works just fine. Very odd.

Even weirder is that when I actually manage to run Process Explorer in time, its handle search feature doesn’t even find the file in use at all! How is that even possible?

While I’m writing this, I had one idea. I have started using TrueCrypt to store lots of stuff in encrypted virtual drives. I’ve used it for a good long while now and I haven’t really had any problems with it at all, but maybe it’s something to check out. Not sure how that checking out is going to work, but check out I will. I’ll keep you posted. But if you have any ideas, please let me know.

7 Comments on MSB3021 is back (file locked by other process), with added weirdness!

  1. Martin Hart // May 8, 2010 at 7:29 am // Reply

    Oliver, you are not alone.

    I have also seen this using VS2010 RTM, it seems to be quite random and un-reproduceable.

    I don’t use TrueCrypt so I think you can rule his out.


  2. Carsten König // May 10, 2010 at 5:53 am // Reply


    I know this problem too.
    Usually I run into this issue when I’m using the “stop debuging” command instead of closing the app in more “normal” terms.
    BUT: I only saw this problem when I was using some kind of Threading.
    It will happen a lot with “non-background” threads but I think I had one or two problems with thread-pool programming as well. I allways thought that the problem was with a single thread not wanting to die … the bugger 😉

    From time to time I do find the causing ***.vshost process in the task-manager (or whatever you are using) and killing those will solve the problem.

    But it happened a lot that I had to close VS and restart it (I never tried Build-All 8 times in a row – I normaly got bored after only 2-3 times 😉 )

    It happend a lot with VS2008 but I didn’t see it in VS2010 yet but I guess it’s still in there.


  3. Great, thanks for letting me know!


  4. I have this problem too (vshost is disabled). It seems like it’s the CLR that has decided not to exit your app. The process explorer showes that “system” is the culprit holding the file open, nothing to do with VS 2010, then? I’ve tried so many things but still no fix. Mostly I’ve tried all kinds of rude exiting in my app, but still the CLR holds on. It’s as if there’s a GC bug where a (IDisposable?) object is still being considered referenced, so the runtime hangs on…


  5. In any case, a workaround (finally!) is to install the program ‘unlocker’ by Cedrick Collomb, and add the following command to the pre-build event command line:

    “c:program filesunlockerunlocker” $(TargetPath) /S


  6. An answer to this problem was provided in the following question on Stack Overflow:

    I tested the sample project linked by Ivan in an above post (, and I found that the answer on Stack Overflow worked there as well.

    If you follow the above link to the bug report, I also posted the exact steps to fix this as a workaround.


Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s