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.
Related
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.
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'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
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?
Working on a Win32 DLL using Visual Studio 2008 SP1 and, since yesterday, whenever I try to right click on code, to go to a variable definition for example, VS completely locks up and I have to manually kill the process. To make it even weirder, whenever this happens the devenv.exe process uses exactly 25% of the CPU. And I mean exactly, never 24%, never 26%, always 25%
Also, I've run ProcMon to see if devenv is actually doing something, but it's doing absolutely nothing external of the process. No disk, network, registry access. Nothing.
This is getting really aggravating because I have a large code base to deal with and the only other way of jumping to the definition is to first search for it.
Has anyone run into a similar issue? And, better yet, know a fix?
Edit: More info. Other projects (even an older version of the same one) work fine. I diffed the project file and the only differences is added source files and a /D define in the command line params.
Edit 2: So, it seems that now it's actually because intellisense is stuck updating. For some reason the status bar was disabled, but when getting it back I say "Updating Intellisense... (186)" and from what I've read, that 186 means that there are 186 background threads working. 186?! But, procmon still shows no IO whatsoever.
Try deleting all .sbr .bsc and .pdb files.
For the 25% CPU load: I guess it uses one core on your quad core machine.
If you have Visual Assist installed, try disabling it.
On connect, a submitted bug: Visual Studio Hang, seems to closely resemble your issue:
At random times, when I right click in the text editor, in this case C/C++ editor, Visual Studio will just hang. And if I wait it out, it still hangs.
It seems the workaround is to exit Visual Studio and delete the intellisense (.ncb) file in your project directory and reopen it.
The issue you are seeing is an intermittent failure in prior versions of Visual C++ that is hard to diagnose, and has a relatively simple workaround, as you have discussed, which is to delete your NCB. In order to get proper intellisense for header files, they would need to be included by a .cpp file in your project (directly, or indirectly through another header.)