while文ブロック内で宣言してみては？
_variant_tクラスのコンストラクタが自動的に解放するようになっているので、
MSDNのサンプルでClearメソッドを読んでいないのでしょう。

だめなようです。
下記のようにサンプル修正しましたが同様でした。
//↓↓↓↓以下サンプルコード抜粋

#import <msxml4.dll> named_guids raw_interfaces_only

// elmは既にyear属性のあるエレメントをセット
void CheckElementAttribute(MSXML2::IXMLDOMElement* elm) {
HRESULT hr;

while(1) {
_variant_t vr;
vr = _T(test);
//getAttributeは成功して値取得する。
hr = elm->getAttribute(_bstr_t(_T(year)), &vr);
Sleep(50);
}
}

//↑↑↑↑以上
通常では_variant_tクラスは値が入力された際に前値Clear()をするようです。
ついでに関数内部のwhileを削除してCheckElementAttribute関数をループさせても同様
でした。

>通常では_variant_tクラスは値が入力された際に前値Clear()をするようです。

確かに_variant_tクラスは値の代入やデストラクタで値をクリアしますが、

> //getAttributeは成功して値取得する。
> hr = elm->getAttribute(_bstr_t(_T(year)), &vr);

ここで第２引数で実際に渡されている型はVARIANT*です。

つまりgetAttributeの実装がVariantClearを呼んでないならリークするんじゃないでしょ
うか。
事前にvr.Clear()を呼ぶが正解なのでは？

確かにおしゃっる通りの気がしてきました。
前述のMSDNのサンプルソース自体、かなりデタラメなようです。

素直にClear()しておきます。

ご教授どうもありがとうございました。

以下は推測やうろ覚え。
間違えかもしれない。

HRESULT getAttribute(
BSTR name,
VARIANT *value);

value[out, retval]

出力兼戻り値であり、VARIANTへのポインタだから、
getAttribute内で作られたVARIANTが返されるんでしょ。

[in,out] VARIANT * valueで、
呼び出し先が値を変更する場合であり
それが新たにメモリ確保が必要ならば
解放して新しいVARIANTを返すことはある。

どのみち、getAttribute内でvalue->Clear()は期待しない方がいいみたい。

サンプルが厳密なエラーチェックやメモリ解放していなくて
間違えて理解したということはよくあるね。
サンプルだからいいじゃないかというのもあるし、
間違えが広まるから困るというのもある。
ちょっとした説明で大量の余計な処理があるサンプルは使いにくいし
ややこしいところだな。

ネットに情報が多すぎるし、とくに特徴のない普通の英単語だし、
同じ単語のものがJava用、MSXML用、.NET用といろいろあり
なかなか検索で見つけるの大変だな。

> [in,out] VARIANT * valueで、
これは
もしも[in,out] VARIANT * valueだったらって話。

[out]、[out,retuval]ってなっているものは
解放済みVARIANTにすべきみたいだね。