A call to PInvoke function has unbalanced the stack. This is likely because the managed PInvoke .. (.NET 4)

Question

My project run successful without errors in .NET Frame work 3.5. But, When I target it to .NET Frame work 4. I got the error:

"A call to PInvoke function has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature."

I used unmanaged library as below:

[StructLayout(LayoutKind.Sequential )]
public class DGNElemCore
{
    public int offset;
    public int size;
    public int element_id;
    public int stype;          
    public int level;
    public int type;
    public int complex;
    public int deleted;
    public int graphic_group;
    public int properties;
    public int color;
    public int weight;
    public int style;
    public int attr_bytes;       
    public IntPtr attr_data;  
    public int raw_bytes;
    public IntPtr raw_data;                 

}

[DllImport("DgnLib.dll", EntryPoint = "DGNOpen")]           
public static extern IntPtr  DGNOpen(string fileName, int bUpdate)

Do you know how to fix this error ?

Kurtzig

#13007080 ? suggests the return type should be DGNElemCore, not IntPtr (btw: I found that by doing a google search for DGNOpen pinvoke - it was the second answer... right after your duplicate of this question on MSDN) – Lyly

@MarcGravell: But DGNOpen returns a DGNHandle which I believe is a void pointer thus IntPtr is the right type. Or did I overlook something? – Sachsse

Do you know how to fix this error? Yes, I do know how. But that is contingent on seeing the native declarations. This is interop. Asking a question with only half of the interface is like a game of pin the tail on the donkey. – Oleviaolfaction

Moving to .NET 4 typically also means you moved to a new VS version, VS2010+. Which uses a different default for the Platform target setting, now forcing 32-bit code. 64-bit code is pretty permissive of declaration mistakes, 32-bit code is not. CallingConvention matters, it should be Cdecl for this function. Return type is good, it is DGNHandle which is a pointer. – Defazio

Answer 1

Add this along with dll import.

, CallingConvention = CallingConvention.Cdecl)]

As taken from here.

Platform invoke

To improve performance in interoperability with unmanaged code, incorrect calling conventions in a platform invoke now cause the application to fail. In previous versions, the marshaling layer resolved these errors up the stack.

Debugging your applications in Microsoft Visual Studio 2010 will alert you to these errors so you can correct them. If you have binaries that cannot be updated, you can include the element in your application's configuration file to enable calling errors to be resolved up the stack as in earlier versions. However, this may affect the performance of your application.

Blackmun

Thanks No One very much ! I added ", CallingConvention = CallingConvention.Cdecl" and successful – Kurtzig

Just saved the day with this one. Had a very old DLL that would not play nice with my new projects until I added the calling convention. +1 :) – Dorsman

I don't see how those paragraphs from the link explain why you needed to specify the calling convention? What was "incorrect" to begin with? VB code that uses the Declare statement don't use attributes. – Manymanya

@Blackmun Did not work for me in a more complicated scenario spawning the same error message as described in the comments of this answer. Please take a look if you have any ideas. – Picayune

Answer 2

I added, CallingConvention.ThisCall, while importing the DLL and it worked

Please try other constants, and check which one works in your environment

Makowski

Definitely give this a try. CallingConvention.Winapi worked for me. – Tabriz