so I have a project that was housed in another directory that I copyied and moved into another directory in order to dump it into a local git repo that was previously running an earlier version of the code( I know why am I doing this copying stuff well it is a long story and irrelevant). after attmepting to build the project in visual studios 2019 I get the following error during the build.
Severity Code Description Project File Line Suppression State
Error C1090 PDB API call failed, error code '3': C:\Users\chad.lahue\AppData\Local\Programs\Git\TOC\project\TOC\Debug_sim\vc142.pdb TOC C:\Users\chad.lahue\AppData\Local\Programs\Git\TOC\project\TOC\TOC.cpp 1
so after looking up what causes this issue and trying the reboot sugestion to no avail or killing a second msbuild.exe process I have noticed in the task menu that about halfway through the build a second msbuild.exe comes up when building this project and does not on any project that builds successfully
Also the code is the same as well as the project settings as far as I can see from the original directory that it was copied from which still builds just fine.
My question is : 1 is this a code issue / project settings issue or is there some kind of directory or computer glitch?
: 2 has anyone else experienced this type of compiler error and had to resolve it in a more complicated way than what is normally suggested for this error ie. restart computer or kill the second msbuild.exe ? better yet has anyone ever had a project that generates 2 msbuild.exe's during the build process which causes it to fail as it appears to be here?
for others experiencing this issue despite updating their vs like I did the following project settings fixed the issue for me, I have also tried the /FS solution on another project that started experiencing the same issue
For those getting the issue with vc142.pdb try setting "Configuration Properties->C/C++->Output Files->Program Database File Name" to "$(TEMP)vc$(PlatformToolsetVersion).pdb"
It could also work for the other pdb's by setting "Configuration Properties->Linker->Debugger->Generate Program Database File" to "$(TEMP)$(TargetName).pdb".
My best guess is the files are being locked by mspdbsrv.exe due to parallel compilation.
for others experiencing this issue despite updating their vs like I did the following project settings fixed the issue for me, I have also tried the /FS solution on another project that started experiencing the same issue an it seemed to clear it up for good as well.
For those getting the issue with vc142.pdb try setting "Configuration Properties->C/C++->Output Files->Program Database File Name" to "$(TEMP)vc$(PlatformToolsetVersion).pdb"
It could also work for the other pdb's by setting "Configuration Properties->Linker->Debugger->Generate Program Database File" to "$(TEMP)$(TargetName).pdb".
My best guess is the files are being locked by mspdbsrv.exe due to parallel compilation.
I had a similar problem except during my CICD process. I found that removing the pdb files from my repository caused the build process to function correctly since the pdbs would no longer be locked down by the build process.
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
I have a MVC/C# based website. One of the nuget packages being used is a wrapper around PDFium, a non .NET dll. The PDFium dll is included as part of another nuget package and is just a dll that gets copied into the output directory.
The problem I have is that after I have used the website the PDFium dll (ie the non .net one, not the one that is doing the wrapping) seems to get loaded and then locked by IIS. If I then try to do a build in Visual Studio I get an error saying:
Unable to copy file [Full Source Path]. The process cannot access the file [destination path] because it is being used by another process.
A second line in the build error log shows something similar and additionally confirms:
The file is locked by: "IIS Worker Process (28776)"
If I do an iisreset then this will cause that worker process to get killed and thus the copy can happen but I am wondering if there is any kind of better way of doing this. My thought is that all the other DLLs included by nuget packages and similar get copied just fine so maybe there is something a bit more "proper" that can be done to resolve this rather than the slightly heavy handed iisreset approach...
Not sure if any of this will help, but in order to avoid an IISReset, one option is to ensure that the PDFium.DLL being used by IIS is not the one that's copied to your project's target directory during a build. However, if the PDFium.DLL must sit in the same folder as your wrapper assembly (as I suspect it does), then you might not have a good option other than to use IISReset. You could follow advice here (How to restart the IIS Site when re-compiling an asp.net website) to add a pre-build script, saving you from the manual effort.
If the PDFium.DLL doesn't have to be in the same folder as the wrapper and can be registered anywhere on your system, you can try to set that reference's Copy Local property to false so that no copy is attempted. Obviously, this would work only if the wrapper can find the DLL through its registry entry--if it can be registered...
Our builds have been reporting the same error with IIS locking pdfium.dll causing build failure. When I notice it, I use a tool called LockHunter.
When Lockhunter is installed, in file explorer locate the locked file reported by the
error and right-click it.
In the context menu, LockHunter will have added a menu option
"What's locking this file" - select that.
A LockHunter window will appear which reports the file is locked by
w3wp.exe (IIS worker process).
The LockHunter window has an option to unlock the file, select that.
The file is unlocked and then the build works.
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.
I have no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.