locked
C++/CLR mixed assembly fails to load from LoadLibrary GetLastError 1114 RRS feed

  • Question

  • Hello,

    I am trying to create a mixed assembly that can be loaded by a legacy application.  I am building targetting the 3.5 framework.  When the legacy app loads the mixed assembly, the LoadLibrary call fails and returns a 1114 error.  I first stumbled upon a SxS error where the assembly manifest was pointing to pre-sp1 CRT dlls, but was able to fix that by following directions here: http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions

    I then followed the directions here: http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx to get the load library trace information to output into windbg.  I have set a breakpoint for the load module event for my module, and I can see the failure output from loader snaps.  The loader correctly loads up the VC9 CRT via SxS and then starts to resolve the dependency graph.  I'm going to list all of the times loader snaps writes "DLL being requested" which seems to be its recursive dll resolution process:

    1. mscoree (which is finds in c:\windows\system32 which is the 4.0 framework version)
    2. advapi
    3. shlwapi
    4. mscorwrks (strangely reported as: [fc4,1210]   DLL being requested: "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll")
    5. shlwapi (again)
    6. mscorlib (reported as: [fc4,1210]   DLL being requested: "c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll")
    7. mscoree (again)
    8. ole32.dll (reported as: [fc4,1210]   DLL being requested: "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\ole32.dll" -- it can't resolve this and reports: ÓLDR: LdrpCheckForLoadedDll - Unable To Locate C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\ole32.dll: 0xc0000135
    9. ole32 (again?)
    10. mscorjit.dll (reported as DLL being requested: "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\MSCORJIT.DLL")
    11. It then runs the init routine for mscorjit and loads some more
    12. kernel32
    13. oleaut32.dll
    14. Then it states: LDR: LdrGetDllHandle, searching for ole32.dll from 
    15. Then it states: 
    16. [fc4,1210] LDR: DLL_PROCESS_ATTACH for dll "C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6F74963E\msvcm90.dll" (InitRoutine: 7842024A) failed
    17. LDR: Unloading ole32.dl because either its init routine or one of its static imports failed; status = 0xc0000142LDR: Derefcount C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6F74963E\msvcm90.dll (1)
    18. LDR: Derefcount mscoree.dll (8)
    19. LDR: Derefcount mscoree.dll (7)

    Then it fires the unload event for my module and returns 1114 from GetLastError after the LoadLibrary call returns to my application.  

    So I am really lost.

    1) Why are so many v1.1 framework DLLs being loaded?  I have the target runtime set at 2.0 in the project properties.

    2) oleaut32 and ole32 are both reported as already loaded (via windbg lm) before I ever call the LoadLibrary function (so why would it not be able to resolve this inside LoadLibrary)

    I double checked the manifest with ildasm and see that its trying to bind against the 2.0 corelib:

    .assembly extern mscorlib

    {

      .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..

      .hash = (90 A1 9B A4 91 AD ED A2 C5 B6 35 38 A0 70 E2 24   // ..........58.p.$

               6F E8 63 E1 )                                     // o.c.

      .ver 2:0:0:0

    }

    Any thoughts?  I've been banging my head against this all weekend.  I think I'm just going to do it as an out of process COM component instead.  But this _should_ work...

    Sunday, July 24, 2011 9:34 PM

Answers

  • Well I got to the bottom of this after many winding debugging paths...

    The problem was simple, and believe me I have inflicted the appropriate number of lashings on myself-- the host process (e.g. MYAPP.exe) which is a native app -- no other .NET stuff involved for _some_ reason had a MYAPP.exe.config that was pointing it to the v1.1 runtime.  Thus, _of course_ it was binding against the v1.1 runtime.

    It's still very strange that it resulting in a binding problem with oleaut32 and caused LoadLibrary to fail instead of completing LoadLibrary successfully, but subsequently failing on a fusion problem trying to bring in v2.0 assemblies (as I would've expected).  But none the less by changing the Myapp.exe.config to point to the v2.0 runtime -- all is well.

    Another curious tidbit -- I discovered this because I said "screw it ill just do a COM out-of-process activation and take the marshalling hit".  Then before I got too far I decided to go ahead and try an in process activation just for giggles -- expecting to run into the same problem because an in process activation still would require mscoree etc and we'd be in a similar loader issue.  The COM one didn't fail in LoadLibrary.  The com interop stuff loaded and I got fusion logs which showed the v1.1 failing to bring in the v2.0 assemblies.  It's interesting to me that when loaded via the mixed assembly it failed in the loader whereas with COM it loaded correctly.  I realize that they are different dependency chains and surely that explains it -- just curious.

    So case closed.

    • Marked as answer by Paul Zhou Tuesday, August 2, 2011 6:57 AM
    Monday, July 25, 2011 4:34 AM

All replies

  • Well I got to the bottom of this after many winding debugging paths...

    The problem was simple, and believe me I have inflicted the appropriate number of lashings on myself-- the host process (e.g. MYAPP.exe) which is a native app -- no other .NET stuff involved for _some_ reason had a MYAPP.exe.config that was pointing it to the v1.1 runtime.  Thus, _of course_ it was binding against the v1.1 runtime.

    It's still very strange that it resulting in a binding problem with oleaut32 and caused LoadLibrary to fail instead of completing LoadLibrary successfully, but subsequently failing on a fusion problem trying to bring in v2.0 assemblies (as I would've expected).  But none the less by changing the Myapp.exe.config to point to the v2.0 runtime -- all is well.

    Another curious tidbit -- I discovered this because I said "screw it ill just do a COM out-of-process activation and take the marshalling hit".  Then before I got too far I decided to go ahead and try an in process activation just for giggles -- expecting to run into the same problem because an in process activation still would require mscoree etc and we'd be in a similar loader issue.  The COM one didn't fail in LoadLibrary.  The com interop stuff loaded and I got fusion logs which showed the v1.1 failing to bring in the v2.0 assemblies.  It's interesting to me that when loaded via the mixed assembly it failed in the loader whereas with COM it loaded correctly.  I realize that they are different dependency chains and surely that explains it -- just curious.

    So case closed.

    • Marked as answer by Paul Zhou Tuesday, August 2, 2011 6:57 AM
    Monday, July 25, 2011 4:34 AM
  • From .NET Framework V2.0 to V3.5, the same runtime --CLR 2.0 is used, so different version of assemblies may be loaded in one process.
    Hard hard work, Day day up!
    Wednesday, July 27, 2011 7:50 AM