3

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
Steve Stone
  • 31
  • 1
  • 2
  • I've also ported an app to 64-bit and had to change MSXML4 to MSXML6 but there hasn't been any error with the loading and parsing of XML documents; the parser library is not buggy, at least not in the suggested way. try creating a stand alone simple 64-bit app that uses MSXML and try to reproduce the problem; I doubt you will be able; that would probably show a bug within the library. – Marius Bancila Jun 09 '11 at 15:05

2 Answers2

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.

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • Thanks, but i already checked that. Also if `CoUninitialize()` would been called (for whatever reasons), then the `CreateInstance` of the XMLDOMDocument would return an error code. But instead it returns a correct COM pointer. At least it looks like it. Although at the first use it throws an exception (as seen above). – Steve Stone Jun 09 '11 at 13:38
0

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

klob
  • 1
  • 1