Related
I have a single solution containing several projects but am only running two right now.
Project 1 runs as a windows service in Release mode but runs as a console app in Debug mode. Project 2 is an MMC snapin (output type=class library). They communicate via WCF.
TIME A
When I first started debugging yesterday after a fresh build my callstack window showed this:
lines in service...
[External Code]
--Transition from Client to Server --
lines in client...
I could double-click any line to go to that line. I could set breakpoints in either project and they would be hit.
TIME B (Sometime later in the day)
I started seeing flags on breakpoints in the client (project 2) indicating "The breakpoint will not currently be hit. The source code is different from the original version" even though I just rebuilt all projects. I had made a few code changes but (as far as I know) no project or build changes. I did a solution "clean" but that did not help. The call stack still worked the same as during TIME A.
TIME C (Next day--this morning)
I rebooted. I deleted all obj and bin directories. I rebuilt the entire solution and launched hoping a fresh start would improve the situation. Now it is worse. Breakpoints are flagged with "The breakpoint will not currently be hit. No symbols have been loaded for this document." The call stack has deteriorated to showing the client as external code:
lines in service...
[External Code]
--Transition from Client to Server --
[External Code]
If I select show external code in the call stack it lists lines from the client assembly (mixed in with system assemblies of course) but all greyed out. In the Module window (debug >> windows >> module) the client assembly is not listed.
If I select symbol load information from a line in the call stack it shows "cannot find or open the PDB file" for 5 different locations, the most curious one being under my project's obj/Release directory--not the obj/Debug directory--even though my project is set to Debug configuration.
If I select load symbols from a line in the call stack then select the pdb file in either my obj/Debug or bin/Debug directory, it reports "A matching symbol file was not found in this folder".
Configuration manager shows that all projects are set to Debug configuration and all are included in the build.
I have reviewed similar SO questions, which helped me find all the above things to examine, but have not yet found any rhyme or reason to my situation.
How can I save Visual Studio from its delirium and recover my lost symbols?
OK, Visual Studio, as I should have expected, it was me, not you. You have, through thick and thin [clients], continued to show your steadfast support [functions]. Can we still be [virtual] friends? It boils down to a difference in our cultures. I take things at face value; you like to bury yourself in your registry data, ignoring my MMC snapin code that was right in front of you shouting "I'm here, I'm here!".
Sigh.
I'm here.
I mean, just because it did not replace your last relationship with InstallUtil is that any reason to dredge up the past, bringing those long-forgotten bits [of code] to the surface, keeping the dll forever separate from the pdb? Apparently you think so. Aye, there's the rub! I just did not understand you, but now I do.
Oh, yes; now I do.
This is a weird problem, which luckily (?) also happens on other machines.
I've never had problems with debugging, and now I have: it shows an exclamation mark at my breakpoints which says :'The debugging symbols are not loaded for this document'.
The difference with other projects is that I run this web application in IIS:
I've created a new website in IIS 7.5 (win7), listening on port 80 to
local.comparer.nl
I've added the url local.comparer.nl to my hosts
file, redirecting it to 127.0.0.1
I've edited the start page of the
project (asp.net 3.5) to local.comparer.nl in 'use local IIS
webserver'
When I start the site, it first says 'unable to start remote debugging'. I don't know why it looks for remote debugging, but when I started the remote debugging monitor, it still didn't work.
When I unloaded the debugging monitor, it didn't complain about the remote debugging anymore, but the exclamation mark still was there.
Solutions which -sometimes- help at my colleagues pc's:
Delete everything from the \bin directory and rebuild
Rebuild again (n number of times)
Choose 'clean solution'
Any idea?
Are you building full debugging symbols? If not then the debugger has no information to relate the source code to the in memory activity under the debugger. This is set in the project properties per configuration.
Also ensure the symbols are in the bin folder.
You can validate that VS is loading the right symbols with the Debug | Modules window.
I had this issue bothering me for quite long. Finally, what resolved my problem is :-
1) Make Internet Explorer the default browser
2) Clean the solution
3) Build the solution
In my case I renamed an asp.net page and disconnected the code behind. Strange it still ran but did not run the code behind and therefore did not hit breakpoints in it.
You have to in Visual Studio 2010
Select "Build" Meanu > Clean [Project/Solution Name]
Rebuild [Project/Solution]
Try debug again... Good luck
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.
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.
I'm unable to debug a WinForms C# application using the released version of Visual Studio 2010 Prof.
I get the following error message after the second debugging run.
Error 9 Unable to copy file "obj\x86\Debug\Arrowgrass Reports.exe" to "bin\Debug\Arrowgrass Reports.exe". The process cannot access the file 'bin\Debug\Arrowgrass Reports.exe' because it is being used by another process.
I've tried a pre-build script to attempt to delete this file, but it's locked by Visual Studio.
There are a few references to this on the net so it is a know problem. Does anyone have a hotfix or effective work-around?
I have found this issue very easy to reproduce, and the fix for me is a variation on Richard Fors' answer. If I have a UserControl open in the designer, run the debugger, and then edit the UserControl, the subsequent rebuild will fail. If I close the UserControl before running the debugger I never get this error, so I just make sure to close the designer window before hitting F5.
As of October 2012, I still have that issue so the VS 2010 SP1 didn't solve the problem. What I did, and worked consistently, was disabling the hosting process in the projects.
To disable the hosting process:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Source:
http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx
You can try to kill the vshost.exe process:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
You might also be lucky and simply be able to move the file in question. Moving the file can be done by adding the following lines of code to the pre-build event of your project:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Disabling windows search did not fix for me. However disabling Antivirus did (our Antivirus is Symantec Endpoint Protection 11)
As such, I was able to fix this for myself by changing the Debug settings in the project to point the working folder to a path on the C: drive, and then excepting that path from the antivirus auto-protect scan settings.
I hope this helps someone.
I posted this answer in a similar question but figured I'd also say it here:
Alright... this might sound pretty crazy.
I've had this problem in VS2010 for the last couple of years. The workaround mentioned here works for me, but a lot of times I forgot to close all my forms/usercontrols first.
I've discovered that merely going to view the open files via:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
will "Free up" whichever file is being locked. Very strange, but it works for me!
In my case, I did Project Properties-->Security Tab-->Uncheck Click-Once security settings (If it is checked). It worked for me. In my project, it was showing this error for a C++ dll being used in my C# project.
The condition described can also be caused by the offending DLL or EXE referencing itself; in which case the Process Explorer test described previously never returns a match (e.g. it's not running). This unexpected situation seems to be caused during some sequence of operations in VS2010 (and likely all previous versions) which insidiously adds the reference behind the scenes. The specific cause of this hasn't been tracked down (or resolved that I know of). To check for, and resolve this error simply make sure the offending DLL or EXE is not listed as a reference to itself.
Got the error ("The process cannot access the file … because it is being used by another process") when I modified the (Visual Studio 2010 C# Express with SP1) solution from two large (10 source files, ~500 lines per file) projects with one referencing the other, to lots (6) of smaller projects with lots of projects referencing other projects.
The references were to the dll- and exe files (the Debug versions of them), NOT to the projects even though the projects were in the same solution.
I then learned that references should be to projects, not files, for F12 to work properly. So I modified the references. That made F12 work (jump to the source file instead of some auto-generated interface description), and at the same time the "cannot access file" error during build disappeared.
I only got the "cannot access file" error when doing Release builds. The references were to the Debug versions of exe/dll's. I suspect that this mixing is what triggers the bug in VS.
I encountered this issue when developing windows services. I found out that it happens when the service is running. Thus, you only need to stop the service (from the services.msc console) and you're good to go !
Hope this helps.
Tidjani.
Check Task Manager for the specified process and End the process explicitly. This solution worked for me.
I cant' write to a comment since not at 50 points but for me I excluded my project folder in ESET Enpoint Security ver 5. Seems like it blocked/hogged some files. My Error did not state which exe or file was in use so it took a long time to finally get to what JoeC said about Antivirus and tried it. Seems to be working now (Visual Studio 2010 SP1)
Closing recently changed User Controls solved the problem in my scenario. Hope this will help somebody out there.
Looks like this issue has (finally!) been fixed in the VS2010 SP1
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en
Please try uninstalling Windows Live SYNC. Does it still happen?
I think I just found the culprit and the solution.
Go to services and stop & disable the "windows search" service.
That solved the problem for me now.
For me the solution was to change the startup project to a dll (problem only occurs in debug mode when having an application as the startup project). If your solution contains several projects (and it will, and it will contain a .dll, else you would not get the problem), switch to that .dll, no .vshost.exe, no problem.
Also, killing .vshost.exe did not work for me, since immediately after starting again, it had locked the .dll.
Also, make sure to have your references clean, especially in more complex projects, and also prefer project references to assembly references, and so on. I suppose bad references (circular and similar) are bound to cause problems, at least so I have read.
A short article by me on this problem (and my solution)
How to "clean up" your references in a solution
Adding the following to the Pre-build event of the shared dll worked for me:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
It's based on the solution given here but instead of just renaming the dll to .locked it keeps trying to rename it to .locked1, locked2. Using 10 I usually run into the problem once a day, but ant value can be used.
Simply make a copy of the whole project and run project from the new copy.... it will work fine.
But you will have to end process of the debug somehow in-order to delete the older project.
Stop IIS service and try building it again or if you can afford to restart your pc, give it a try. Worked for me both ways.
Cheers
My problem was that Outlook 2010 (outlook.exe) was using the same port as my ASP.NET MVC project with IIS express.
Solution: close outlook.exe, run your solution and open outlook again (so that it uses another port).
Hopefully this helps somebody, because I received the same error message as described in this topic.
Try deleting .exe file in debug or release folder (whatever you working on)
Windows will prompt that the process X has opened this and you can't delete it
after that go to task manager and in details tab end task X process
Delete obj file.And stop your service and Restart again.Then you may solve the problem
The best solution for me was to move my project files out of My Documents - which is on a server managed by the IT department - and locate them locally on my C drive. Also working: unchecking the "Enable the Visual Studio hosting process" checkbox, as stated by other people.
If you are working on a C# project which is using reference of C DLL, then you can eliminate the error by checking the Allow unsafe code check box. I know I have not used pointers in my C# project but I was using some bitwise operator in C#. May be these C-like features morphed it as 'Unsafe' code.
What worked for me was removing "read only" status on the bin folder. Once I did that, it has worked ever since.
I've had this error when the project is on a remote share (like, if your $env:homepath is helpfully redirected by your IT department to a network share). Make sure your project is resident on a local drive.
My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
A literally removed the whole source code regarding the custom control and last problem never stopped, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
So: just check the references and remove the self-reference to the project.
Delete your Bin folder and run the application.
This worked for me. :)
Simply turn off Visual Studio hosting in debug, run the project and again re on it and run project.
Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box
For Windows Project
The Visual Studio hosting process can hold the executable file pointer. To stop the host instance, open the Project properties and then go to Debug tab. Now uncheck the Enable the Visual Studio hosting Process option and then check the checkbox again to debug.
For web project
The IIS can hold the file pointer. Restarting the IIS can solve the issue.