none
FileLoadException (HRESULT 0x80131052): Could not load file or assembly RRS feed

  • Question

  • We have an application where we dynamically load some assemblies with Assembly.Load. When code in this assembly is executed that needs another assembly, we sometimes get FileLoadException (Could not load file or assembly xxx or one of its dependencies). The HRESULT is 0x80131052, which is FUSION_E_CACHEFILE_FAILED (Failed to add file to AppDomain cache). We store the assemblies in a separate folder and have an AppDomain.AssemblyResolve handler to locate and load them, again with Assembly.Load(byte[], byte[])

    Does anybody have an idea when or why you get FUSION_E_CACHEFILE_FAILED?

     

    Thanks for your help.

     

    Tuesday, June 22, 2010 9:06 AM

Answers

  • We added some logging statements into the code, from which it seems to be a concurrency problem: If two threads are executing code in a dynamically loaded assembly and both access a dependent assembly at the same time, the AssemblyResolve event is fired twice. Our handler simply loads the assembly from byte stream without checking if it was already loaded before. So we end up having the same assembly twice in the AppDomain. Soon afterwards we can get the FileLoadException. I am now also able to reproduce this.

     

    I tried to fix our AssemblyResolve handler such that it first checks if the requested assembly is already in the list of assemblies returned by AppDomain.GetAssemblies(). I also had to put a synchronization 'lock' around this code. My test case works with these changes and I hope it will also work on the custormer's machine.

    • Proposed as answer by eryang Friday, July 2, 2010 4:04 AM
    • Marked as answer by eryang Monday, July 5, 2010 2:29 AM
    Thursday, July 1, 2010 11:57 AM

All replies

  •  

    The error occurs when trying to put incompatible PE file to appdomain cache.

    Are those exception happened when you loading the same assembly? Did you set current appdomain's CachePath? What if rebuild related assemblies and try again?


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, June 22, 2010 10:52 AM
  • The exception happened only with one assembly. After the application was restarted, it worked again - without having to recompile the assembly. We do not set the CachePath.

    The error happened on our customer's machine, so I have to relay the information we get from them. So far, we have not been able to reproduce it on our development machines.

     

    Best Regards

     

    Wednesday, June 23, 2010 8:42 AM
  • I also failed to reproduce this issue on my machine.

    If this case is reproduciable on your customer side, you may let him to use fuslogvw.exe to get detail information about this assembly binding failure.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, June 24, 2010 3:06 AM
  • Thanks for your efforts. We will try to get something from fuslogvw. In the meantime, can you please explain what you mean with "incompatible PE file". Could it be a version conflict or an assembly built for a different architecture?
    Friday, June 25, 2010 12:03 PM
  • By "incompatible PE file" i mean the file stream maybe interrupted, from my understanding, it doesn't seems to be a version confliction issue. It will be helpful if you can get more information from your customer.
    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, June 28, 2010 11:16 AM
  • it can also happen if you are running a 64-bit executable trying to load 32-bit assembly or vice versa. If its a 64-bit machine, then use corflags to see if the PE is configured as a 32 bit app or not. IF not, you might want to try "corflags /32BIT+ /force <app>.exe".


    Software Engineer 1, My Blog
    Thursday, July 1, 2010 4:30 AM
  • We added some logging statements into the code, from which it seems to be a concurrency problem: If two threads are executing code in a dynamically loaded assembly and both access a dependent assembly at the same time, the AssemblyResolve event is fired twice. Our handler simply loads the assembly from byte stream without checking if it was already loaded before. So we end up having the same assembly twice in the AppDomain. Soon afterwards we can get the FileLoadException. I am now also able to reproduce this.

     

    I tried to fix our AssemblyResolve handler such that it first checks if the requested assembly is already in the list of assemblies returned by AppDomain.GetAssemblies(). I also had to put a synchronization 'lock' around this code. My test case works with these changes and I hope it will also work on the custormer's machine.

    • Proposed as answer by eryang Friday, July 2, 2010 4:04 AM
    • Marked as answer by eryang Monday, July 5, 2010 2:29 AM
    Thursday, July 1, 2010 11:57 AM
  •  

    We temporarily mark a reply, please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, July 5, 2010 2:29 AM