Problem Description:
Occassionally when debugging, I get the following error. I'm using visual studio 2010:
1>------ Build started: Project: projectName, Configuration: Debug Win32 ------
1>LINK : fatal error LNK1104: cannot open file 'C:\Projects\projectName\Debug\projectName.exe'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Note that projectName is the name of my project. The error occurs when I debug, make changes, and debug again (after doing all of that, the above error shows up instead of running the program a second time).
Steps to replicate:
Create a new empty c++ project, and add a file called "main.cpp" to the sources folder
Copy the following code into main.cpp:
int main(){
return 0;
}
Click the green debug arrow button, and note the successful run of the program. Ensure it is closed and that the debugging session is over. Open the process explorer and ensure the exe for the project is no longer running (if it is, wait until it closes).
Erase the contents of main.cpp and replace it with this code (or any other code that will compile properly which is different than the code used above):
#include<iostream>
int main(){
std::cout<<"hello\n";
return 0;
}
Click the green debug arrow button. Instead of running the program, the IDE will show the fatal LNK1104 error. You've now replicated the problem.
Any ideas on how to fix this?
Additional Details:
If I try to change the permissions or delete projectName.exe after the error has occured, an error popup shows up which says:
You need permission to perform this action
You require permission from the computer's administrator to make changes to this file
I am using windows 7.
The account I'm using is an admin account, but this issue also occurs exactly the same when I use a non-admin account.
For 2-3 minutes after the error occurs, I cannot rebuild or debug the project, but after approximately that amount of time, I am able to start at the beginning of the repro steps again.
UPDATE: BOUNTY
Anyone who can offer a solution that fixes the problem gets 100 rep :)
I've tried stopping all services, processes and applications that could be interfering with VC++ accessing the file, and the issue is still occuring. Also, running vc++ as an admin does not help.
This is most likely a bugfeature of the Windows Explorer.
Make sure that the .exe file is NOT selected/focused in the Windows explorer. On Vista i often get LNK1104-errors, when the executable file is selected in the Windows Explorer during linking.
If that does not help, check that no other program has "selected" the file.
EDIT:
This program can show you which process has locked your file (the pages contains some links to other "unlock" tools aswell)
I had this problem with a new program I was writing that seemed to compile once but gave your error at the end of compilation and on subsequent builds. My Antiviral program, BitDefender, had locked the exe file. My exe was in the list of viruses found. I turned off Bitdefender for 5 minutes, recompiled and the program was not locked when Bitdefender restarted or thereafter.
You can use Process Explorer to see if any process has a handle open to that file, even if the executable itself isn't running. Go to Find -> Find Handle or DLL... and type in projectName.exe, and it will give you a list of all processes that have it open.
My guess would be that something has a lock on the file. For whatever reason, VS cannot open the file to write the output of compilation. As SnOrfus suggests, make sure some sort of profiling or testing tools aren't open. I would also try to wait a few seconds between finishing an execution of the program (debug or otherwise) before attempting to rebuild. It's possible that you're building so fast that the debugger still has a lock on the file when VS attempts to access it.
I've never seen that happen when there wasn't a lock on the file. Do you have any profiling or testing tools that might still be holding on to it?
note: I wasn't able to repro that.
edit> Have you tried opening process explorer while the program is running (as opposed to task manager)? It'll show you if your exe is running in any other processes.
Have you checked for malware? I recently had a case where some malware that would bootstrap every process that ran on a machine, and task manager wasn't very informative.
Related
Sorry if this is a duplicate -- I've looked at this and this and others, but I can't find my problem.
A program I build debugs successfully on my local machine, but when I try to debug it remotely, I can't set breakpoints in my code. I've opened the modules window in the debugger, and under Symbol Status for my executable, it tells me "Cannot find or open the PDB file." I try to load it manually, and get the error, "A matching symbol file was not found in this folder."
I created a minimal (hello world) app, and I can debug that, so I'm able to reach the remote PC. Indeed, the app does start up and run on the remote system. So, it isn't an access issue.
Not sure what else to say about this, other than to show you my project debugging configuration:
Any ideas are MOST welcome. Thanks...
Well, I found the answer -- I needed to check the "deploy" box in the Configuration Manager window. This surprised me a little, as using the "deploy" command (available from right-clicking the project property) didn't do the trick. Evidently, there's some behind-the-scenes magic that takes place when the deploy box is checked.
I'm using VS2017 (Enterprise) to build a project. I'm pretty new to VS and especially to setting up my machine for a big project, so please do let me know if you need more info.
A while ago, my build was working fine, all cpp files were compiling well. Then I made some changes to a few cpp files (harmless little changes). But after I restarted my machine, I keep getting a
D8050: failed to get command line into debug records
The full error message is:
D8050 cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\c1xx.dll': failed to get command line into debug records projectnameC:\Users\username\Documents\reponame\projectname\cl 1
However, this seems to be a really outdated error. I can't find the official support doc for this error (when I click on the error code on VS, it leads me to the support main page) and all the S/O questions are from 3-4 years ago. This question's answer suggests changing the TMP variable, but this can't be found under Properties anymore.
Just fyi, my OS is Windows 8, and my computer shut down abruptly while the project was building (it's a borrowed laptop, battery is old). I'm wondering if that has anything to do with this issue.
Again, please let me know if you need more details (eg logs).
I was able to solve this by switching to a user with admin rights, I had a feeling this was something related to user-permission rights
I was suggested by a friend to do a clean build (clean + rebuild), but this also failed.
What did solve my problem was deleting and reinstalling VS all over again. This reset the program files folder for VS and my build is working again.
I did uninstall McAfee at the same time, because I saw somewhere that antivirus software might be disturbing the build, but I'm not sure if this affected the build.
I am developing a VB.NET (4.5 framework) solution in Visual Studio 2015, Win10 OS, and have been able to run the builds uninhibited for several months, but now I am receiving the following error upon starting the build:
vbc : error BC2012: can't open
'C:\MyProject\ProjR5\ProjR5\obj\Debug\ProjR5.exe' for writing: Access
to the path 'C:\MyProj\ProjR5\ProjR5\obj\Debug\GenTagR5.exe' is
denied.
At first, VS2015 would give me the option to run the last successful build, but even that is no longer an option. After exhaustive internet searches on this problem, none of the dozen or so given solutions are solving my issue.
Here is what I have tried in order to resolve the error so far:
Ran sfc /scannow (elevated prompt)
Using ProcessExplorer, find handle or DLL substring that included my project
Made sure there were no hanging procs (including procs with my project name, devenv.exe, [project].exe, [myproject].vhost.exe, etc.)
Restarted VS2015
Restarted VS2015, running "as Administrator"
Restarted Computer
Full Shutdown of computer
Complete Rebuild of Solution
Build->Clean Solution
Build->Clean Solution, then Build->Build Solution
Build->Rebuild Solution
Uninstalled and Reinstalled VS2015
Disabled all indexing
Removed "Read Only" attribute from entire project folder and files within
Checked startup scripts for like- or identical processes
Disabled all AV apps
Disabled all antispyware apps
Disabled all firewalls
Verified that Application Experience (services.msc) wasn't disabled (I'm using
Win10 ... it isn't even in the list of services)
Set Tools->Options->Projects and Solutions->Build and Run->Max. parallel
builds to 1
Rerun aspnet_regiis.exe (under .NET\Framework)
Checked Local Security Policies and verified account was listed under
"Impersonate a client after authentication"
Removed \bin and \obj folders
Put \bin and \obj back when removing them didn't help
Removed \bin and \obj folders, then Rebuilt
None of these have worked. Any suggestions?
The problem ended up being Samsung Magician's Rapid Mode losing data during its write-caching phase to my solid state drive. I turned off Rapid Mode, and now the project builds without any problems.
Sorry for came too late, but i had this problem and i wanted to show how i fixed for the next devs who need a solution:
It's quite simple, just change your proyect assembly name:1) On your solution explorer: Right click on your proyect.
2) Properties>> aplication>> assembly name>> change it.
3) Compile, run to test it.
4) Change the name again if u wanted the original name.
Adding a description:
Changin the assembly name
New 2 programing in VS but i had same problem of Access or Write exe file ON BUILD.
Problem came out of nowhere. I didn't use or make changes 2 exe file in months,
made exe file, used it now and then and forgot about it....
Then after few months i wanted 2 start exe but no icon on desktop ??? ....tried everything, lost 3 days of searching inside code for error in VS and then called Google....
I read last comment ABOVE which mentioned Bitdefender, opened it and found BitD did block and isolate exe files ..... so i tried exluding files and folders which made problems inside BitD but no help....
So i went back 2 VS.
Within debug i got some X86 processor error which didnt make problem to build but it was warning (free component name in error description helped me ), - errors you can ignore but they are here on build ....
So i made last move before starting it all over again. Removed COMPONENT from application, deleted it on PC ...started VS from start .. and ALL was OK !!!
So in my case it was all about FREE component i used in app inside VS .... Bitdefender found some add / virus in it and blocked build progress.
BitD deleted or blocked exe file in start....
Hope this help anyone with similar problem !
The cause of this error for me was that Team Foundation Server had pulled in a bunch of files to my work space as Read-only. Not sure why it pulled them down from the server with read-only checked, but all I had to do was uncheck it.
Ok. Create a new solution and add its directories to the exception list and copy all your work, except for the '.vbproj' and except for the '.csproj' and the directory files to the directory of the directory of the new solution. I have tried that and it works, due that I have Bitdefender, it will be the only way to sort that issue. After doing so, try to build the app again. If it does not work, then I am definitely out of ideas.
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.
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.