MS_COMMemoryLeak

COMのメモリ・リーク

• 戻る（メモリ・リーク、COM（MS_COM.md））
  • VC++のメモリ・リーク
  • COMのメモリ・リーク
  • WWWブラウザのメモリ・リーク

概要

• COM オブジェクトは参照カウンタで管理されている。
• COM オブジェクトは参照カウンタが 1 以上の状態では解放されない。
• VC++ では Release、VB6 では Set X = Nothing で参照カウンタをデクリメント。

移行メモ: 原文は「参照カウンタが1以上の状態では GC されない」としていたが、 COM に GC は無い。参照カウントが 0 になった時点で即座に自己破棄される仕組み。 「解放されない」に改めた。

.NETのCOM

• .NET では Marshal.ReleaseComObject を呼び出すのが推奨。
  RCW（Runtime Callable Wrapper）の GC で自動的に Release 処理されるが、解放遅延が発生する。
• RCW はファイナライズで自動的に Release するもよう。

移行メモ（誤記）: 原文の Marshall.ReleaseComObject は Marshal.ReleaseComObject（l は1つ、System.Runtime.InteropServices）。

実装上の注意

• ドット連鎖に注意。app.Workbooks.Open(...) のように書くと、
  中間の Workbooks の RCW が変数に残らず、明示的に解放できない。
  1つずつ変数に受けて、逆順に ReleaseComObject する。
• ReleaseComObject は参照カウントを1つ減らすだけなので、
  完全に解放したい場合は FinalReleaseComObject を使うか、戻り値が 0 になるまでループする。
• Office のサーバーサイド利用（Office サーバー サイド オートメーション: MS_OfficeServerSideAutomation.md）は
  そもそも Microsoft が非サポートとしている。プロセスが残留する典型例。

補足（最新化）: .NET Core / .NET 5 以降でも Marshal.ReleaseComObject は Windows 限定で利用できるが、 ランタイムは「明示解放より、スコープを短くして GC に任せる」設計を推奨している。 確実に解放したい場合は、COM を使う処理を別プロセスに隔離するのが安全。

参考

• メモリ・リーク
• Marshal.ReleaseComObject - Microsoft Learn
• ランタイム呼び出し可能ラッパー - Microsoft Learn

---

Tags: 障害対応, 性能, デバッグ