user7101086 user7101086 - 1 month ago 13
C++ Question

vc++ 64-bit dll incorrect parameter sizes

I'm just trying to create a simple DLL, with a single exported function using VC++ (VS2015) and call this function from a Win32 application. I'm testing building both the dll and exe in x86 and x64 build configurations.

Everything works as expected when compiled as x86, however when I compile as x64 and step into the dll function call, the function parameters are all garbage data.

I have the function defined as follows in a header file that is included in both the DLL and the application project:

#ifdef CPPDLL_EXPORTS
#define CPPDLL_API __declspec(dllexport)
#else
#define CPPDLL_API __declspec(dllimport)
#endif

extern "C" CPPDLL_API void __cdecl CallDll(LONG64 value, bool trueOrFalse);


This how the function is implemented in the DLL:

extern "C" CPPDLL_API void __cdecl CallDll(LONG64 value, bool trueOrFalse)
{
return;
}


This is how the function is called in the application:

CallDll(12345, true);


Changing the parameter from LONG64 to something like int makes no difference. I have no doubt it's a silly mistake, but I've been pulling my hair out trying to figure it out.

Entire sample project:
https://1drv.ms/u/s!AiwVLuwdzWP_zZ0tSDA15ZqL9QgKXQ

Answer

I think you are only having an issue with debugging. I changed the dll function this way to have it display the passed parameter:

extern "C" CPPDLL_API   void  __cdecl CallDll(LONG64 value, bool trueOrFalse)
{
    std::wstring s = std::to_wstring(value);
    MessageBox(0, s.c_str(), L"Hello World", 0);
    return;
}

The message box shows the correct value "12345" in both 32bit builds as well as 64bit builds.

Then I put two break points at the beginning of the function like shown here:

enter image description here

What I noticed is that when I break at the first break point, the values shown for the parameters are wrong and look random when compiled for 64bit but are correct when compiled for 32bit. However, when I break at the second break point, the values are correct in both environments.

So, this seems to be a problem with the debugger. The first breakpoint at the exact beginning of the function seems to be hit too early for the debugger to be able to show the correct values.