Problem with COM and MSXML (64-bit only)

2

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.

c++
com
64-bit
porting
msxml6
asked on Stack Overflow Jun 9, 2011 by Steve Stone • edited Jan 23, 2020 by Christophe

1 Answer

0

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.

answered on Stack Overflow Jun 9, 2011 by sharptooth • edited May 23, 2017 by Community

User contributions licensed under CC BY-SA 3.0