title: LoadLibrary 193
body: <p>I am creating a C++/CLI dll that will be loaded into a legacy c++ application. The legacy application does this with a traditional call to LoadLibrary. Both the application and the C++/CLI dll are compiled in 64 bit mode.</p>
  
  <p>When the LoadLibrary call happens, it fails with error 193. This usually means that some non-64bit component is trying to load. When I look at the dll load output in visual studio 2010, I see the the failure is occurring when mscoree.dll is being loaded (to be exact, I see my dll loaded, then mscoree loaded, then mscoree unloaded, then my dll unloaded, then the error returned). Specifically C:\Windows\System32\mscoree.dll is being loaded, when I examine this mscoree.dll, I find that it is targeting I386. </p>
  
  <p>How can I ensure that my application will link against the correct mscoree.dll? I understand this could be done with a manifest, but I can't find any good information about setting one up. The ideal solution would allow compilation in 32bit or 64bit mode and target the correct mscoree.dll. </p>
  
  <p>As a side note, I found an mscoree.dll in a side-by-side folder that I verified is 64bit mode and copied it into my application directory with the hopes that it would pick up that one first. This didnt work and the C:\Windows\System32 version was still loaded.</p>
  
  <p>Thanks,</p>
  
  <p>Max</p>
  
  <h3>Output of CorFlags.exe on the C++/CLI dll</h3>
  
  <pre><code>Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
  Copyright (c) Microsoft Corporation.  All rights reserved.
  
  Version   : v4.0.30319
  CLR Header: 2.5
  PE        : PE32+
  CorFlags  : 16
  ILONLY    : 0
  32BIT     : 0
  Signed    : 0
  </code></pre>
  
  <h3>Output of pedump.exe on C:\System32\mscoree.dll</h3>
  
  <pre><code>PS C:\Windows\System32&gt; pedump.exe .\mscoree.dll
  Dump of file .\MSCOREE.DLL
  
  File Header
    Machine:                      014C (I386)
    Number of Sections:           0004
    TimeDateStamp:                4B90752B -&gt; Thu Mar 04 22:06:19 2010
    PointerToSymbolTable:         00000000
    NumberOfSymbols:              00000000
    SizeOfOptionalHeader:         00E0
    Characteristics:              2102
      EXECUTABLE_IMAGE
      32BIT_MACHINE
      DLL
  ...
  </code></pre>
  
  <p>(pedump goes on from here to describe imports and exports but thats not important here)</p>
  
  <h3>Extended loading information</h3>
  
  <p>This is the full output from failed load.</p>
  
  <p>Note: The C++/CLI dll is called DsfClr.dll<br/>
  the output was obtained by running gflags.exe -i [exename] +sls and examining the results in a debugger</p>
  
  <p><a href="http://pastebin.com/FyumUiMN" rel="noreferrer">http://pastebin.com/FyumUiMN</a></p>
  
  <h3>UPDATE:</h3>
  
  <p>Using a tip posted in a below comment by Reuben, I was able to determine that mscoree.dll is indeed targeting AMD64, but pedump is providing invalid information because it is being run in WOW64. That being said I still cannot load this library, if anyone has any suggestions they would be greatly appreciated. <br/>
  One more thing I have tried: I made a new C# application and referenced the C++/CLI dll, then, in the main() function, I instantiated a class in the C++/CLI dll. This caused an access violation exception before the main() function is called. When I remove the instantiation, the main function runs fine. My guess is that the instantiation is causing a delay load of my C++/CLI assembly, which causes the same load error I was seeing from the native assembly.</p>