我们正在将一个巨大的应用程序从 32 位移植到 64 位。这个应用程序有一些外部库，我们要么禁用它们，要么使用它们的 64 位版本。 我们还通过自己编写的 COM 方法访问数据库。我们使用的是在 32 位上运行良好的 MSXML4。
没有 64 位版本的 MSXML4，因此我们升级到 MSXML6。我们只使用了 MSXML 的一些功能，尤其是 DOM 解析器，所以我们唯一做的就是替换以下行:
#import "msxml6.dll"
和
MSXML2::IXMLDOMDocumentPtr pXMLDocPtr;
pXMLDocPtr.CreateInstance( ___uuidof( MSXML2::DOMDocument60 ) );
然后我们尝试做这样的事情:
pXMLDocPtr->loadXML( _bstr_t( L"<?xml version=\"1.0\" encoding=\"utf-8\"?><abc></abc>" ) );
这在 32 位下工作正常。但在 64 位下，调用 loadXML 函数时 msxml6.dll 会抛出异常。虽然 CreateInstance 返回一个有效的指针并且返回码是 S_OK。调试输出中还打印了一条错误消息:
First-chance exception at 0x000007fef888238e in App.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
Unhandled exception at 0x000007fef888238e in App.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
一开始我们以为是我们使用库的方式不对，后来发现了下面的东西。如果我们在初始化我们自己的 COM 组件之前读取我们的 XML 文件，它就可以工作。所以现在看起来我们自己的 COM 组件正在“破坏”COM 库。但这怎么可能呢？
我们进行了一些试验，只有当我们尝试使用 MSXML 时才会出现问题。所有其他 COM 对象都在工作。除了 IFileDialog(我认为它也是一个 COM 类)有一次在使用过程中崩溃。
问题出现在我们调用 COM 组件的 CoCreateInstance 之后，这在我们的例子中并没有做太多。而且我在我们的 COM 服务器上看不到任何明显的错误，例如具有 64 位数据类型。
那么问题是:
64 位版本的 MSXML 有问题吗？
还是我们在 COM 服务器的 64 位端口上犯了一个 fatal error ？
有没有人遇到过类似的问题？
任何帮助将不胜感激，因为我现在真的陷入困境，因为我不知道如何追踪真正的问题。
最佳答案
出现这种情况的典型原因是对 CoUninitialize() 的意外调用 - 它导致所有 COM 对象被释放并且指向它们的所有指针都变得悬空。 See this question for an example .
关于c++ - COM 和 MSXML 的问题(仅限 64 位)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6293262/