Diagnose “Access Denied” error on Assembly Loading

I posted a rather long reply in newsgroup microsoft.public.dotnet.framework.clr, to help diagnose “Access Denied” error on Assembly Loading.


The error is actually very typical and I saw it quite often internally.

I posted the full text below. Hope it is useful to you.

“Junfeng Zhang[MSFT]” wrote in message news:exfHZKorEHA.2008@TK2MSFTNGP12.phx.gbl

> It is very hard to diagnose this kind of problems. I have debugged many
> access denied errors. And most of them boil down to the following scenario:
> 1. You enabled shadow copy on the AppDomain.
> And,
> 2. You have either Anti-Virus or index service enabled.
> And,
> 3. You may have run the applications many times in a relatively short time.
> The reason is related to how fusion does shadow copy. Here is exactly what
> happens.
> 1. Say you enabled shadow copy on the AppDomain, and you load an assembly.
> Fusion will first copy the assembly to a temporary directory under the
> shadow copy directory, then call MoveFile to move the temporary directory to
> the final location under shadow copy directory. The reason is that we want
> the shadow copy to be atomic. And MoveFile gives us the atomicity.
> 2. If you have Anti-Virus and index service enabled, and you are unlucky,
> after we have copied your assembly to the shadow copy directory, and about
> to call MoveFile, Anti-Virus or index service decides to poke around the
> temporary directory. Now when we call MoveFile, we get the access denied
> error.
> Condition (3) is not necessary. But it greatly increases the possiblity of
> the error. When you read/write the same file many many times, it will alert
> the anti-virus.
> The fix is easy, excluding the shadow copy directory from Anti-Virus or
> index service.
> How do you know if you are hitting this scenario?
> First, download File Monitor from http://www.sysinternals.com. Run
> filemon.exe and set the filter to only trace file accesses under shadow copy
> directory. Now run your applications. If you see the Access Denied
> exception, you can stop the filemon tracing. Now search the filemon log for
> “ACCESS DENIED”. When you find it, look at the a few lines above. If the
> application on the a few lines above is Anti-Virus or index service
> (cisvc.exe), you know you are hitting this problem.
> If this is not your case, sorry, I don’t know why. You have to debug it
> yourself. And you should start with filemon.
> —
> Junfeng Zhang
> http://blogs.msdn.com/junfeng
> This posting is provided “AS IS” with no warranties, and confers no rights.
> “Gursharan” <Gursharan@discussions.microsoft.com> wrote in message
> news:62DDE23C-3BBD-4EAA-99A6-72A37711D8C0@microsoft.com
>> My app supports en and ja cultures. The app fails on an Application Center
>> cluster and the fusion log shows 0x80070005 error (access denied). I have
>> checked permissions/ACLs on the assemblies, used tlist -m to check process
>> locks and we don’t use impersonation.
>> Any other way to find out which access is denied?
>> Thanks


Comments (4)

  1. Hi Junfeng,

    I have a similar problem (or may be not) when I try to load an assembly from a custom AppDomain with shadow copy enabled. This is the scenario;

    From inside ASPNET in a W2003 box (Network Service wp account) I create a new AppDomain with this settings:

    AppDomainSetup setupInfo = new AppDomainSetup();

    AppDomainSetup currentSetup = AppDomain.CurrentDomain.SetupInformation;

    setupInfo.ApplicationName = name;

    setupInfo.ApplicationBase = AppDomainApplicationBase;

    setupInfo.ConfigurationFile = currentSetup.ConfigurationFile;

    setupInfo.PrivateBinPath = currentSetup.PrivateBinPath;

    setupInfo.PrivateBinPathProbe = currentSetup.PrivateBinPathProbe;

    setupInfo.ShadowCopyFiles = bool.TrueString;

    // Notice that I not set the ShadowCopyDirectories so every assembly // in the private path should be shadow copied

    setupInfo.DisallowBindingRedirects = currentSetup.DisallowBindingRedirects;

    setupInfo.DisallowCodeDownload = currentSetup.DisallowCodeDownload;

    setupInfo.DisallowPublisherPolicy = currentSetup.DisallowPublisherPolicy;

    // Create the new AppDomain

    AppDomain domain = AppDomain.CreateDomain( name, null, setupInfo);

    When I load any assembly (from the private path, not from GAC) in this newly created domain, the following fusion log is generated:

    The operation failed.

    Bind result: hr = 0x80004003. Invalid pointer

    Assembly manager loaded from: C:WINDOWSMicrosoft.NETFrameworkv1.1.4322fusion.dll

    Running under executable c:windowssystem32inetsrvw3wp.exe

    — A detailed error log follows.

    === Pre-bind state information ===

    LOG: DisplayName = TestAppDomainLib


    LOG: Appbase = C:TestAppDomainLib

    LOG: Initial PrivatePath = bin

    LOG: Dynamic Base = NULL

    LOG: Cache Base = NULL

    LOG: AppName = MyAppDomain

    Calling assembly : (Unknown).


    LOG: Processing DEVPATH.

    LOG: DEVPATH is not set. Falling through to regular bind.

    LOG: Attempting application configuration file download.

    LOG: Download of application configuration file was attempted from file:///C:/Inetpub/wwwroot/TestAppDomain/web.config.

    LOG: Found application configuration file (C:InetpubwwwrootTestAppDomainweb.config).

    LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

    LOG: Post-policy reference: TestAppDomainLib

    LOG: Attempting download of new URL file:///C:/TestAppDomainLib/bin/TestAppDomainLib.DLL.

    LOG: Assembly download was successful. Attempting setup of file: C:TestAppDomainLibbinTestAppDomainLib.DLL

    LOG: Entering download cache setup phase.

    LOG: A partially-specified assembly bind succeeded from the application directory.

    LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

    LOG: Post-policy reference: TestAppDomainLib, Version=1.0.1745.34549, Culture=neutral, PublicKeyToken=null

    ERR: Setup failed with hr = 0x80004003.

    ERR: Failed to complete setup of assembly (hr = 0x80004003). Probing terminated.

    My test showed me that there is some issue with the shadow copy activation, because when I disable it, everything goes fine. However, when I set the shadow copy directories (only inside the physical path of the virtual directory of my test site) all goes fine as well. This is not the case for any other directory outside the physical virtual folder.

    If you have any idea or suggestion about what may be causing this issue, I would greatly appreciate that.

    Thank you and Regards.

    Hernan de Lahitte.


  2. I never saw error like this. If you can provide an repro that will be great.

  3. I just sent this issue to the Product Feedback Center:


    All comments would be greatly appreciated.