OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历

项目需要,用到了OPC,系统是64位系统,因为调用了x64的库,所以整个工程是以x64模式编译的,但是我手中的OpcRcw.da.dll却是x86的

经过单步调试发现会在向Group中添加Item时直接跳出,异常信息是 超出读写范围     也就是说代码的指针跑到了它不应该到的地方。

代码锁定在

  ((IOPCItemMgt)GetObjectByGroupName(groupName)).AddItems(itemCount, ItemDefArray, out pResults, out pErrors);

这句出现了问题。

看函数的入参类型:

OPCITEMDEF[] ItemDefArray 
IntPtr pResults
IntPtr pErrors
int itemCount

可以看到在AddItem函数中有一个结构体数组形式的入参

右键查看定义,跳转到dll元数据中(我跟你们讲啊,这个.Net调试起来感觉真是赞..)

下图中可以看到该结构体中有一个IntPtr 指针pBlob

OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历_第1张图片

 结构体里存指针,我的直觉告诉我这里可能有问题,(关于这个直觉下文再说)

来了个测试代码

OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历_第2张图片

x86模式下编译输出结果是4

x64下输出为8

然后通过ILSpy逆向OpcRcw.da.dll看源码(这个工具还能实现C#和VB.Net的代码互转 http://blog.csdn.net/backspace110/article/details/53525404)

OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历_第3张图片

可以看到 Pack = 4 也就是说该结构体是4字节对齐的。

关于结构体对齐的那一堆规则就不说了,有兴趣的可以去查一下,分几种情况的,我也记不全。

反正对齐规则是会影响内存分布的,(之前说的直觉)可能会把x64模式下8字节的IntPtr拆分掉。

主要是之前单片机开发时遇到过结构体对齐的问题。


大体上知道了可能的问题,那么就改成Pack = 8试试。

在ILSpy中FIle -> Save Code 导出为VS工程文件源码

修改Pack = 8 然后重新编译为dll

再回到我的代码中,调用我修改的最新的OpcRcw.da.dll

再次以x64模式编译,问题解决。


上附件,vs2015,x86,x64,anycpu的debug与release模式dll下载

http://dl2.iteye.com/upload/attachment/0121/8582/7100e290-ddb3-32af-850e-e6d6fc382691.zip



你可能感兴趣的:(OpcRcw.da.dll在x64模式下编译运行失败的一次调试经历)