巨大なアプリケーションを 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 を呼び出した直後に発生しますが、この場合はあまり効果がありません。また、64 ビット データ型など、COM サーバーで明らかなエラーは見られません。
質問は次のとおりです。
MSXML の 64 ビット バージョンにはバグがありますか?
それとも、COM サーバーの 64 ビット ポートで致命的なミスを犯したのでしょうか?
誰かが同様の問題を経験しましたか?
実際の問題を追跡する方法がわからないため、現時点で本当に行き詰まっているので、助けていただければ幸いです。