Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Error C101008d MT.EXE described as having vurus or unwanted software

Ian_K_
New Contributor I
2,492 Views

I just updated to version 4 of the latest compiler and when I compiled in x86 mode / debug  I get an error message C101008d see below

Severity Code Description Project File Line Suppression State
Error general error c101008d: Failed to write the updated manifest to the resource of file "C:\Users\RMADELL\source\repos\rma11v94\Debug\rma11v94.exe". Operation did not complete successfully because the file contains a virus or potentially unwanted software. mt.exe

I do not have the same problem if I compile in x64 mode.

I use Pardiso from the MKL library and have an historic problem with duplicate library names preventing linking (reported to Intel with no luck/help resolving this problem so that I have not been able use 32 bit mode for this program for a while.

When I test a separate program without MKL I have no problems.

Anybody have any clues?   

Thanks in advance  Ian King

 

0 Kudos
1 Solution
mecej4
Honored Contributor III
2,468 Views

Given the few pieces of information, one can only speculate: The program gets linked and, because of a linker option or directive, the MT.EXE program is called to write a manifest to the EXE that was just generated. Simultaneously, an active virus checking program detects and blocks attempted modification of the EXE, since that is one of the things that a virus does.

Some steps that you can consider and take if you find it safe to do so:

1.  Turn off or postpone virus checking in the directory where the EXE is written.

2. Specify (in the relevant part of your build procedure) that no manifest be generated.

If either of these changes allows an EXE to be built, you may then discuss further changes to your build procedure.

View solution in original post

4 Replies
Ian_K_
New Contributor I
2,480 Views

An additional note.  It appears to be a problem with VS2019.  The issue does not appear to occur when I run VS2017

0 Kudos
mecej4
Honored Contributor III
2,469 Views

Given the few pieces of information, one can only speculate: The program gets linked and, because of a linker option or directive, the MT.EXE program is called to write a manifest to the EXE that was just generated. Simultaneously, an active virus checking program detects and blocks attempted modification of the EXE, since that is one of the things that a virus does.

Some steps that you can consider and take if you find it safe to do so:

1.  Turn off or postpone virus checking in the directory where the EXE is written.

2. Specify (in the relevant part of your build procedure) that no manifest be generated.

If either of these changes allows an EXE to be built, you may then discuss further changes to your build procedure.

Ian_K_
New Contributor I
2,444 Views

Thanks for the suggestion.  It appears that the issue is now resolved.  I am not entirely clear why but after initially adding MT.EXE to anti-virus exceptions (as suggested) it had no effect.  Restarting this morning however seemed to activate this change and the linker now functions for both VS2017 and VS2019.  This update now appears to resolve my duplicate library issue associated with MKL that has prevented debugging of these codes in the 32 bit version for  2 years.

0 Kudos
mecej4
Honored Contributor III
2,429 Views

Depending on how your virus blocker works, it may make sense to delay putting into effect an exemption request until the next restart of the virus checker, if not the OS. After all, we would not want to make it easy for a just-downloaded virus to issue an "exempt-me" request and have that malicious request granted!

0 Kudos
Reply