locked
FileNotFoundException on Microsoft.Ccr.Core.resources.dll when exception is thrown in a task RRS feed

  • Question

  • Hi,

    we have recently upgraded our projets to target .net 4.0 and using RDS 2008 R3, but now, whenever an Exception is thrown in a task and we have a causality added to the dispatcher CCR throws an exception of its own: 

    Edit: Removing the the causalities doesn't matter, it still crashes.

    *** Assembly Binder Log Entry (01/11/2010 @ 2:06:04 PM) ***
    
    The operation failed.
    Bind result: hr = 0x80070002. The system cannot find the file specified.
    
    Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable D:\TestApp\Debug\TestApp.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: User = XBN\gigs
    LOG: DisplayName = Microsoft.Ccr.Core.resources, Version=2.2.76.0, Culture=en-US, PublicKeyToken=31bf3856ad364e35
     (Fully-specified)
    LOG: Appbase = file:///D:/TestApp/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = TestApp.exe
    Calling assembly : Microsoft.Ccr.Core, Version=2.2.76.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
    ===
    LOG: This bind starts in default load context.
    LOG: No application configuration file found.
    LOG: Using host configuration file: 
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: Post-policy reference: Microsoft.Ccr.Core.resources, Version=2.2.76.0, Culture=en-US, PublicKeyToken=31bf3856ad364e35
    LOG: GAC Lookup was unsuccessful.
    LOG: Attempting download of new URL file:///D:/TestApp/Debug/en-US/Microsoft.Ccr.Core.resources.DLL.
    LOG: Attempting download of new URL file:///D:/TestApp/Debug/en-US/Microsoft.Ccr.Core.resources/Microsoft.Ccr.Core.resources.DLL.
    LOG: Attempting download of new URL file:///D:/TestApp/Debug/en-US/Microsoft.Ccr.Core.resources.EXE.
    LOG: Attempting download of new URL file:///D:/TestApp/Debug/en-US/Microsoft.Ccr.Core.resources/Microsoft.Ccr.Core.resources.EXE.
    LOG: All probing URLs attempted and failed.

    It is also sometimes sent from a LoadFrom context:

     

    *** Assembly Binder Log Entry (01/11/2010 @ 2:06:04 PM) ***
    
    The operation failed.
    Bind result: hr = 0x80070002. The system cannot find the file specified.
    
    Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable D:\TestApp\Debug\TestApp.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: User = XBN\gigs
    LOG: Where-ref bind. Location = D:\TestApp\Debug\Microsoft.Ccr.Core.resources.dll
    LOG: Appbase = file:///D:/TestApp/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = TestApp.exe
    Calling assembly : (Unknown).
    ===
    LOG: This bind starts in LoadFrom load context.
    WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
    LOG: No application configuration file found.
    LOG: Using host configuration file: 
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: Attempting download of new URL file:///D:/TestApp/Debug/Microsoft.Ccr.Core.resources.dll.
    LOG: All probing URLs attempted and failed.

    From what I can tell from the call stack, it is trying to localize its error string, but it wants to use en-US, which it doesn't have (only neutral), but has no way to fall back to neutral because it asks for en-US explicitly.

    This is very irritating because it is very hard to know what exception caused it and it never gets back to our causality, which should be able to handle it gracefully.

    When we target 3.5 it doesn't happen, but we need 4.0 for some WCF features.

    We are pretty much lost as to what is causing this. Any help is appreciated, even is we have to use an ugly workaround to fix this.

    Thanks.

     

     

     

     

    • Edited by MrGigs Tuesday, November 2, 2010 1:40 PM more info
    Monday, November 1, 2010 6:47 PM

Answers

  • Well here it is: http://msdn.microsoft.com/en-us/library/ff527268.aspx

    Beginning with the .NET Framework 4, the AssemblyResolve event is raised for satellite assemblies. This change affects an event handler that was written for an earlier version of the .NET Framework, if the handler tries to resolve all assembly load requests. Event handlers that ignore assemblies they do not recognize are not affected by this change: They return null, and normal fallback mechanisms are followed.

     

    Since our code was loaded via LoadFrom, we had our own resolver which was not updated for 4.0. The crash has been fixed by returning nullptr.


    • Marked as answer by MrGigs Wednesday, November 3, 2010 10:09 PM
    Wednesday, November 3, 2010 10:09 PM

All replies

  • Here's some more information.

    I tried reproducing the error in a small executable, but I've been unable to. When our application crashes, it is always because it tries to load Microsoft.Ccr.Core.resources.dll in a LoadFrom context. Ccr is used in an add-in, which is loaded with Assembly.LoadFrom.

    So I tried reproducing the error by having an application doing Assembly.LoadFrom("path/to/some/classlibrary.dll") and then Invoke a static method which enqueues a task that throws an exception.

    Everytime, Ccr tries to load Microsoft.Ccr.Core.resources.dll and fails, but does not crash, because the binds starts in the default context, even if Microsoft.Ccr.Core.dll's bind starts in a LoadFrom context.

    I really don't know why our application ends up with trying to load resources.dll in a LoadFrom context, yet when I do a simple test case, it doesn't. Anyonw has any ideas?

    Here's a call stack of the crash, I guess (since I couldn't step into the stack) throwOnFileNotFound is true, which is very sad in our case.

    mscorlib.dll!System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(string name, System.Globalization.CultureInfo culture, System.Version version, bool throwOnFileNotFound, ref System.Threading.StackCrawlMark stackMark) + 0x97 bytes	
    mscorlib.dll!System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(System.Globalization.CultureInfo lookForCulture, ref System.Threading.StackCrawlMark stackMark) + 0xda bytes	
    mscorlib.dll!System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(System.Globalization.CultureInfo culture, System.Collections.Generic.Dictionary<string,System.Resources.ResourceSet> localResourceSets, bool tryParents, bool createIfNotExists, ref System.Threading.StackCrawlMark stackMark) + 0x25c bytes	
    mscorlib.dll!System.Resources.ResourceManager.InternalGetResourceSet(System.Globalization.CultureInfo requestedCulture, bool createIfNotExists, bool tryParents, ref System.Threading.StackCrawlMark stackMark) + 0x231 bytes	
    mscorlib.dll!System.Resources.ResourceManager.InternalGetResourceSet(System.Globalization.CultureInfo culture, bool createIfNotExists, bool tryParents) + 0x31 bytes	
    mscorlib.dll!System.Resources.ResourceManager.GetString(string name, System.Globalization.CultureInfo culture) + 0x12a bytes	
    Microsoft.Ccr.Core.dll!Microsoft.Ccr.Core.Resource1.HandleExceptionLog.get() + 0x34 bytes	
    Microsoft.Ccr.Core.dll!Microsoft.Ccr.Core.TaskExecutionWorker.HandleException(Microsoft.Ccr.Core.ITask currentTask, System.Exception e) + 0x3b bytes	
    Microsoft.Ccr.Core.dll!Microsoft.Ccr.Core.TaskExecutionWorker.ExecutionLoop() + 0x1b3 bytes	
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x63 bytes	
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool ignoreSyncCtx) + 0xb0 bytes	
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x2c bytes	
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes	

    Wednesday, November 3, 2010 7:51 PM
  • Well here it is: http://msdn.microsoft.com/en-us/library/ff527268.aspx

    Beginning with the .NET Framework 4, the AssemblyResolve event is raised for satellite assemblies. This change affects an event handler that was written for an earlier version of the .NET Framework, if the handler tries to resolve all assembly load requests. Event handlers that ignore assemblies they do not recognize are not affected by this change: They return null, and normal fallback mechanisms are followed.

     

    Since our code was loaded via LoadFrom, we had our own resolver which was not updated for 4.0. The crash has been fixed by returning nullptr.


    • Marked as answer by MrGigs Wednesday, November 3, 2010 10:09 PM
    Wednesday, November 3, 2010 10:09 PM