COM 和 MSXML 问题（仅限 64 位）
我们正在将一个巨大的应用程序从 32 位移植到 64 位。该应用程序有一些外部库，我们禁用或使用它们的 64 位版本。 我们还通过自己编写的 COM 方法访问数据库。我们使用的是 MSXML4，它在 32 位上运行良好。
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 位端口上犯了致命错误？
有人遇到过类似的问题吗？
任何帮助将不胜感激，因为我现在真的陷入困境，因为我不知道如何找出真正的问题。
We are porting a huge application from 32-bit to 64-bit. This application has a few external libraries which we either disabled or used their 64-bit versions.
We are also accessing a database via our self-written COM methods. And we were using MSXML4 which worked fine on 32-bit.
There is no 64-bit version of MSXML4 so we upgraded to MSXML6. We just use a few features of MSXML, especially the DOM parser, so the only thing we did was substitute the following lines:
#import "msxml6.dll"
and
MSXML2::IXMLDOMDocumentPtr pXMLDocPtr;
pXMLDocPtr.CreateInstance( ___uuidof( MSXML2::DOMDocument60 ) );
then we try to do something like this:
pXMLDocPtr->loadXML( _bstr_t( L"<?xml version=\"1.0\" encoding=\"utf-8\"?><abc></abc>" ) );
This works fine under 32-bit. But under 64-bit the msxml6.dll throws an exception when the loadXML function is called. Although CreateInstance returns a valid pointer and the return code is S_OK. There is also an error message printed in the debug output:
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.
At first we thought that the way we use the library is wrong, but then we discovered the following thing. If we read our XML file before we initialize our own COM components, it works. So now it looks like our own COM components are "damaging" the COM library. But how is this even possible?
We were experimenting a little bit and the problem only appears if we try to use MSXML. All other COM objects are working. Except for one time the IFileDialog (which is also a COM class i think) crashed during its usage.
The problem appears right after we call CoCreateInstance of our COM components which doesn't do much in our case. And I can't see any obvious errors at our COM server e.g. with 64-bit data types.
So the question is:
Is the 64-bit version of MSXML buggy?
Or did we make a fatal mistake with our 64-bit port of the COM servers?
Has anyone experienced similar problems?
Any help would be appreciating as i'm really stuck at the moment, because i have no idea how to track down the real problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
典型的原因是对 CoUninitialize() 的意外调用 - 它导致所有 COM 对象被释放，并且所有指向它们的指针变得悬空。 请参阅此问题的示例。
The typical reason for that is an unexpected call to
CoUninitialize()- it leads to all COM objects being released and all pointers to them becoming dangling. See this question for an example.是的，我认为 64 位版本有更多 bug。我多次遇到错误，但在使用 32 位版本时没有发生。
，其中
一个例子是枚举命名空间
可能会导致访问冲突（对于 MSXML 6.30.17763.2989 64 位，较新的版本似乎修复了此问题）。
请务必检查系统上安装的组件的实际版本，因为行为可能会有所不同。
有关详细信息，请参阅 https://developercommunity.visualstudio。 com/t/access-violation-in-msxml6dll-referenceoperator-cl/1357678
Yes, the 64bit version is in my opinion more buggy. I hit bugs multiple times which did not occur when using the 32bit version.
One example is enumerating namespaces with
<xsl:for-each select="./namespace::*">, which
may result in an access violation (with MSXML 6.30.17763.2989 64bit, newer versions seem to fix this).
Be sure to check the actual version of the component installed on the system, as there may be differences in the behaviour.
For more info see https://developercommunity.visualstudio.com/t/access-violation-in-msxml6dll-referenceoperator-cl/1357678