C++ unmanaged DLL loaded from a C# .exe

C++ unmanaged DLL loaded from a C# .exe

• soconne

  I am also having a similar issue with unmanaged dll's on Win XP Pro x64. I have an managed application which is calling an simple test function located within an unmanaged dll. I'm thinking that the issue is with the C++ compiler not building the dll as an x64. What should the settings be, or should Visual Studio automatically setup the project to be built for the x64 platform when I create a new one

  My unmanaged function looks like this:

  extern "C" _declspec(dllexport)int _stdcall sum(int x, int y)

  {

  return x + y;

  }

  and in my managed C# application, I'm declaring it as

  [System.Security.SuppressUnmanagedCodeSecurity]

  [DllImport("Library.dll")]

  public static extern Int32 sum(Int32 x, Int32 y);

  Every time I make a call to sum, I recieve an BadImageException. I moved this project over to my x86 machine, rebuilt it, and it ran fine. I'm not finding much info on the net about this.

  - Bill

  
  
  

• Roger Jennings

  Given that you're seeing these problems it is highly likely that the Fortran dll that you're loading is a 32-bit dll. These will not load in a 64-bit proccess.

  I go into great detail on this here:

  http://blogs.msdn.com/joshwil/archive/2004/03/11/88280.aspx

  But generally if you have a dependence on a bit-specific component like this the recommendation is to use the /platform:<X> switch to lock down the bitness of your managed assembly and force it to run correctly on both 32-bit and 64-bit operating systems. It sounds like /platform:x86 is the right move in this case.

  -josh

  http://blogs.msdn.com/joshwil/

  
  

• MINA7343

  1) VS 2005 builds managed DLLs .. If you are trying to use C++ on VS 2005, refer to the following link to build an 'managed' C++ DLL(which I guess is not the case..):

  http://msdn2.microsoft.com/en-us/library/9yb4317s.aspx

  2) If you are using VS 6 to build the unmanaged DLL, you may want to use the PSDK - http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=58670&SiteID=1

  (ignore the porting stuff talked about in this link - because you are building all from scratch..)

  
  
  

• Kamen

  Ok I finally figured out the settings for a x64 mixed application solution (1 Managed, 1 non managed)...

  1. Open Configuration Manager
  2. Select the unmanaged projects platform drop down list.
  3. Select new from the drop down list.
  4. Choose x64 from the 'New Platform' list.
  5. Set 'Copy Settings From' to Win32.
  6. Make sure 'Create new solution platforms' is not checked.
  7. Click Ok.
  8. Select the managed projects platform drop down list.
  9. Select new from the drop down list.
  10. Choose x64 from the 'New Platform' list.
  11. Set 'Copy Settings From' to 'Any CPU'.
  12. Make sure 'Create new solution platforms' is not checked.
  13. Click OK
  14. Now Select The 'Active solution platform' drop down list.
  15. Select new from the drop down list.
  16. Choose x64 from the 'New Platform' list.
  17. Set 'Copy Settings From' to 'Empty'.
  18. This time we will check 'Create new solution platforms '

  Finally setup both of the projects to output to the same directory, and you should be able to compile and run your mixed x64 application from VS 2005.

  
  
  

• XNA Rockstar

  This same code works fine when compiled on a 32 bit machine, but when I compile it to run on an AMD64 running XP64 I get an eception that says it might be a bug in the CLR. Has anyone run across this before

  Any help is appreciated, thanks in advance.

  
  
  

• Rod Yager

  I'm not really porting, I built both from scratch on the x64 machine. I think the issue is with the Visual Studio 2005 settings. The only code I've added to the two projects, I posted above.  Its just a small test application right now. From what I see, that code looks x64 compliant. The WP_Portx64.pdf seems to have the VS 2005 settings I am looking for as far as my unmanged dll is concerned. Unfortuanately the machines at work, so I wont be able to test it until tommorrow.

  Do I have to specifically change any settings in Visual Studio for the managed application too

   

  Basically, I'm looking to build a x64 C# Manged Application (For the GUI), then there will be an x64 unmanaged dll that will be written in C for some low level driver calls...

  
  
  

• Norbert.Bender

  I got the same error when trying to use a dll sold by NIST under the product name RefProp. I am pretty sure the dll was written in Fortran. I put the dll in a vs2005 c++ wrapper and called it from c#. I got the exact same error on my amd64 machine running xp64 bit version. When I ran it on my Dell laptop there were no problems. Fortunately, the 64 bit platform is not my target machine so I will probably not persue this problem.
  
  

• Erik_Olofsson

  Even I am facing same kindof problem.

  I have 32 Bit application running on a 64 bit OS machine.

  And I am loading a unmanaged C++ dll(Not a COM dll) in a 32 bit application.

  When I register my 32 bit COM application in a 64 bit machine It throws me an excpetion.

  My query is Will 64 bit OS support 32 bit unmanaged dll when it is loaded from a 32 bit application

  else DO I need to recompile my 32 bit unmanaged dll to 64 bit

  Thanks,

  king

  
  

• Yogesh Saxena Bareilly Ghaziabad

  Bill,

  Compiler your managed application as 'x86'. It will work.

  best

  sriram

  
  
  

• SandeepLohani

  @ sriram

  I can't build the managed code as x64 I have the source for the unmanaged dll, I was hoping to compile them both as x64... otherwise running the application as an x86 application defeats the purpose of us targetting it on an x64 machine. The application I am designing is memory intensive and will need to take advantage of the memory benefits the x64 platform has to offer. This is my first time working with x64 machines, so I'm still learning my way around. Thanks.

  
  
  

• Ke Sun

  Bill

  If you want to take full advantage of x64, you will have to port your unmanaged app to x64 (this may involve change is your program, especially where pointers are used)...

  You might be interested in the following article, especially in the section "Porting applications comprised completely of unmanaged code"

  http://msdn.microsoft.com/isv/technology/64bitwindows/productstrategy/default.aspx

  some good reading on porting is at the following links

  www.tmurgent.com/WhitePapers/WP_Portx64.pdf

  http://www.devx.com/amd/Article/31825

  Hope this helps

  sriram

  
  
  

• chunket

  Its not a COM DLL. Just a very basic .Net DLL that I created.

  I havn't done much with 64-bit programming and am trying to migrate an application from 32-64. This application has several occurances where it does this (c# exe calling a c++ dll) and when I compile it on the 64 bit (with a few changes) everything compiles, yet when I try to run the program, I get the error below.

  I tried to recreate the problem using the most basic C# exe and C++ DLL I could create and still got the same error. Either the problem is with my compiler setting (very possible) or there is a problem with doing this in Win64.

  This is the error in its entirety:

  "The runtime has encountered a fatal error. The address of the error was at 0x7f570c2b, on thread 0xa18. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack."

  Thanks for your time,

  -Ray

  
  
  

• Steve Severance

  Can you tell us a tad more about the native DLL

  I assume you've compiled it for the proper 64-bit platform you are trying to run on. Anything special about it Does it pass pointers, etc across the managed/native boundary

  From what you've descibed of the crash, it sounds like a bad pinvoke signature could be a pretty good candidate for the issue.

  -scott

  
  
  

• Manolis

  Can you send more details on the exeption. Is the unmanaged DLL a COM DLL

  
  
  
• C++ unmanaged DLL loaded from a C# .exe