I often have this problem even when I build a new C++ project and try to build a release file.
I use Visual studio 2008. One thing that may cause this problem is my code is saved on the server disk, not on local hard disk.
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\Release\PGTS_version17C.exe". The process cannot access the file because it is being used by another process.
Anyone know how to solve this? Thanks.
If you are embedding a manifest file, your anti-virus program may lock and scan your exe file before embedding the manifest.
I recommend disabling anti-virus from reading your DEBUG and RELEASE output folders.
Go to Debug and/or Release folder(s), right click and unset, recursively, the Read-Only property.
Found this tip in the MSDN Community and solved my problem!
It it's not a permissions or actual file access problem (AV)...
You can add a flag to make the compiler check the validity of the manifest.
This validation will fix the problem so you'll never have to rebuild it again.
This is very important for anyone who's running an actual Build-Machine or automatic buildscript where you don't want to manually interfere:
Add this flag:
Project properties -> Configuration Properties -> Manifest Tool -> Command Line -> Additional options:
/validate_manifest
Funny enough I had the exact same error and a "rebuild" on the whole project solved it.
If you need not generate Manifest file, just set it off it will resolve the problem.
Goto Project(right click)
properties
Linker
Manifest Files
Generate Manifest
change it Yes to No
It resolve the problem for me on VS2008 without disabling Anti-virus. ;)
Enjoy :)
I worked around this with a "wrapper" program for mt.exe, one that reran it until it succeeded. Save the following code as mt-wrapper.cpp:
#include <windows.h>
#include <stdio.h>
#include <process.h>
// Build from a Visual Studio Command Prompt with "cl /O2 /Gy /Femt.exe mt-wrapper.cpp"
int __cdecl wmain(int argc, WCHAR **argv, WCHAR **env)
{
// Stop outputting text.
fclose(stdout);
fclose(stderr);
// Run the original mt.exe, which has been renamed to mt-orig.exe .
for (;;)
{
// Try to run the original mt.
intptr_t iStatus = _wspawnve(_P_WAIT, L"C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\mt-orig.exe", argv + 1, env);
if (iStatus == 0)
break;
// Try again, after a short wait.
::Sleep(100);
}
return 0;
}
Build this program, go to your C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin folder, rename the old mt.exe to mt-orig.exe (and the mt.exe.config to mt-orig.exe.config), and put this wrapper program in there as mt.exe. Now, when you build, it will retry running the original mt.exe until it succeeds.
Oddly, MSBuild doesn't seem to check for a zero status when deciding that mt.exe has succeeded — it seems to look for error messages written to stdout/stderr. So this program closes both of those before spawning the original mt.exe. Anyone feeling industrious can apply the advice found here to save the output of the successful run of the original mt.exe, and output it to stdout/stderr.
Try this:
In my case none of the suggestions presented here worked. I am using Ninja build with VS 2019, and build fails randomly in only Jenkins. Disable manifest is not an option in our case. As a workaround I disable manifest during link stage, however added a custom target with POST_BUILD step to embed manifest using mt.exe.
target_link_options(target_name PRIVATE /MANIFEST:NO)
add_custom_command(TARGET target_name POST_BUILD
COMMAND mt.exe -manifest manifest_file -outputresource:$<TARGET_FILE:target_name>;#1
COMMENT "Adding custom manifest on target_name"
VERBATIM)
With above workaround no failure in Jenkins server now.
If you're using Hudson/Jenkins to create releases restarting it solved the problem for me.
I solved this error by stopping and disabling the 'Timing Service' (part of FireEye)
If your project is stored in Dropbox, you have to quit Dropbox to build. This is also an issue when using Unreal Engine.
