IDispatch::Invoke()で渡していないCComVariant型変数の値が変わる。

###環境
Windows10 64bit / Visual Studio 2019
C++17
###経緯
以下コードの実行時に、
最初の IDispatch::Invoke() の引数用として準備した CComVariant 型の変数 params について、
2回目の IDispatch::Invoke() 実行時にその値が書き換わってしまう現象が発生しました。

該当の変数の初期化時には、取得するエクセルの Range オブジェクトのアドレスが格納されています。
これが、2回目の IDispatch::Invoke() 実行後に取得した result.parray の一番最初の要素に書き換わります。
掲題では値としましたが、参照先が result.parray[1][1] （最初の要素）と全く同じになります。

以下コードの通り、2回目の IDispatch::Invoke() の実行時には該当の変数 params を渡していません。
強いて言うなら、params を利用して取得した CComDispatchDriver 型の range を渡しています。

また、以下コードでは1回目と2回目の実行時に同じ変数 result が渡されていますが、
実際は1回目と2回目の実行でルーチンを分離しており、この事象の発生とは無関係であることを確認しています。
ルーチンを分離せず、以下の通りに実行しても同様の事象が発生することは確認済みです。
###知りたいこと
1．この事象の原因は何でしょうか。
2．この事象が発生しない為にはどの様にすれば良いでしょうか。
###コード
※値が格納されない変数については、コメントの通りの値が格納されているものと仮定して下さい。

C++
1int main() {
2	CComVariant params;
3	params.vt = VT_BSTR;
4	params.bstrVal = CComBSTR(L"A1:B2");
5
6	DISPPARAMS disp_params = { nullptr,nullptr,NULL,NULL };
7	disp_params.cArgs = 1;
8	disp_params.rgvarg = &params;
9
10	CComDispatchDriver	worksheet;		//エクセルのワークシートの IDispatch*。
11	DISPID				dispid;			// Worksheet.Range の DISPID。
12	CComVariant			result;
13	HRESULT hr = worksheet->Invoke(dispid, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYGET, &disp_params, &result, nullptr, nullptr);
14
15	CComDispatchDriver range = result.pdispVal;
16	result.Clear();
17
18	// dispid を Range.Value の DISPID へ変更。
19	hr = range->Invoke(dispid, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYGET, nullptr, &result, nullptr, nullptr);
20	
21	//この時点で、params の値が "A1:B2" から、セルA1の値に変更されている。
22	
23	CComSafeArray<VARIANT> source = result.parray;
24}

###補足
知りたいことの項番2については自身でも検証中ですので、解決したらこちらに追記します。
ただ、項番1については調べた限りでは原因が特定できずにおりますので、お力添え頂けますと幸甚です。

ちなみにこの事象で困っていることですが、
result を CComVariant 型にしている為、result のスコープを抜けると result に VariantClear が実行されます。
その後で params のスコープを抜ける際、こちらも CComVariant 型ですので VariantClear をするわけですが、
既に result.parray[1][1] に対して SysFreeString が実行されている為、例外が投げられてしまいます。

ですので、短絡的には params を VARIANT 型にして、VariantClear を明示しなければ解決とは思いますが、
当事象が必ず発生することが確約できない限り、解放を明示しないのは宜しくないと考えた為質問させて頂いております。
###追記
知りたいことの項番2について、
2回目の IDispatch::Invoke() の実行前に params.Clear() を実行することで事象は発生しませんでした。

Bull

2021/02/20 02:38

MSVC でしたら #import "～" で、タイプライブラリを読込んだ方が簡単だと思いますが、なぜわざわざ Invoke しているのでしょうか？

subka

2021/02/20 06:01

import を使用しない手法で実装してみたいからです。後、Excelのバージョンに依存しない為です。複数バージョンでも対応できる手法が存在する様ですが、impot の処理の周りをあまり理解しておらず、子細を把握できませんでした。質問とは別件になりますが、そういった処理の詳細が分かりやすく記載されているサイトなどがあればご紹介頂けませんでしょうか。併せて、質問本文の事象についても思い当たる原因がございましたらご教示頂けますと幸甚です。

Bull

2021/02/20 08:08

まあ、#import を使用しなければ、別のコンパイラ (たとえば gcc ) でもコンパイルできますしね。 Invoke する方法はすごく面倒で、情報が少なくてやっている人もあまりいないような気がします。必然的に回答も少なくなるのではないでしょうか。もっともタイプライブラリを使う方法も、最近は情報があまりなくなってしまっているようです。 import するタイプライブラリ (のフォルダ) はインストールしてある Excel のバージョンに依存しますが、実行時には依存しませんよ。複数の環境でコンパイルする必要があるなら、#ifdef ～で import するタイプライブラリを分ける手法もあります。申し訳ありませんが、回答するほどの知見も経験もありません。タイプライブラリに関することでしたら多少は答えられるかも知れませんが。

subka

2021/02/20 10:10

ご丁寧にありがとうございました。確かに、そもそもC++でエクセルを操作すること自体あまりないでしょうし、思う様に情報が集まらないことが多いですね。 C#が使える要件なら間違いなくC#で実装しますし。ちなみに、Invoke はそのまま扱うのは面倒ですが、実際は Docs に記載のある AutoWrap を参考にラップしているので、予想外の挙動が起きなければそこまで扱いは面倒ではないですね。可読性に欠けるのは否めませんが。タイプライブラリと Excel のバージョンはコンパイル環境にのみ依存するのですね。これが知れただけでも大助かりです。次に機会があれば import を使用する手法で進めたいとも思いますので、参考にさせて頂きます。