none
C# exception thrown from a C++ managed dll - EEFileLoadException * __ptr64 RRS feed

  • Question

  • I am receiving this error from within a normal C# console program that's consuming a DLL produced as the build output of a C++ CLI project. There I have a simple DumbThing public ref class with a static method. I'd like to simply call that function or at least instantiate one tiny DumbThing object and see that C# can call code that it gets from a C++ CLI born DLL, but it's not working as it throws an error that puzzles me even more:

    First-chance exception at 0x000007fefd2acacd (KernelBase.dll) in DumbTest.exe: Microsoft C++ exception: EEFileLoadException * __ptr64 at memory location 0x007fc228..

    A colleague pointed out to me that it might be a compile time issue (some options), but I don't have any clues what could cause it. Could anyone please provide some starting point hints?


    Imagination is perpendicular to reality.

    • Moved by Rohit.Sharma Monday, July 23, 2012 4:16 AM (From:BizTalk Server General)
    • Moved by Mike FengModerator Tuesday, July 24, 2012 1:49 AM CLR (From:.NET Base Class Library)
    Friday, July 20, 2012 6:18 PM

Answers

All replies

  • repost this in appropriate forum

    Shashi


    Friday, July 20, 2012 7:14 PM
  • Hi Teodor,

    Welcome to the MSDN Forum.

    How about this thread: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/57f661b5-65c4-42ca-a4eb-ecb223fbd76e 

    Somehow the <DEFAULT> value for structure alignment was being set to 1.
    In the GUI projects settings panel the alignment was set to <DEFAULT> but the vcproj file was set to 1.
    I don't know where/why this setting was set to that value nor why it was working as my default value. but this solved the issue.
    Thanks for all the help in tracking this down!

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, July 23, 2012 9:57 AM
    Moderator
  • Actually this thread should belong to Common Language Runtime forum.

    Are you experiencing this issue in 64 bit machine? If yes, then I think you have built your C# application in Any CPU mode or x64 mode whereas the C++/CLI app could be a x86 dll.

    So, Change the Target Platform of C# application to x86 and then try running the application. You can change the target platform in Build Page of Project properties.

    I hope this helps.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Monday, July 23, 2012 10:17 AM
  • Thank you and everyone else for moving this thread and responding with suggestions. So far, it seems it's not a "bitness" issue (the generated dll and C# application are both 64 bit binaries and recognize IntPtr.Size as being 8). Also, the configurations regarding the target build are everywhere set to x64. I tried writing a simpler solution where the C++ CLI project didn't make use of any native libraries (in my scenario, I'm using a more cumbersome 3D rendering engine library collection - the famous Ogre) and I'm wrapping this (due to client requirements, no further logical explanations here) in a C++ CLI generated dll for C# runtime support. Those dll's are also 64 bit and link within the C++ CLI wrapper dll successfully (if this was not the case, then my project shouldn't have been able to produce a .dll after the build phase, should it?!). Now, I wrote a consumer in C++ CLI and this one also fails to load the wrapper dll. 

    The unwanted behaviour is accompanied by another odd message found int he output console: Loaded "Wrapper.dll", symbols loaded and, immediately on the following line, this one: Unloaded "Wrapper.dll". Then the original tray of hermetic exceptions:

    First-chance exception at 0x000007fefe32cacd (KernelBase.dll) in DumbTestCLR.exe: Microsoft C++ exception: EEFileLoadException * __ptr64 at memory location 0x0029be48..
    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 0x77cd11b8 (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.

    This boils down to one last rational question: how to check whether that darn Wrapper.dll is consistent and it can also load its dependencies when just using one functionality irrelevant class that it contains causes everything to crash without a moderately intuitive clue? I tried dependency walker as a tool to check dependencies, they don't seem to be the issue (I repeat, the dlls this wrapper uses at runtime are also 64 bit and don't conflict with anything when my library wrapper is generated). 

    Thanks!


    Imagination is perpendicular to reality.

    Monday, July 23, 2012 11:24 AM
  • Hi Teodor,

    Based on your further clarification, it seems that there is something wrong in the wrapper.dll. As the message shows, when it try to load the wrapper.dll, it indicates an exception, so it unload this dll.

    To isolate this issue, please try to consume this dll in a C++ project.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, July 24, 2012 2:40 AM
    Moderator
  • Hello Mike,

    Thanks for the suggestion. I already tried that after the C# application failed to load it an throw a more relevant exception. I then resorted to using gflags to enable loader snaps and observed that the wrapper.dll was found and almost accepted. But when the output console reached the line where it was marked as unloaded, it also provided a non-null loader status for the ldrpfindormapdll step. Since this DLL uses other runtime libraries (also supposedly built and reported as being 64 bit), I used the dependency walker utility to check if they are reachable, and everything was, seemingly, in order. Is there, ultimately, a method to test the bitness of a dll? I generated those dlls myself, building them from native C++ sources with the aid of the VS100 64 bit C++ compiler.

    Moreover, I used CorFlags.exe to check the wrapper dll and it is indeed a 64 bit one:

    Version   : v4.0.30319
    CLR Header: 2.5
    PE        : PE32+
    CorFlags  : 16
    ILONLY    : 0
    32BIT     : 0
    Signed    : 0

    Kind regards,

    T.C.


    Imagination is perpendicular to reality.



    Tuesday, July 24, 2012 8:02 AM
  • Hi Teodor,

    Please try this tools: http://msdn.microsoft.com/en-us/library/c1h23y6c.aspx 

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Teodor Cioaca Tuesday, July 24, 2012 2:15 PM
    Tuesday, July 24, 2012 8:34 AM
    Moderator
  • Thanks, I forgot about dumpbin, it also confirms that the required dlls are 64 bit. To drill down for the real problem, I created a native C++ program to consume one of the native dlls that my wrapper.dll requires. When compiled with the /clr flag, it fails outputting: 

    The program '[2828] OgreTest.exe: Native' has exited with code -1073741701 (0xc000007b).

    My wrapper was built and requires static linking to boost (for the threading system). I've found out that this is the problem... and it is unclear whether CLR and boost will work eventually. Thanks for the entire support and patience, I'll perhaps start another thread for further issues.


    Imagination is perpendicular to reality.


    Tuesday, July 24, 2012 2:12 PM