Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Error MSB6006: "mt.exe" exited with code 31

I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:

  1. Rebuild Solution
  2. 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.

like image 867
paddy Avatar asked May 21 '13 22:05

paddy


5 Answers

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.

like image 168
bunkerdive Avatar answered Nov 20 '22 00:11

bunkerdive


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.

like image 34
user1839019 Avatar answered Nov 20 '22 00:11

user1839019


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.

like image 5
paddy Avatar answered Nov 19 '22 23:11

paddy


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.

like image 3
wpfwannabe Avatar answered Nov 19 '22 23:11

wpfwannabe


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.

like image 2
KJAWolf Avatar answered Nov 20 '22 01:11

KJAWolf