Keeping PInvoked method alive

Question

Here's my C code:

    LIBRARY_API bool __cdecl Initialize(void (*FirstScanForDevicesDoneFunc)(void));

And here's C# PINvoke code to work with this DLL:

    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    public delegate void FirstScanForDevicesDoneFunc();

    [DllImport("Native.dll", CallingConvention=CallingConvention.Cdecl)]
    public static extern bool Initialize(FirstScanForDevicesDoneFunc);

When I call this method like this:

    static public void Init() {
        Initialize(FirstScanForDevicesDone);
    }

    static public void FirstScanForDevicesDone() {
        //do something
    }

At the end of Init() when callback comes I get NullReferenceException. So I use Thread to keep it and everything works fine, but I'm not happy with this solution:

    static public bool Working = true;

    static public void Init() {
        new Thread(() =>
        {
            Thread.CurrentThread.IsBackground = true;

            Initialize(FirstScanForDevicesDone);
            while (Working)
            {
                Thread.Sleep(1000);
            }
        }).Start();
    }

Is there a more sophisticated way to keep this working?

We'd first of all need to understand the problem. Why to you have a `NullReferenceException`? What is the native code doing? When is the callback called? — David Heffernan, Sep 22 '14 at 11:29
Standard way to define managed callback for native code is using Marshal.GetFunctionPointerForDelegate method. — Alex F, Sep 22 '14 at 11:40
@AlexFarber It looks that Your previous comment worked: keep static variables of callback functions. That means that callbacks are being collected at the end. I feel stupid right now. — Mike G, Sep 22 '14 at 11:46

score 11 · Accepted Answer · edited May 23 '17 at 11:44

So I use Thread to keep it and everything works fine

No, the thread doesn't actually fix the problem. It only looks like it does, a side-effect of testing the Debug build and using a debugger. It will still crash the exact same way after you ship the Release build to your customer. Worst kind of failure of course. Why it seems like the thread solves it is explained in this post.

You need to fix the real problem, you are passing a delegate object to the native code but after the Init() method completes there is no visible reference to the object anymore. The garbage collector cannot peek inside the native code to see it in use. So the next garbage collection is going to destroy the object, kaboom when the native code makes the callback after that. Do note that you normally get a strongly worded warning about that from a debugger assistant, do make sure you didn't solve the problem by shooting the messenger.

Proper fix is:

   static FirstScanForDevicesDoneFunc callbackDelegate;

   static public void Init() {
        callbackDelegate = new FirstScanForDevicesDoneFunc(FirstScanForDeviceDone);
        Initialize(callbackDelegate);
   }

The callbackDelegate variable ensures that the GC can always see a reference to the object. You set it back to null when the native code cannot make callbacks anymore. Typically never.

Thanks - that's a great and simple solution. I feel stupid that I didn't notice this before. — Mike G, Sep 22 '14 at 11:52

Keeping PInvoked method alive

1 Answers1

Linked