2

Following the solution proposed in a similar SO question, I want to load a fairly complex dll file in a C++ CLI app (or C# for that matter of fact). The target architecture is consistently set to 64 bits.

The .dll to be consumed in this app is generated in another project and it is written in C++ CLI using native C++ libraries (e.g. Ogre, Boost, etc.) and depends on its own dlls (all of them have been compiled for 64 bit platforms). These dependency dlls are copied in the output folder of my application, together with the pesky .dll that uses them.

However, when reaching this line:

Assembly^ SampleAssembly;
SampleAssembly = Assembly::LoadFrom( "E:\\x64\\Debug\\OgreWrapper.dll" );

the output console reads:

'DumbTestCLR.exe': Loaded 'E:\x64\Debug\OgreWrapper.dll', Symbols loaded.
'DumbTestCLR.exe': Unloaded 'E:\x64\Debug\OgreWrapper.dll'

and some fatal uncaught exceptions are thrown:

First-chance exception at 0x000007fefe32cacd (KernelBase.dll) in DumbTestCLR.exe: Microsoft C++ exception: EEFileLoadException * __ptr64 at memory location 0x0016d588..
First-chance exception at 0x77cace3b (ntdll.dll) in DumbTestCLR.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x77cace3b (ntdll.dll) in DumbTestCLR.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x77cace3b (ntdll.dll) in DumbTestCLR.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

Since none of the suggestions given here apply (i.e. it's not because of bitness conflicts between the app and the dll), what could be the source of the problem? I suspect the dll cannot load other (native) dlls and hence the crash, but how to check which dlls cause the problem, if this might be the case?

sorry for the long question and for the, perhaps, dumb question..

Community
  • 1
  • 1
teodron
  • 1,410
  • 1
  • 20
  • 41
  • Sounds to me that your OgreWrapper.dll is a native dll and should be handled with pinvoke instead. – Totonga Jul 23 '12 at 13:15
  • 1
    http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx – Hans Passant Jul 23 '12 at 13:40
  • I compiled it with the `Common Language Runtime Support (/clr)` flag. Can it be that this dll still is a native one, and not a mixed one? I've heard people saying that it should be a mixed one, as it is the way they wrap other C++ libraries and make use of their functionality from within C# applications.. – teodron Jul 23 '12 at 13:45
  • 1
    Are you sure it isn't a native dll? Have you tried referencing it in a C# project? [Check this answer out](http://stackoverflow.com/a/1366517/1469494), might help you determine the type of dll you're dealing with. – Shahin Dohan Jul 23 '12 at 18:19
  • Thanks, checked it now and it was confirmed( Version : v4.0.30319 CLR Header: 2.5 - PE : PE32+ - CorFlags : 16 - ILONLY : 0 - 32BIT : 0 - Signed : 0) – teodron Jul 24 '12 at 08:27
  • It's [clearly](http://blogs.msdn.com/b/slessard/archive/2010/04/09/types-of-managed-code-assemblies.aspx) a 64-bit only mixed-mode assembly based on that data. I would at this point just try to remove chunks of code from the OgreWrapper.dll until I figure out the source of the problem, my guess is it's coming from the pure native C++ that it references. Have you tried instantiating the dll normally and not doing it the Assembly::LoadFrom way? – Shahin Dohan Jul 24 '12 at 09:15
  • Yes, have tried that as well and the application fails without even reaching a breakpoint. Normal C++ can consume the dlls OgreWrapper.dll depends on. So it must be something else. Both native dlls and the wrapper are 64 bit consistent, and the native ones can be used by native c++ apps. BUT when compiling with CLR turned on, the C++ managed up fails (when trying to verify the validity of the native dll). Could this be a compile flags configuration issue? BTW, thanks a lot for those suggestions, they were tremendously helpful.. – teodron Jul 24 '12 at 09:35
  • If you're linking the native boost libraries statically then try to link them dynamically instead, Apparently this causes dependency problems according to the last comment in [this](http://stackoverflow.com/q/8092869/1469494) question. Other than that I'm out of ideas. – Shahin Dohan Jul 25 '12 at 21:22

1 Answers1

2

Use Dependency Walker to see if the dll's dependencies are all there.

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • Yes, that's what I did in the first place. Those dependencies are all there, nothing is missing, except for two bogus DLLS (`IESHIMS.dll` and `GPSVC.dll` - both being irrelevant for my application - also, Google results point out that the DependencyWalker executable won't be able to find anything - it can't deal with manifests). But the required native dlls are there.. – teodron Jul 23 '12 at 13:33
  • 1
    You can debug it as mixed, set the sebugger to catch first chance exceptions, and see where it originates – Yochai Timmer Jul 23 '12 at 16:43