Question

I have a DLL from which I need to P/Invoke the following C method:

int DAOpen(HANDLE *hOpen, UNIT *flags, void *callback, char *userData)

I’ve come up with the following C# signature:

[DllImportAttribute("<libName>", EntryPoint="DAOpen")]  
    static extern  int DAOpen(  
    out IntPtr hOpen,  
    ref uint flags,  
    IntPtr callback,  
    IntPtr userData);

Assuming the native code keeps a reference to all parameters for longer than the duration of the P/Invoke call:

1. Aside from keeping an instance of the hOpen, should I also pin it?

2. Should I keep a reference of the flags variable? Should I also pin it since it’s passed as a reference in this particular case?

3. I’m assigning my callback delegate in the following way:

   private IntPtr callBackOnNativeEvents;
...
this.callBackOnNativeEvents = Marshal.GetFunctionPointerForDelegate(
new CallBack(this.CallBackOnNativeEvents));

   Should I keep a reference to the delegate in itself (not only the pointer)? Should I also pin it?

4. Finally, I’m defining the userData parameter in the following way:

   private IntPtr userData;
...
string userName = "test";
this.userData = Marshal.StringToHGlobalAnsi(userName);

   Should I keep a reference to the string? Should I also pin it? The API documentation states that it copies the string content to unmanaged memory, but I’m not sure if it copies the content of the reference.

Answer 1

1. No need to pin hOpen, it has value type semantics.
2. If the DLL writes to the address pointed to by flags, and does so after the original function returns, then you need to pin it one way or another (as well as keeping it alive and safe from the clutches of the GC).
3. The callback function pointer is already effectively pinned. You need to keep a reference to the delegate alive, but you don’t need to pin it because the native thunk is allocated from the unmanged heap.
4. You don’t need to do anything special here because you are passing an IntPtr and the memory behind that is pinned. You don’t need to to keep a reference to the string alive because it is completely disconnected from the IntPtr returned by StringToHGlobalAnsi. It just has a copy of the contents of the string at the point of call to StringToHGlobalAnsi.

I have to say that I am still incredulous that this DLL really could be doing what you say it is doing. I suspect that something else is going wrong which you are mis-diagnosing as the DLL holding onto pointer parameters from one call and then modifying their contents during subsequent calls. I find that exceptionally hard to believe, but of course only you can really know. If I was in your position I would simply ask the question of the DLL vendor.