Databases
StackOverflow2013
Postsdbo
POProblem with COM and MSXML (64-bit only)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POProblem with COM and MSXML (64-bit only)
    primarykey
    data
    text
    <p>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.</p> <p>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:</p> <pre><code>#import "msxml6.dll" </code></pre> <p>and</p> <pre><code>MSXML2::IXMLDOMDocumentPtr pXMLDocPtr; pXMLDocPtr.CreateInstance( ___uuidof( MSXML2::DOMDocument60 ) ); </code></pre> <p>then we try to do something like this:</p> <pre><code>pXMLDocPtr-&gt;loadXML( _bstr_t( L"&lt;?xml version=\"1.0\" encoding=\"utf-8\"?&gt;&lt;abc&gt;&lt;/abc&gt;" ) ); </code></pre> <p>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:</p> <pre><code>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. </code></pre> <p>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?</p> <p>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.</p> <p>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.</p> <p>So the question is:</p> <p>Is the 64-bit version of MSXML buggy?</p> <p>Or did we make a fatal mistake with our 64-bit port of the COM servers?</p> <p>Has anyone experienced similar problems?</p> <p>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.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USSteve Stone
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POProblem with COM and MSXML (64-bit only)
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POProblem with COM and MSXML (64-bit only)
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POProblem with COM and MSXML (64-bit only)
      1. USIngo Schalk-Schupp
      1. VTFavorite
    1. COI'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.
      singulars
      1. POProblem with COM and MSXML (64-bit only)
      1. USMarius Bancila
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload