I've been stuck with this error for a couple days now with one of our C++ products. This only occurs when I trigger the build in TFS.
Here are the details:
It is a VS2005 solution with a few C++ projects in it
We are using TFS2012 Update 3
MSBuild Platform is x86
Opening the solution in VS2005 and building does not generate this
error
Full error message, cl : Command line error D8022: cannot open
'xxx.rsp'
I've tried:
Changing the intermediate and output directories to point to
different locations
Changing project dependencies so projects are dependent on each other
Disabled parallel builds
Gave my build account admin rights
Any insight would be greatly appreciated! :)
EDIT
After looking around the logs some more, it seems like the build isn't generating the .rsp files before attempting to locate them.
I noticed when building locally my log displays some warnings before it creates the .rsp file, while the build server lacks these warnings. They both should generate these warnings prior to the .rsp creation.
So my new question is, how do I resolve this race case?
Related
We have a fairly large solution (>200 projects) and recently switched to VS2019. We are using Qt 5.14 with Qt Visual Studio Tools 2.7.1.18 and QtMsBuild. After we started using VS 2019 we get the following warning multiple times when we build the solution:
"...\AppData\Local\QtMsBuild\qt_globals.targets(131,5): warning : Qt::BuildLock[{E42AFBC7-0C5E-441F-B1DB-AE4C9E75F86E}]: Waiting..."
The GUID is the GUID from one of the projects in the solution. Sometimes the build process even hangs up on the "Waiting..." but in most cases the warning does not seem to have an obvious effect other than that it is displayed.
My question is: Where does this warning come from? Why does it show? And how can we get rid of it?
I recently had a problem pop up seemingly out of nowhere. It's described in this issue: Visual C++ Builds Failing due to Log File Access Collision
Based on my investigation, Visual Studio appears to be redundantly building project dependencies instead of just referencing them, and when multiple projects with the same dependency build simultaneously, they will both hit a log file (or some other file) simultaneously, causing one to fail due to access restriction.
It seems that the QtMsBuild developers solved this by adding a CriticalSection task to the QtPrepare target preventing concurrent access. The downside is that this gets reported as a warning.
I'm attempting to merge some code from a 3rd party. I thought I merged the source file ok as well as the .vcxproj files. To test out, I tried to do a compile of a single source file. It did a compile and failed with a message (don't remember what atm) and I addressed the error and tried to build that source file again. What I got was
1>Error: The operation could not be completed
Yes, not very helpful error message and I'm at a loss. I tried to delete the object files and tried again, I still get the same message. It doesn't seem even building anything. What can I do to get VS2017 to give me more helpful diagnostics? What could be causing this issue?
I got this error when moving a website from .net 2 to .net 4.6.1 which was hosted on local IIS7.5. It also showed as Visual Studio throwing all manner of errors upon loading the solution (pointing me at the not very helpful activity log)
All of my assemblies had been recompiled to .Net 4.6.1 and I'd changed the app pool to run .net 4 and integrated, however, VS seemed to think the web site should be loaded or compiled as plain .Net 4.0. This meant that it couldn't load the .Net 4.6.1 assemblies but didn't register this error just said it couldn't complete the operation.
I amended the web.config to add targetFramework="4.6.1" into the compilation element and it fixed it.
I just had this same error which drove me mad for hours. It turned out to be due to some sort of mix-up in the compilation configurations in the solution file, which made reference to configurations that did not exist (because the solution had been copied from another with more projects in it). What appeared to fix it was just going into the configuration manager dialog and then saving.
During a long compilation with Visual Studio 2005 (version 8.0.50727.762), I sometimes get the following error in several files in some project:
fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'
(The file mentioned is either vc80.pdb or vc80.idb in the project's temp dir.)
The next build of the same project succeeds. There is no other Visual Studio open that might access the same files.
This is a serious problem because it makes nightly compilation impossible.
It is possible that an antivirus or a similar program is touching the pdb file on write - an antivirus is the most likely suspect in this scenario. I'm afraid that I can only give you some general pointers, based on my past experience in setting nightly builds in our shop. Some of these may sound trivial, but I'm including them for the sake of completion.
First and foremost: make sure you start up with a clean slate. That is, force-delete the output directory of the build before you start your nightly.
If you have an antivirus, antispyware or other such programs on your nightly machine, consider removing them. If that's not an option, add your obj folder to the exclusion list of the program.
(optional) Consider using tools such as VCBuild or MSBuild as part of your nightly. I think it's better to use MSBuild if you're on a multicore machine. We use IncrediBuild for nightlies and MSBuild for releases, and never encountered the problem you describe.
If nothing else works, you can schedule a watchdog script a few hours after the build starts and check its status; if the build fails, the watchdog should restart it. This is an ugly hack, but it's better than nothing.
We've seen this a lot at my site too. This explanation, from Peter Kaufmann, seems to be the most plausible based on our setup:
When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Bild and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution: Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.
Switch the debug info to C7 format instead of using the PDB.
Project Options -> C/C++ -> General -> Debug Information Format and set it to C7.
This generally happens when your previous attempts at debugging have not killed the debugger fully.
In Task manager look for a process called vcjit, kill it and try again.
Worst option restart visual studio, this should solve your problem.
I had this problem today and it turned out to be non-ansi characters in the path to the pdb that caused it.
I'm using windows through vmware, and my project was in a shared location: \vmware-host\Shared Folders\project
When I moved it to \Users\julian\project it resolved the issue.
I just ran into this problem. Visual studio was complaining about not being able to open vc100.pdb. I looked for open file handles to this file using procexp and found out that the process mspdbsrv had an open file handle to it. Killing this process fixed the issue and I was able to compile.
Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........
I had a similar problem while working on a project which I had located in my Dropbox folder. I found that it would throw this error when the little "syncing" icon was going on the Dropbox icon in the system tray, since Dropbox was accessing the files to upload them to their server. When I waited to build until Dropbox finished syncing, it worked every time.
I have same problem C1033: cannot open program database,
Scenario
I have two dll's parent.dll and child.dll.I just attached child.dll project with visual studio debugger at the same time i am trying to build the parent.dll project,produces error C1033: cannot open program database
Solution
Stop debugging and kill the process attached with the debugger.Rebuild the project
This happens to me consistently if I Ctrl+Break to cancel a build (vs2015). There's some process that isn't shut down properly. I went on a rampage "End Tasking" ms/vs related processes (look for duplicates) and my build worked again. A restart would probably work too. As would moving to gnu binutils.
Annoyingly unlocker tools don't report any processes locking the file, windows doesn't let me delete the .pdb but I can rename it. My guess is two processes jump in at the same time during a build.
Are you using LinqToSql at all? Perhaps it is similar to the odd error I will experience occasionally as I asked in this question: What causes Visual Studio to fail to load an assembly incorrectly?
I changed my intermediate directory from:
%TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
to
C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
It works now. NO idea why.
In my case the problem was Google Drive: I forgot that the project was under a synced folder and G Drive probably locked that file. Pausing the sync didn't help since the error was throwed anyway.
Moving the project folder to another location not synced by Google Drive solved my issue.
Just to mention, at the beginning I thought it was my anti-virus, since when examinating the file using procexp it showed that the file was used by one of my anti-virus process. Excluding the folder project from my anti-virus scan didn't help in my case.
the simplest solution is "build one more time":
BuildConsole abc.sln /rebuild /cfg="release|Win32"
if %errorlevel% neq 0 (
BuildConsole abc.sln /cfg="release|Win32"
if %errorlevel% neq 0 (
rem process error
exit 1
)
)
I just ran into this problem and Google led me here. For me, it was Google Drive syncing my project files while I'm trying to run. Pausing Google Drive sync temporarily solved it, but I'd rather there was a way for Google Drive to keep its hands off while Visual Studio is doing its stuff. If anyone knows how I can configure that, please let me know
I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:
Rebuild Solution
Clean followed by Build Solution
If I did a second Build after either of these, the problem did not show up. Using Google, all I really came up with was year-old blogs from Microsoft saying they are unable to reproduce the problem, or that it is fixed in a future release.
The best thing I found was here: Mikazo Tech Blog: Solve MT.exe Errors in Visual Studio 2010
In the above article it said that the problem is related to Manifest generation, and that the solution is to turn off Manifests in settings under Linker-->Manifest. I don't need Manifests for this project, but I still wasn't satisfied.
I have solved this, and am simply going to answer my own question, because I haven't found this specific error (code 31) on StackOverflow.
WARNING: This exact error can also happen as a result of having a Windows Explorer window open in the folder containing the *.exe which you are currently attempting to build.
For example: Explorer open in /.../MyProj/Debug/ while trying to build the Debug version of your code in Visual Studio.
I was angry with myself for ~10min before realizing this.
Using process monitor and dbgview I discovered msmpeng (Microsoft Security Essentials) was accessing the file, just when mt.exe wanted to have it exclusively. Excluding the development directory solved the problem.
It is still a workaround of course.
In my projects, the Intermediate and Output directories were set to:
Intermediate Dir : $(Configuration)\
Output Dir : $(SolutionDir)bin\$(Configuration)\
Under C/C++-->Output Files, I had the following:
ASM List Location : $(IntDir)\
Object File Name : $(IntDir)\
Program Database File Name : $(OutDir)\$(TargetName).pdb
Under Linker-->Manifest File, I had:
Manifest File : $(IntDir)$(TargetName)$(TargetExt).intermediate.manifest
The cure was to remove the trailing \ from my C/C++-->Output Files section (because it's already part of those variables):
ASM List Location : $(IntDir)
Object File Name : $(IntDir)
Program Database File Name : $(OutDir)$(TargetName).pdb
Normally, the double-up of using $(IntDir) or $(OutDir) with a trailing \ doesn't seem to cause trouble, even though it's bad practice. I can't remember now whether I did it by accident or if the conversion process did it, but for whatever reason, it seems to have been messing up MT.exe.
I hope this is useful to anyone else who encounters this problem. Your settings may well be different, but consider that it may be related to improperly formed filenames.
Try turning off Windows Defender (or possibly other anti-virus related software). Windows Defender is known to lock files because MT.EXE runs after the linker is finished. WD jumps in the middle to check up on the newly built EXE and locks it up for the MT.EXE.
Giving credit to https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c5a3e2c3-fbf4-4268-a551-8cee195be586/test-case-13-for-vista-certification?forum=windowscompatibility, I found this was resolved by fixing the '-' character in the post build commandline. I believe some bad copy/paste efforts have replaced a hyphen with a dash.
deleting the "program debug database" in "debug" folder worked for me.
This problem happened when I was running the .exe in the debug folder on high priority.
Run VS as administrator. It solved the problem for me.
I have a project (*.sln) written in visual studio c 8.0. It was migrated to VC10 recently. When I choose the "Release mode", it was compiled sucessfully. But if I choose "Debug mode", the error " MSB6006 mt.exe code 31" happened.
I found that, in the debug mode, it used a wrong sub-project to startup.
After fixing the startup sub-project, it goes fine so far.
---- new status ---
This won't fix the problem. It just makes the problem disapear temporalily by rebuilding-all. Also, there are other faults caused by the migration. The "resources.h" is missed from the new project and the "winres.rc" is shorten.
In my case it was a problem with TortoiseGit. Removing Debug and Release folders from the GIT repository solved the problem.
Check if you have any anti-virus software like AVG. Exclude the manifest files in the anti-virus software exclusion list.
Look for an MSB8012 warnings. Likely you have a different output specification for the C++ output value and the Linker Output value.
Try Sysinternals/Procmon and filter on process = "mt.exe". It might tell you that a build input cannot be found.
I am getting the following compile error when building a C++ application in VS 2010
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(153,5): error MSB6006: "CL.exe" exited with code -1073741805.
I know it has something got to do with property settings, but I am not quite sure as to what i should do, Can someone tell me what i should do to remove this error?..Thanks in advance.
I have a long experience with finding and reporting compiler bugs.
First, MSBuild leaves some files that includes the actual command line used to invoke CL.exe. It also sets environment variables, so you might need to look at /v:d output to see the actual steps to reproduce. Get CL.exe to produce the error without MSBuild.
Then prune things out of the source file until you get a small thing that still frys the compiler. I delete stuff starting at the bottom. I remove #include's that are no longer needed; expand out the bottom one that remains and continue.
Save each "save" so you can back out when you kill the error.
Then, log an incident with MS. Once they get it to the proper department, and then determine that it's a compiler bug, they will refund your incident. I recall having something like 3 credits with the MSDN subscription; used that to get it rolling.
You may have had imported property sheets which were not compatible with your current build environment.
Try to open Property Manager and see if any custom property sheets are present.
I just experienced this issue moving from VS2010 to VS2013, where I had some old Windows 8.1 SDK property sheets. Building from the command line caused this error, while building within Visual Studio was fine.