从非托管C++调用C++/CLI代码时Debug模式访问违例排查

问题场景 #

• C++/CLI单元测试项目（目标框架.NET Core 6）集成Google Tests，导出方法如下：

int runTests(int argc, char* argv[])
{
    testing::InitGoogleMock(&argc, argv);
    return RUN_ALL_TESTS();
}

• 非托管C++可执行文件通过以下代码调用该方法：

int main(int argc, char* argv[])
{
    return runTests(argc, argv);
}

• Visual Studio 2022编译后，Release模式运行正常；Debug模式下runTests执行完毕、main函数即将退出时，coreclr.dll中触发「Access violation reading location ...」错误，断点指向gtest.cc的TestInfo::~TestInfo() { delete factory_; }代码行。

排查方向 #

• CRT运行时库跨模块不匹配：Debug模式下，C++/CLI DLL和非托管EXE若使用不同的CRT（如DLL用/MDd多线程调试DLL CRT，EXE用/MTd多线程调试静态CRT），会导致factory_在DLL的CRT堆分配，却在另一个CRT堆释放，引发访问违例。检查两个项目的C/C++ -> 代码生成 -> 运行时库设置，确保一致（推荐统一使用/MDd）。
• GTest生命周期与CLR运行时冲突：Debug模式下CLR的垃圾回收或模块卸载逻辑可能提前释放GTest相关资源。尝试在runTests末尾手动调用testing::ShutdownGoogleMock()，确保GTest资源在CLR环境未卸载前完成清理。
• 托管/非托管边界内存问题：Debug模式下CLR对非托管内存的检查更严格。argv参数跨模块传递时可能被CLR意外修改或回收，可在runTests内部先将argv复制到DLL本地内存，再传递给InitGoogleMock，规避跨边界内存生命周期风险。
• GTest版本兼容性：部分GTest版本的Debug模式实现可能与C++/CLI的异常处理、内存模型存在冲突。尝试升级GTest到最新稳定版，或检查是否启用了GTEST_HAS_SEH等与C++/CLI不兼容的编译选项。
• CLR模块卸载时机异常：Debug模式下，runTests返回后CLR可能提前卸载C++/CLI DLL模块，而GTest全局对象（如TestInfo实例）在EXE退出时才销毁，此时对应内存已被CLR回收。可在main调用runTests后手动触发CLR清理，或调整项目设置延迟模块卸载。
• 内存状态调试：在崩溃断点处查看factory_是否为野指针或已释放内存，通过VS内存窗口查看factory_的分配栈，确认释放时对应的模块是否仍处于加载状态。

内容的提问来源于stack exchange，提问作者advocateofnone