前言
在C#开发中，我们常常会通过平台调用（P/Invoke）或COM互操作来调用非托管代码，以实现对操作系统底层功能的访问。这种方式虽然强大，但也隐藏着不少陷阱，尤其是在处理复杂结构体时。
本文记录了一次在实际开发中遇到的离奇Bug：一个局部变量在调用非托管函数后莫名其妙地变成了null，而问题的根源竟然是对union类型内存布局的误解。这不仅是一次调试经历的复盘，更是一次对C#与非托管代码交互机制的深入理解。
一、离奇现象
你有没有遇到过这样的情况：一个明明非null的局部变量，在调用了一个看似正常的非托管函数后，突然就变成了null？中间没有抛出任何异常，返回值也完全正确，但变量的状态却“被篡改”了。
前几天，我就遇到了这样一个诡异的问题。代码逻辑非常简单，目的是从一个WPF窗口获取某个属性值：
private static PropVariant GetProperty(Window window, PropertyKey key)
{
var hwnd = new WindowInteropHelper(window).EnsureHandle();
Win32.Shell32.SHGetPropertyStoreForWindow(hwnd, out IPropertyStore ps);
ps.GetValue(ref key, out PropVariant value);
return value;
}
其中，ps 是一个通过COM接口获取的 IPropertyStore 对象。在调用 ps.GetValue(...) 之前，ps 是有效的（非null），但调用之后，它却变成了null。更奇怪的是，value 的值是正确的，没有任何异常抛出。
二、暗藏玄机
IPropertyStore 是一个COM接口，而 PropVariant 是一个典型的非托管结构体，其原型定义如下（来自Windows SDK）：
typedef struct tagPROPVARIANT {
union {
typedef struct {
VARTYPE vt;
PROPVAR_PAD1 wReserved1;
PROPVAR_PAD2 wReserved2;
PROPVAR_PAD3 wReserved3;
union {
// ... 此处省略大量成员
};
} tag_inner_PROPVARIANT, PROPVARIANT, *LPPROPVARIANT;
DECIMAL decVal;
};
} PROPVARIANT, *LPPROPVARIANT;
我在C#中最初是这样封装的：
[StructLayout(LayoutKind.Sequential)]
internal record struct PropVariant(ushort vt, IntPtr pointer);
这个结构体在64位系统中默认大小是16字节（ushort 2字节 + IntPtr 8字节，加上6字节填充对齐）。
但问题就出在这里。当我尝试将结构体大小显式声明为128字节时，问题消失了：
[StructLayout(LayoutKind.Sequential, Size = 128)]
internal record struct PropVariant(ushort vt, IntPtr pointer);
这说明，非托管代码在操作 PropVariant 时，实际写入的内存超过了16字节，导致了内存访问越界。而越界写入的区域，恰好覆盖了栈上相邻的局部变量——也就是 ps。
三、追根溯源
为了验证这一点，我调整了局部变量的声明顺序：
IPropertyStore ps;
var hwnd = new WindowInteropHelper(window).EnsureHandle();
Win32.Shell32.SHGetPropertyStoreForWindow(hwnd, out ps);
ps.GetValue(ref key, out PropVariant value);
return value;
结果发现，被“破坏”的变量从 ps 变成了 hwnd。这强烈暗示了局部变量在栈上是连续排列的，当 value 被越界写入时，自然会影响到它后面的变量。
通过查看IL代码，我确认了局部变量的分配顺序：
.locals init (
[0] class IPropertyStore ps,
[1] native int hwnd,
[2] valuetype PropVariant 'value',
[3] valuetype PropVariant V_3
)
在原始代码中，hwnd 和 ps 的顺序是相反的。ldloca.s 'value' 指令将 value 的地址压入栈，非托管代码通过这个地址写入数据，但由于 PropVariant 实际大小大于封装大小，写操作就越界到了相邻的栈空间。
四、罪魁祸首
问题的根源在于 PropVariant 的复杂结构，尤其是内部的 union。union 的大小等于其最大成员的大小（考虑内存对齐）。
在 PropVariant 中，内部的 union 包含一个名为 tag_inner_PROPVARIANT 的结构体，该结构体包含一个更深层的 union，其中某些成员（如 CALPWSTR）的大小为16字节。加上前面的 vt 和三个保留字段（共8字节），整个结构体在64位系统下大小为24字节。
而我最初封装的 PropVariant 只有16字节，导致非托管代码写入时越界8字节，正好覆盖了栈上相邻的指针变量。
最终，将封装修正为：
[StructLayout(LayoutKind.Sequential, Size = 24)]
internal record struct PropVariant(ushort vt, IntPtr pointer);
或者更严谨地，显式声明字段以兼容32位和64位系统：
[StructLayout(LayoutKind.Sequential)]
internal record struct PropVariant(VarEnum vt, IntPtr pointer)
{
public VarEnum vt = vt;
private ushort r1;
private ushort r2;
private ushort r3;
public IntPtr pointer = pointer;
private IntPtr r4;
}
本文通过一个真实的调试案例，揭示了在C#中调用非托管代码时，因结构体大小不匹配导致的内存越界问题。
核心教训是：在封装非托管结构体时，必须精确匹配其内存布局，尤其是涉及 union 类型时，要计算其最大可能大小。
总结
这次经历让我深刻体会到，平台调用虽方便，但一旦涉及内存操作，就必须格外小心。一个看似微不足道的结构体封装错误，可能导致程序行为异常，且难以排查。通过IL分析和对栈布局的理解，我们最终定位并解决了问题。这也提醒我们，在使用AI生成互操作代码时，仍需具备扎实的底层知识进行验证。
关键词
C#、非托管代码、内存越界、union、StructLayout、平台调用、PropVariant、局部变量、栈溢出、IL分析
最后
如果你觉得这篇文章对你有帮助，不妨点个赞支持一下！你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助，欢迎随时留言。
也可以加入微信公众号 [DotNet技术匠] 社区，与其他热爱技术的同行一起交流心得，共同成长！
优秀是一种习惯，欢迎大家留言学习！
作者：昏睡红猹
出处：.cnblogs.com/yangtb/p/19031663
声明：网络内容，仅供学习，尊重版权，侵权速删，歉意致谢！
