Home Dashboard Directory Help
Search

mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\Debug\DX10Interop.dll". Access is denied. by TFG


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


8
0
Sign in
to vote
Type: Bug
ID: 301614
Opened: 9/30/2007 7:53:19 AM
Access Restriction: Public
4
Workaround(s)
view
15
User(s) can reproduce this bug

Description

Around 10-30% of the time when I compile the solution I am working on using F5 I get:

mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\Debug\DX10Interop.dll". Access is denied.

If I press F5 again, it usually, but not always compiles fine. On occasion I will get that error a second time. In those cases, pressing F5 again will almost always resolve that issue.

The solution I am working with consists of two projects. One solution is a managed C++ library using Direct3D 10 and is called DX10Interop. The other solution is a WPF application that uses the C++ library called DX10Client. They are both using the .NET 3.5 framework.

It seems to occur the most when I make changes to the header file in the C++ library.

Trent
Details
Sign in to post a comment.
Posted by Edgars Batnya on 7/19/2012 at 5:40 AM
It happens nearly half the times. Hoping VS2012 won't be such a brat.

VS2010 SP1.
Posted by jlbgs12 on 3/15/2012 at 5:25 AM
Just to say this still happens in VS2010 (with SP1). I'm on a dual-core Windows 7 machine (it sounds as though any multi-core or multi-threading machine is susceptible)

The race condition mentioned below sounds accurate, and the advice in that article to set 'Embed Manifest' to 'No' seems to work.

In VS2010 you can find that setting in Configuration Properties -> Manifest Tool -> Input and Output
Posted by SergeLalonde1 on 2/7/2012 at 7:11 AM
Have you looked at this:
http://www.aspnet-answers.com/microsoft/VC-NET/29192102/general-error-c101008d.aspx
It shows that there is a race condition between mt.exe and devenv.exe.
Posted by Aidtopia on 11/4/2011 at 2:06 PM
We started seeing this problem once we upgraded to VS2010. Turning off the anti-virus does not solve the problem. It typically happens for at least one binary in our build but succeeds on a retry. Sometimes, it retries four times and gives up.
Posted by Fishing_Frenzy on 3/6/2010 at 7:07 AM
I have experienced the same thing in vs2008. My issues came after I tried to clean out vs2005. I may have gotten overzealous... with the add/remove patches associated with vs2005.

After getting the error in vs2008, I try the debugger agian without changing anything and it will run.

Todd
Posted by Microsoft on 10/10/2007 at 2:27 PM
The Visual C++ team has triaged the issue you reported. The issue has been resolved during triage with the following message:

This bug could not be reproduced by our engineering team with the VS2008 version.

For further information, you may want to consult one of these resources:
1. Visual C++ triage guidelines:
        http://blogs.msdn.com/vcblog/articles/621116.aspx
2. MSDN forums:
        http://forums.microsoft.com/msdn/default.aspx

Thank you for taking time to send us feedback,
The Visual C++ Team
Posted by Microsoft on 10/5/2007 at 12:56 PM
Thank you for reporting the issue to Microsoft. Unfortunately, we are not able to repro the bug based on your repro steps. Please contact us again once you have additional information for reproing the bug.
Posted by Microsoft on 10/2/2007 at 3:50 AM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided. We tried to repro with the following steps:

1. Create a managed cpp class library
2. Add a WPF App to the solution and set as the startup project
3. Add project reference to WPF
4. Change the header of the VC class library.
5. F5 to debug.

It may help if you provide us with:

1. a zippe project file
2. more exact steps to repro the issue

If we do not receive a response from you after 7-days , we will automatically close your issue. There is no obligation to respond -- at any time you may edit your issue via Connect and change the status to “Active.”

Thank you,
Visual Studio Product Team
Posted by Microsoft on 9/30/2007 at 5:30 PM
Thank you for your feedback. We are currently investigating. The investigation process normally takes 7-14 days. If this issue is urgent, please contact support directly (see http://support.microsoft.com).

If at any time your issue is closed unsatisfactorily, you may edit your issue via Connect and change the status to “Active.”

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by Aidtopia on 4/25/2012 at 8:31 AM
We resolved this by disabling both Sophos Antivirus *and* Parity (Bit9) on build machines. With Sophos, we could exempt the directory from on-access scanning. Bit9 doesn't have such a mechanism, so we had to disable it completely on our build machines.

When the linker writes the executable or DLL, both anti-malware products were attempting to read the entire binary. During that time, MT tries to re-open the binary for writing in order to embed the manifest, and there's a sharing violation. It looks like MT retries a couple times before failing (probably in an attempt to deal with such a problem). But with multiple anti-malware products and lots of disk contention due to a large build, the file may occasionally be under contention for longer than the retry period.
Posted by jlbgs12 on 3/15/2012 at 5:26 AM
As per the comments, set 'Embed Manifest' to 'No' seems to work.

In VS2010 you can find that setting in Configuration Properties -> Manifest Tool -> Input and Output
Posted by dieunke on 9/23/2010 at 1:54 AM
It's more easy (and pssibly more secure) to exclude the outputdir from the online protection. I'm using Microsoft Security Essentials. Excluding the output directory fixed the problem for me.
Posted by npiegdon on 4/4/2008 at 8:10 AM
If you're running Symantec AntiVirus (or possibly another antivirus suite), disable Auto-Protect for the duration of the build.