链接：致命错误 LNK1104：无法打开文件 'D:\...\MyProj.exe'
使用 Visual Studio 2010，当我在短时间内构建+运行我的应用程序时，经常会收到以下错误。如果我等一两分钟再试一次就可以了。 Unlocker 声称没有句柄锁定可执行文件。
我怎样才能发现是什么锁定了它？< br> 如果是 Visual Studio 本身，我该怎么做才能让它停止？或者释放文件？
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 ==========
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 ==========
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
您可能有一个锁定可执行文件的杂散构建进程，并且它（杂散进程）没有被清理。在这种情况下，请关闭 Visual Studio，打开进程资源管理器，然后删除您能找到的与 Visual Studio 相关的每个进程。
然后再次打开 Visual Studio 并尝试重建您的项目。
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.
正如乔纳森所说，是的，重命名可以帮助解决这个问题。但是，例如我被迫多次重命名目标可执行文件，这有些乏味而且不好。
问题在于，当您运行项目并稍后收到无法构建项目的错误时 - 之所以如此，是因为此可执行文件（您的项目）仍在运行（您可以通过任务管理器检查它。）
如果您只是重命名目标构建，一段时间后您也会收到新名称相同的错误，如果您打开任务管理器，您将看到未完成的项目垃圾系统。
Visual Studio 进行新构建需要删除以前的可执行文件并创建新的而不是旧的，当可执行文件仍在运行时它无法执行此操作。因此，如果您想进行新的构建，则必须关闭旧可执行文件的进程！ （很奇怪，视觉工作室不会自行关闭它，是的，它看起来像是一些错误的行为）。
手动执行此操作有些繁琐，因此您可能只是一个bat文件，然后单击它这样的问题：
它至少对我有用。
就像猜测一样 - 我没有在 C++ 中正确关闭我的程序，所以 Visual Studio 保持它运行可能是正常的。
添加：
由于申请尚未完成，很有可能会出现这种情况。检查你最后是否调用了PostQuitMessage，以便让Windows知道你已经完成了。
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:
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.
该文件可以被锁定，因为它正在运行。尝试使用任务管理器终止该进程。
the file can be locked because it is being run now. Try killing the process with a task manager.
您可能还没有关闭输出。关闭输出，清理并重建文件。您现在也许可以运行该文件。
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.
我得出的结论是这是某种 Visual Studio 错误。也许 C Johnson 是对的 - 也许构建过程会保持文件锁定。
我确实有一个有效的解决方法 - 每次发生这种情况 - 我都会更改项目属性下可执行文件的目标名称（右键单击该项目，然后单击属性\配置属性\常规\目标名称）。
通过这种方式，VS 创建了一个新的可执行文件，问题就解决了。每隔几次，我都会返回到原来的名称，从而循环使用约 3 个名称。
如果有人找到原因和解决方案，请回答，我可能会将答案移至您的答案，因为我的方法是一种解决方法。
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.
我遇到了同样的问题，但是使用了 Codeblocks。由于这个问题，我放弃了编程，因为每次我只想把电脑扔出窗外。
我要感谢用户963228，他的回答确实解决了这个问题。您必须将应用程序体验设置为手动启动（您可以通过在Windows 7开始菜单中搜索服务，然后找到应用程序体验并单击属性来完成此操作）。
当人们想要调整他们的 Windows 7 机器，并且他们决定禁用一些无意义的服务时，就会发生这个问题，因此他们在谷歌上搜索了一些调整指南，大多数指南都说应用程序体验可以安全地禁用。
我认为这个问题应该与 Windows 7 问题而不是 VS 问题相关，并且它应该更明显 - 我花了很长时间才找到这个解决方案。
再次感谢！
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!
只是为了在列表中添加另一个解决方案，我发现 Visual Studio（在我的例子中是 2012）偶尔会锁定不同进程下的文件。
因此，在崩溃时，devenv.exe 可能仍在运行并保留文件。或者（正如我刚刚发现的），vstestrunner 或 vstestdiscovery 也可能保留该文件。
杀死所有这些进程可能会解决问题。
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.
我刚刚在 VS2013 中遇到了同样的问题，用 C++ 创建设备驱动程序，以上似乎都没有解决该问题。然而，我刚刚发现，就我而言，问题似乎与 VMWare 相关。
我正在运行一个 VMWare 工作站客户端，并在整个 C: 驱动器上的 VM 上定义了一个共享文件夹。当我在虚拟机设置中禁用共享文件夹时，VS2013 能够愉快地构建我的 .exe 文件。
我的新流程是：
1）禁用虚拟机上的共享文件夹（虚拟机设置 | 选项 | 共享文件夹 - 并取消选中该复选框）
2) 在主机上运行构建
3）重新启用共享文件夹（并从那里继续）
希望这可以帮助其他人。
（顺便说一句，您收到的错误是 .exe（或其他文件）被锁定或需要管理员权限，但这是转移注意力的 - 在我看来，VMWare 共享导致这些文件显示为锁定。）
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.)
通常，这意味着您的程序已被锁定，并且可能无法通过任务管理器或进程资源管理器杀死。我遇到过类似的情况，我的程序在运行过程中出现异常，触发了Windows错误报告，从而锁定了程序。 对于Windows错误报告锁定程序的情况，您可以进入控制面板->系统和安全->操作中心->问题报告设置设置“从不检查解决方案”。希望有帮助。
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.
对我来说，当我尝试在调试模式下构建时，它就发生了，但它在发布模式下工作正常。我将 Visual Studio 中的构建配置从 x86 更改为 x64，它对我来说工作得很好，因为我在 64 位系统上运行。
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.
我刚刚在 VS22 中遇到了这个问题 - 我想我在编译时关闭了调试器。我所要做的就是重新启动计算机。
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.
该错误（至少有时）来自太长的路径。在我的项目中，只需减少输出文件路径即可完成此工作：
“属性/配置属性/常规/中间目录”
似乎已达到 250 个字符的路径限制。
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.
使用 Bjarne Stroustrup 编程原理和实践使用 C++“FLTK”示例，我遇到了同样的错误，但大约 1 小时后我有了一个想法，我跟踪了项目属性中已经看到的库之一 ->链接器->输入->其他依赖项，就我而言，我跟踪 kernel32.lib 以查看其位置，并发现不同文件夹中有许多 kernel32.lib。所以我开始复制这些文件夹中的 FLTK 库，最后一个尝试成功了。 Visual Studio 2013 Express 找到了 fltkd.lib 并且代码可以运行。
就我而言，正确的路线是 C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
我不知道如何在 Visual Studio 内设置该路线。
不确定在安装适用于 Windows 7 和 .NET Framework 4 (ISO) 的 Microsoft Windows SDK 时是否创建了 Windows 工具包文件夹 http://www.microsoft.com/en-us/download/details.aspx?id=8442
希望对您有所帮助。
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.
我刚刚遇到了同样的问题。对我来说，exe 仍在运行，但我无法使用任务管理器结束它。只需重新启动 VS，它就对我有用了。
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.
我的是，如果你设置 MASM 列表文件选项一些额外的选择，它会给你这个错误。
只要用一下
就可以了。
但任何额外的东西都有问题。
Mine is that if you set MASM listing file option some extra selection, it will give you this error.
Just use
it is fine.
But any extra you have issue.
今天重装后出现这个问题。确保应用程序体验服务已启动且未设置为禁用。如果设置为手动，我相信VS会启动它。
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.
我知道这已经很老了，但我刚刚在 Visual Studio 2010 上遇到了同样的问题，所有补丁都已修复，所以其他人可能仍然会遇到这个问题。
将我的项目路径添加到我的 AVG 防病毒设置中的“排除项目”似乎已经解决了我的问题。
尝试禁用任何防病毒/驻留防护罩，看看是否可以解决问题。如果是这样，请将您的项目路径添加到 AV 配置中的排除目录中。
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.