none
Unmanaged C++ calls managed c++ : it crashes on windows xp RRS feed

  • Question

  • Hi,

    if I call a c++ function in a managed DLL from an unmanaged dll or exe, it crashes on Windows xp, but it runs fine on Windows 7.

    On Windows XP I get an error message:

    Die Anwendung konnte nicht richtig initialisiert werden (0xc0000135).

    The Code is very simple. The Header file:

    #pragma once
    
    
    #ifdef _CLR_DLL_
    #define _EXPORT_ __declspec( dllexport )
    #else
    #define _EXPORT_ __declspec( dllimport )
    #endif
    
    extern "C"
    {
    int _EXPORT_ func(int i);
    }
    
    

    The c++ file:

    #include "stdafx.h"
    
    #include "ClrDll.h"
    
    int func(int i)
    {
    	return i;
    }
    
    

    It is compiled with the /clr switch.

    The caller is a simple C++ program, it calls this function.

    I use Visual Studio 2010, and .NET framework 4.0

    It works fine on windows 7.

    It is very important for me this project to run on Windows XP.

    I can send a whole project, it is very small.

    Is there a wrong setting in VIsual Studio, or it is a bug in Windows XP? Can I make a workaround?

    Monday, April 11, 2011 7:45 PM

Answers

  • Hi,

    I had the same problem and solved it.

    For me it worked, that you have to load the managed C++/CLI DLL in a lazy mode: so either by AfxLoadLibrary or insert the "XYZ.dll" in the "Linker\Input\Delayd loaded DLLs" in Visual Studio.

    That's it.

    If it is still there, you have to check if all your needed DLLs (or symbols) are present: do this via "DependencyWalker"

    • Marked as answer by eryang Monday, April 25, 2011 9:41 AM
    Wednesday, April 13, 2011 5:54 AM

All replies

  • The error code 0xc0000135 indicates some files cannot be found, did you install .NET 4.0 on the xp machine?
    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 12, 2011 3:56 AM
  • Hi,

    i´ve  exact the same problem as Laca22 describes. The only difference is the error code, in my case it is 0xc0000005.

    I´ve to use a .NET Assembly (target .NET framework 4.0) in unmanaged C++ Code.

    For test purposes i built a dll with the target framework 3.5. I also changed my target framework in my C Wrapper/API project,

    then i built the a C++ Test App without clr support. The result is that the C++ Test App works fine.

    But this is not the solution for me because i need the Assemblies in .NET 4.0. 

    So hopefully someone can help me...

     

    Tuesday, April 12, 2011 4:27 PM
  • Hi,

    I had the same problem and solved it.

    For me it worked, that you have to load the managed C++/CLI DLL in a lazy mode: so either by AfxLoadLibrary or insert the "XYZ.dll" in the "Linker\Input\Delayd loaded DLLs" in Visual Studio.

    That's it.

    If it is still there, you have to check if all your needed DLLs (or symbols) are present: do this via "DependencyWalker"

    • Marked as answer by eryang Monday, April 25, 2011 9:41 AM
    Wednesday, April 13, 2011 5:54 AM
  • Thank´s a lot it works! I inserted the "XYZ.dll" into the linker properties.

    But, it would be very interesting to find out the reason for this behaviour!

    Why does it run without problems on Windows 7 and not on Windows XP, or is .NET framework the matter???

    I´ve no clue. 

    Wednesday, April 13, 2011 8:23 AM
  •  

    Glad to hear that TZ's workaround can help, by the way, you can submit this issue to Microsoft Connect feedback portal http://connect.microsoft.com, Microsoft engineers will evaluate them seriously, thanks. If this issue is urgent, please contact support at http://support.microsoft.com.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, April 14, 2011 7:08 AM
  • I solved this by removing "/clr" setting from the compile options.

    I suppose it's related to .Net Framework

    Tuesday, June 30, 2015 7:06 AM