.NET Framework 4.5+中Marshal.PtrToStringUni引发AccessViolationException问题

哇，这个问题我之前帮同事排查过类似的，刚好能给你分享下思路！首先得明确：这个异常几乎肯定和.NET Framework 4.0到4.5+之间的互操作封送行为变化有关，尤其是非托管内存的管理和安全性校验的严格化。

可能的核心原因 #

1. PInvoke声明不规范，4.0中侥幸兼容，4.5+暴露问题 #

.NET 4.0对PInvoke的校验相对宽松，一些不符合规范的声明（比如调用约定不匹配、字符集未指定、返回值封送属性缺失）可能不会触发异常，但4.5+引入了更严格的栈校验和内存访问检查，直接把潜在问题爆出来了。

比如如果你的非托管函数返回的是LPWSTR（Unicode字符串指针），但PInvoke声明没指定返回值的封送类型，4.5+可能会错误地处理内存生命周期，导致指针指向的内存被提前回收。

2. 非托管内存生命周期管理不当 #

如果非托管函数返回的指针指向的是需要手动释放的内存，在4.0中GC可能没那么快回收相关资源，但4.5+的GC机制优化后，可能在你调用Marshal.PtrToStringUni之前就释放了内存，导致访问受保护的内存区域。

3. 字符串长度参数错误 #

Marshal.PtrToStringUni(IntPtr ptr, int len)中的len如果指定过大，会导致读取超出指针指向的内存范围，触发内存访问异常——4.0可能对这种越界访问的容忍度更高，而4.5+直接拦截了。

具体解决方案 #

1. 严格规范PInvoke声明 #

确保你的PInvoke声明和非托管函数的签名完全匹配，尤其是：

• 指定正确的调用约定（比如CallingConvention.Cdecl或CallingConvention.StdCall）
• 明确返回值/参数的封送类型
• 设置正确的字符集

举个正确的例子：

// 假设非托管函数是：LPWSTR GetMyUnicodeString();
[DllImport("YourNative.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.LPWStr)]
public static extern IntPtr GetMyUnicodeString();

2. 手动管理非托管内存生命周期 #

如果非托管函数返回的内存需要你手动释放，一定要在读取完字符串后调用对应的释放方法：

IntPtr strPtr = GetMyUnicodeString();
try
{
    if (strPtr != IntPtr.Zero)
    {
        // 可以用Marshal.PtrToStringUni自动识别长度，或者传入正确的len
        string result = Marshal.PtrToStringUni(strPtr);
        // 处理字符串
    }
}
finally
{
    // 根据非托管函数的内存分配方式选择释放方法：
    // 如果是LocalAlloc分配的，用Marshal.FreeHGlobal
    Marshal.FreeHGlobal(strPtr);
    // 如果是CoTaskMemAlloc分配的，用Marshal.FreeCoTaskMem
    // Marshal.FreeCoTaskMem(strPtr);
}

3. 临时启用.NET 4.0兼容模式（应急方案） #

如果暂时没时间修改代码，可以在项目的app.config中添加兼容性开关，让4.5+的PInvoke行为回到4.0的宽松模式：

<configuration>
  <runtime>
    <NetFx40_PInvokeStackResilience enabled="true"/>
  </runtime>
</configuration>

⚠️ 注意：这只是临时方案，长期来看还是要修复PInvoke声明和内存管理的问题，避免潜在的内存泄漏或其他不稳定问题。

4. 校验指针有效性和长度 #

在调用Marshal.PtrToStringUni之前，先做基础校验：

if (strPtr == IntPtr.Zero)
{
    throw new InvalidOperationException("非托管函数返回空指针");
}
// 如果能获取到正确的字符串长度，不要硬传len，避免越界
string result = Marshal.PtrToStringUni(strPtr); // 自动识别以'\0'结尾的字符串长度

总结 #

优先从PInvoke声明的规范性和非托管内存的生命周期入手排查，这两个是最常见的原因。4.5+的.NET Framework对互操作的安全性要求更高，很多在4.0中“能跑”的不规范代码，都会在高版本中暴露问题——这其实是好事，能帮你提前发现潜在的内存问题。

内容的提问来源于stack exchange，提问作者Eric P.