我们正在将一个巨大的应用程序从 32 位移植到 64 位。这个应用程序有一些外部库，我们要么禁用它们，要么使用它们的 64 位版本。我们还通过我们自己编写的 COM 方法访问数据库。我们使用的是在 32 位上运行良好的 MSXML4。
MSXML4 没有 64 位版本，所以我们升级到 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 位端口上犯了一个致命的错误？
有没有人遇到过类似的问题？
任何帮助都会很感激，因为我现在真的被困住了，因为我不知道如何找到真正的问题。