LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'

Using Visual Studio 2010, when I build + run my application in short intervals I often get the following error. If I just wait a minute or two and try again it works fine. Unlocker claims no handle is locking the executable file.
How can I discover what's locking it?
If it's Visual Studio itself, what should I do to make it stop? or alternatively to release the file?

1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1>  Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1>  All outputs are up-to-date.
1>  SomeFile1.cpp
1>ResourceCompile:
1>  All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Had this issue after a reinstall today. Make sure the Application Experience service is started and not set to disabled. If its set to manual, I believe VS will start it.

I'm aware this is quite old but I just had the same problem with Visual Studio 2010 all patched up so others may still run into this.

Adding my project path to "Exluded Items" in my AVG anti-virus settings appears to have fixed the problem for me.

Try disabling any anti-virus/resident shield and see if it fixes the problem. If so, add your project path to excluded directories in your AV config.

You probably had a stray build process that was locking the executable, and it (the stray process) didn't get cleaned up. In that case, shut down visual studio, open up process explorer, and nuke every process you can find that is related to visual studio. Then open up visual studio again and try rebuilding your project.

the file can be locked because it is being run now. Try killing the process with a task manager.

Like Jonathan said, yes, renaming can help to work around this problem. But ,e.g. I was forced to rename target executable many times, it's some tedious and not good.

The problem lies there that when you run your project and later get an error that you can't build your project - it's so because this executable (your project) is still runnning (you can check it via task manager.) If you just rename target build, some time later you will get the same error with new name too and if you open a task manager, you will see that you rubbish system with your not finished projects.

Visual studio for making a new build need to remove previous executable and create new instead of old, it can't do it while executable is still runinng. So, if you want to make a new build, process of old executable has to be closed! (it's strange that visual studio doesn't close it by itself and yes, it looks like some buggy behaviour).

It's some tedious to do it manually, so you may just a bat file and just click it when you have such problem:

taskkill /f /im name_of_target_executable.exe

it works for me at least. Like a guess - I don't close my program properly in C++, so may be it's normal for visual studio to hold it running.

ADDITION: There is a great chance to be so , because of not finished application. Check whether you called PostQuitMessage in the end, in order to give know Windows that you are done.

You might have not closed the the output. Close the output, clean and rebuild the file. You might be able to run the file now.

I've concluded this is some kind of Visual Studio bug. Perhaps C Johnson is right - perhaps the build process keeps the file locked.

I do have a workaround which works - each time this happens - I change the Target Name of the executable under the Project's properties (right click the project, then Properties\Configuration Properties\General\Target Name).

In this fashion VS creates a new executable and the problem is worked around. Every few times I do this I return to the original name, thus cycling through ~3 names.

If someone will find the reason for this and a solution, please do answer and I may move the answer to yours, as mine is a workaround.

I had the same problem, however using Codeblocks. Because of this problem i quited programming because everytime i just wanted to throw my computer out of the window.

I want to thank user963228 whos answer is really a solution to that. You have to put Application Experience on Manual startup(you can do it by searching services in windows 7 start menu, and then find Application Experience and click properties).

This problem happens when people want to tweak theyr windows 7 machine, and they decide to disable some pointless services, so they google some tweaking guide and most of those guides say that Application Experience is safe to disable.

I think this problem should be linked to windows 7 problem not VS problem and it should be more visible - it took me long time to find this solution.

Thanks again!

Just to add another solution to the list, what I've found is that Visual Studio (2012 in my case) occasionally locks files under different processes.

So, on a crash, devenv.exe might still be running and holding onto the file(s). Alternatively (as I just discovered), vstestrunner or vstestdiscovery might be holding onto the file as well.

Kill all those processes and it might fix up the issue.

I have just run into the same issue with VS2013, creating device drivers in C++ , and none of the above seemed to fix the issue. However, I have just discovered that in my case the issue appears to have been VMWare-related.

I was running a VMWare workstation client with a shared folder defined on the VM on my entire C: drive. When I disabled the shared folders on the VM Settings, VS2013 was able to happily build my .exe files.

My new process is:

1. Disable the shared folder on the vm (VM Settings | Options | Shared Folders - and uncheck the checkbox)
2. Run the build on the host PC
3. RE-enable the shared folder (and proceed from there)

Hopefully this might help someone else.

(BTW, the errors you receive are that the .exe (or other files) are locked or require Administrator permission, but that is a red herring - It seems to me that the VMWare share is causing those files to appear as locked.)

Usually, this means that your program is locked and might not be killed through task manager or process explorer. I met a similar case that my program had an exception during running and triggered the windows error reporting which locked the program. For the case that windows error reporting locks the program, you can go to control panel->System and Security->Action Center->Problem Reporting Settings to set "Never check for solutions". Hope it helps.

For me it was happening, when I was trying to build in debug mode, but it was working fine in release mode. I changed the build configuration in the visual studio from x86 to x64 and it worked fine for me, as I was running on 64 bit system.

I just had this issue in VS22 - I think I closed the debugger right when it was compiling. All I had to do was restart my computer.

The error comes (at least sometimes) from paths that are too long. In my project simply reducing the output file path does the job: "Properties/Configuration Properties/General/Intermediate Directory"

Seems that I have hit the 250 character path limitation.

Working with Bjarne Stroustrup Programming Principles and Practice Using C++ "FLTK" example i got the same error but after like 1 hour i got an idea, i tracked one of the libs already seen in Project Properties -> Linker -> Input -> Additional Dependencies, in my case i tracked the kernel32.lib to see where was located and saw there were many kernel32.lib's in different folders. So i started copy the FLTK libs in those folders and the last one i tried worked. Visual Studio 2013 Express found the fltkd.lib and the code worked.

In my case the correct route was C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86

I don't know how to set that route inside Visual Studio.

Not sure if that Windows kits folder was created when i installed Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO) http://www.microsoft.com/en-us/download/details.aspx?id=8442

Hope that helps you people.

I just had thesame problem. With me the exe was still running but I could not end it with the Task Manager. Just by restarting VS, it worked for me.

Mine is that if you set MASM listing file option some extra selection, it will give you this error.

Just use

 Enable Assembler Generated Code Listing   Yes/Sg
 Assembled Code Listing $(ProjectName).lst

it is fine.

But any extra you have issue.