12

I have recently been tinkering around with C# to C++ interop, in particularly setting up a callback function which is called from the C++ DLL.

namespace TomCSharpDLLImport
{
    class Program
    {
        public delegate void TomDelegate(int a, int b);

        [DllImport("TomDllNative.dll", CallingConvention = CallingConvention.Cdecl)]
        public static extern void GetData();

        [DllImport("TomDllNative.dll", CallingConvention = CallingConvention.Cdecl)]
        public static extern void SetCallback(TomDelegate aCallback);

        static void Main(string[] args)
        {
            TomDelegate lTD = new TomDelegate(Program.TomCallback);

            SetCallback(lTD); //Sets up the callback

            int thread = Thread.CurrentThread.ManagedThreadId;

            GetData(); //This calls the callback in unmanaged code

            while (true) ;
        }

        //Callback function which is called from the unmanaged code
        public static void TomCallback(int a, int b)
        {
            Console.WriteLine("A: {0} B: {1}", a, b);
            int thread = Thread.CurrentThread.ManagedThreadId;
        }
    }
}

The question I have is that, when the program control comes into the TomCallback function, I was expecting it to then hit the while(true) loop in Main. However instead the program just exits. I can't quite get my head round the behaviour, part of me imagines this is as expected but part of me would have expected it to continue on in main.

What I was expecting...

  1. The GetData() function is called
  2. The GetData function calls the callback
  3. The callback function returns back to GetData
  4. GetData returns back to main()

However this is not quite right.

Would someone be kind enough to explain what happens.

In order to save space I haven't posted the unmanaged code, however if it is needed i'm happy to post

Edit: I turned on Unmanaged debugging (totally forgot to do this) and now I see the crash..

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

Native code as this is where crash is

#include "stdafx.h"
typedef void (*callback_function)(int, int);

extern "C" __declspec(dllexport) void SetCallback(callback_function aCallback);
extern "C" __declspec(dllexport) void GetData();

callback_function gCBF;

__declspec(dllexport) void SetCallback(callback_function aCallback)
{
    gCBF = aCallback;
}

__declspec(dllexport) void GetData()
{
    gCBF(1, 2);
}
jszigeti
  • 373
  • 4
  • 11
TomP89
  • 1,420
  • 3
  • 11
  • 29

2 Answers2

15

You must convert your managed callback to the Native Function Pointer (IntPtr in C#) by using the

IntPtr Marshal.GetFunctionPointerForDelegate(Delegate d)

method.

Your usage of SetCallback() with System.Delegate as an argument is wrong.

Make it

SetCallback(Marshal.GetFunctionPointerForDelegate(lTD));

and redeclare SetCallback as

/// StdCall is crucial here
[DllImport("TomDllNative.dll", CallingConvention = CallingConvention.StdCall)]
public static extern void SetCallback(IntPtr aCallback);
Viktor Latypov
  • 14,289
  • 3
  • 40
  • 55
  • Hi Viktor, Thanks for the response. I made the changes as you suggested, but it is still exhibiting exactly the same behaviour. – TomP89 May 31 '12 at 22:00
  • The program "exits" - this means a crash. Would you be so kind to show the crash dump ? This can be done in Event Viewer tool, in Application Errors list. Or just copy'n'paste the console output of your program. – Viktor Latypov May 31 '12 at 22:17
  • Try the "stdcall" calling convention ! You should have posted the log earlier :) I've edited the answer for the StdCall. – Viktor Latypov May 31 '12 at 22:35
  • Yes my apologies, I had forgot to turn 'debug unmanaged code'. That solved it however, thank you very much for your help! Now time for me to go and read up on the difference between calling conventions :) – TomP89 May 31 '12 at 22:59
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/12003/discussion-between-viktor-latypov-and-tomp89) – Viktor Latypov May 31 '12 at 22:59
11

I had the exact same problem as the OP (same error message). The accepted answer did not help at all, which even @TomP89 admits in the comments.

This is not surprising because the error message indicates that the calling convention of the passed callback function is wrong, whereas the supposed solution changes the calling convention of the function that passes the callback, which results in a stack imbalance if what the library exports are cdecl-functions (as is the default case for all functions outside the Win32 API).

It turns out that .Net assumes by default the calling convention "stdcall" for any delegate. Typically the unmanaged code will assume the same calling convention as its exported functions (in this case and mine: "cdecl").

So the true solution (which finally worked for me) is changing the calling convention of the callback to "cdecl". This question shows how this is accomplished, in short:

    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    public delegate void TomDelegate(int a, int b);
oliver
  • 2,771
  • 15
  • 32