PInvoke调用导致堆栈不对称

对 PInvoke 函数“HTLib::Usb_DelHtFile”的调用导致堆栈不对称。原因可能是托管的 PInvoke 签名与非托管的目标签名不匹配。请检查 PInvoke 签名的调用约定和参数与非托管的目标签名是否匹配。

把：

[DllImport("ht32dll.dll")]

public static extern long Usb_DelHtFile(string filename,long mIndex);

改成：

[DllImport("ht32dll.dll")]

public static extern int Usb_DelHtFile(string filename, int mIndex);

 

后来查阅网文（网址：http://hi.baidu.com/wzlv/blog/item/cfd09e189ebf320134fa41eb.html），把这个问题说的比较清楚，引述如下，备忘：

从.NET1.1升级到.NET2.0时出现的PInvokeStackImbalance错误

微软官方的解释 (http://msdn2.microsoft.com/zh-cn/library/0htdy0k3.aspx)

如果 CLR 检测到平台调用之后的堆栈深度与 DllImportAttribute 属性指定的调用约定中以及托管签名的参数声明中提供的预期堆栈深度不匹配，则将激活 PInvokeStackImbalance 托管调试助手 (MDA) 。

下面将举一个具体的例子

PCCamera 类 (UserLib.Device.PCCamera摄像头类) 在从 .NET1.1升级到.NET2.0 时出现的 PInvokeStackImbalance 错误 :

检测到 PInvokeStackImbalance

Message: 对 PInvoke 函数“ WindowsApplication1!UserLib.Device.PCCamera::SendMessage ”的调用导致堆栈不对称。原因可能是托管的 PInvoke 签名与非托管的目标签名不匹配。请检查 PInvoke 签名的调用约定和参数与非托管的目标签名是否匹配。

错误首次发生在这一行代码 : SendMessage(hWndC, WM_CAP_SET_CALLBACK_VIDEOSTREAM, 0, 0);

经过分析发现所有调用SendMessage函数的地方都会出现以上错误

于是查看DLLImport:

[DllImport("User32.dll")]

private static extern bool SendMessage(IntPtr hWnd, int wMsg, int wParam, long lParam);

原来是因为WinAPI的long类型是32位的,而C#的long是64位的,这就导致 堆栈不对称 , 引发错误 .

原因 : (http://discuss.develop.com/archives/wa.exe?A2=ind0512c&L=dotnet-winforms&D=0&T=0&P=8094)

在 .NET2.0 中加入了 MDA(managed debugging assistant), 在平台调用时后会检查栈的指针 , 如果发现不平衡 , 就会抛出 PInvokeStackImbalance 异常 ; 而在 .NET1.1 中不会检查 , 所以不会捕获到异常 , 但在运行时会导致不稳定 .

解决方法 :

将最后一个 ” long lParam ” 改为 “ int wParam ”, 因为 C# 中 int 是 32 位的 . 并且将之后有涉及到 SendMessage 函数的参数适当地转成 int 型就可以了 .

但是 , 之后查阅了资料 http://www.pinvoke.net/default.aspx/user32/SendMessage.html

发现先前的解决方案还有不合适的地方 , 应该将其中的 ”wParm” 和 ”lParm” 参数的类型都转成 IntPtr 类型 , 并且将后面涉及到的参数的 ”0” 改为 “IntPtr.Zero”. 因为如果使用 int 类型 , 那么这段代码在 64 位的 Windows 上面将会无法正常运行 .

总结 :

       我们在调用 WinAPI 时要特别小心 , 因为 WinAPI 和 C# 的数据类型不是完全一样 , 就好像在 WinAPI 中的 long 类型在 C# 中就是 int 类型 , 如果没有处理好类型问题 , 就很可能会导致堆栈的不平衡 , 引发 PInvokeStackImbalance 错误 , 但是这类错误在 .NET1.1 下不会被暴露出来 , 所以在从 .NET1.1升级到.NET2.0 时要特别注意此类问题 .