Access Denied and Fusion logging RRS feed

  • Question

  • Ok so here's a very strange problem.

    We have a .NET Remoting application running under .NET Framework 2.0 which has been working for a number of years. Recently we dicovered that certain method calls to the server were not working when called from clients running outside the local network, entering through a NAT router. Investigations showed that these methods were returning complex types such as FileStream and Dataset. Network traces and a search of the Internet showed that this was caused by the server embedding its private IP address in these method responses. The solution was to add a machineName property when registering the remoting channel within the server application. Setting the machineName property to the dnsname of the server worked however it introduced a new problem.

    In another part of the application, a method call began to fail with a System.IO.FileLoadException with the message: 

    "Could not load file or assembly 'MaxIT.Infrastructure.SchemaManager.Core, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied."

    Removing the machineName property of the channel eliminated the problem and the application works again (albeit with the original problem passing FileStream and Dataset to external clients). Since the required DLL does exist in the same place it always has, this must presumably be a permission problem though it is unclear why adding the machineName property to the channel changes the security so that a change in permissions is required. Can anyone explain this?

    Anyway, it gets stranger. In order to investigate the permissions problem, I wanted to examine the Fusion log within the exception. Unfortunately Fusion logging was not turned on so that Fusion section of the exception showed:

    "WRN: Assembly ninding logging is turned OFF.
    To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
    Note: There is some performance penalty associated with assembly bind failure logging.
    To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]."

    So I added the EnableLog entry in the registry and restarted our server application ... and the FileLoadException disappeared entirely. So having Fusion logging turned on somehow changed the system so the DLL could be loaded successfully. This was going to make investigating the exception somewhat difficult. And yet I need to get to the bottom of the problem because I don't want to leave Fusion logging turned on permanently because of the performance penalty.

    So I removed the EnableLog entry in the registry and restarted our server application ... and the FileLoadException problem still is not occurring again. So whatever change to the system was made by turning on Fusion logging is still in effect. Now our application works fine including for the remote clients.

    Now I cannot reproduce the problem and I cannot gather new information about it and yet, I don't want to let it lie because all this occurred in our test environment and I'm worried that I'll run in to the same problem when we move this version to production. I don't consider turning Fusion logging on then off to be an acceptable solution even if it does work.

    Can anyone shed any light on this?

    Thanks in advance

    Tim Blizard
    Wednesday, July 15, 2009 1:51 AM

All replies

  • IMO there is not enough information to conclude anything here. If you cannot reproduce your problem now, then just wait for it to appear again. Otherwise you can just guess ... and that is mostly not productive way how to solve problems.


    Saturday, July 18, 2009 12:46 PM
  • Reminds me of a old nighmarish problem with COM objects on ISAPI serversr, when running with impersonation. The issue: class factories for server objects capture the credentials of the FIRST user to connect to the site. If the first user can't create the object, then all subsequent attempts to create the object fail.

    Are you impersonating? if so, maybe it has something to do with the location of the first user to connect to the site. (Changing settings would involve a restart of IIS, which would reset the clock on which user connected first).
    Sunday, July 19, 2009 5:33 AM