前書き
.NETを使ったOfficeの自動化が面倒なはずがない
―そう考えていた時期が俺にもありました。
以下のPowerShellのコードを見てみましょう。
$app = New-Object -ComObject Excel.Application
$books = $app.Workbooks
$book = $books.Open("test.xlsx")
Write-Host $book.Sheets["Sheet1"].Cells[1,1].Text
$book.Close()
$app.Quit();Excelを立ち上げて、シートのセルを表示し、Excelを終了するコードです。
本来であれば、なんの問題もありません。
しかしながら、起動したExcelのプロセスは終了せずタスクマネージャーに残り続けます。
今回はExcelで説明しましたが、これはWordでもOutlookでも同様です。また、PowerShellでなくC#で同様の実装をしても、この問題は発生します。
何が問題なのか？
Office オートメーションで割り当てたオブジェクトは、自分で解放する必要があります。
解放処理を適切に行わないことで、予期せぬ動作や、メモリの圧迫を引き起こします。
解放処理のベストプラクティスについてはマイクロソフトの中の人が以下のような記事をあげています。
Office オートメーションで割り当てたオブジェクトを解放する – Part1
Office オートメーションで割り当てたオブジェクトを解放する – Part2
.NETでOfficeの操作をする場合は必ず一読しておくことをお勧めします。
上記、記事のポイントとしては以下の通りです。
・作成されたRCWはReleaseComObjectで解放を行う
・Officeのアプリケーションの終了前後にガベージコレクトを実行する
作成されたReleaseComObjectで解放処理を行う。
New 演算子で Excel.Application クラス等を生成すると、RCW (ランタイム呼び出し可能ラッパー) も生成され COM オブジェクトのインスタンスを管理することになります。
ここで作成したRCWはReleaseComObjctを実行して参照カウントを減算します。これを行わないとオブジェクトが解放されずに予期せぬ動作を引き起こします。
# ここでRCWが作成される。
$app = New-Object -ComObject Excel.Application
$app.Quit()
# 作成したオブジェクトはReleaseComObjectを用いて解放する。
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app)
COMオブジェクトは暗黙的に作成されることがあり、以下のケースがそれにあたります。
# ここでRCWが作成される。
$app = New-Object -ComObject Excel.Application
# 暗黙的に「Microsoft.Office.Interop.Excel.Workbooks」オブジェクトが作成される。
Write-Host $app.WorkBooks.Count
$app.Quit()
# 作成したオブジェクトはReleaseComObjectを用いて解放する。
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app)
上記の暗黙的に作成されるCOMオブジェクトも解放処理を記載する必要があります。
つまり、以下のように実装する必要があります。
# ここでRCWが作成される。
$app = New-Object -ComObject Excel.Application
$books = $app.WorkBooks
Write-Host $books.Count
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($books)
$app.Quit()
# 作成したオブジェクトはReleaseComObjectを用いて解放する。
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app)
How to properly release Excel COM objectsで述べているように「1 dot good, 2 dots bad」と覚えると楽だと思います。
Officeのアプリケーションの終了前後にガベージコレクトを実行する
Office 開発系サポートの提唱するいわゆる「ベストプラクティス」ではOfficeのアプリケーションの終了前後に明示的にガベージコレクトを実行することを薦めています。
アプリケーションの終了時には、Excel からの COM オブジェクトの参照解放処理が行われます。このタイミングまでに適切に COM オブジェクトが解放されていないと、ガベージコレクトのタイミングによっては予期せぬエラーが生じる場合があります。このため、アプリケーションの終了前にまずガベージコレクトを実行します。
さらに、Application インスタンスを解放する際なのですが、Marshal.ReleaseComObject メソッドを使用して参照カウンタをデクリメントしただけでは、プロセスが終了することを保証できませんので、GC.Collect メソッドでガベージコレクトを強制してオブジェクトを解放しています。
つまりいわゆる「ベストプラクティス」では以下のようになります。
# ここでRCWが作成される。
$app = New-Object -ComObject Excel.Application
$books = $app.WorkBooks
Write-Host $books.Count
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($books)
# GCの対象になるようにNULLをいれて変数の参照を切る
$books = $null
Remove-Variable books -ErrorAction SilentlyContinue
# アプリケーション終了前のGC
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
$app.Quit()
# 作成したオブジェクトはReleaseComObjectを用いて解放する。
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app)
# GCの対象になるようにNULLをいれて変数の参照を切る
$app = $null
Remove-Variable app -ErrorAction SilentlyContinue
# アプリケーション終了前のGC
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
また、以下のようにReleaseComObjectなしのガベージコレクトだけでExcelのプロセスは終了して一見正しく動いているように見えます。
# ここでRCWが作成される。
$app = New-Object -ComObject Excel.Application
$books = $app.WorkBooks
Write-Host $books.Count
# GCの対象になるようにNULLをいれて変数の参照を切る
$books = $null
Remove-Variable books -ErrorAction SilentlyContinue
# アプリケーション終了前のGC
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
$app.Quit()
# GCの対象になるようにNULLをいれて変数の参照を切る
$app = $null
Remove-Variable app -ErrorAction SilentlyContinue
# アプリケーション終了前のGC
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
「Office オートメーションで割り当てたオブジェクトを解放する – Part2」のTipsではこの危険性を訴えています。
Null 代入の後、GC.Collect メソッドを実行するだけで良いように見える場合があります (例. EXCEL.EXE プロセスが終了するなど) が、これは非常に危険な方法です。
RCW への参照を残しているままの状態では、COM オブジェクト生成や参照等を繰り返した際に、例えば開発者が解放済みと考えている COM オブジェクトに対して接続しに行くなど、正しい COM オブジェクトに対する接続が実施できる保障ができなくなります。
なお、このベストプラクティスはあくまでOfficeアプリケーションのCOM解放処理のベストプラクティスであって、全てのベストプラクティスではありません。
サーバーサイドでガベージコレクトを明示的に実行することは、ベストではありません。
ベストプラクティスとその問題点
前書きに以下のようなコードを記載しました。
$app = New-Object -ComObject Excel.Application
$books = $app.Workbooks
$book = $books.Open("test.xlsx")
Write-Host $book.Sheets["Sheet1"].Cells[1,1].Text
$book.Close()
$app.Quit();このベストプラクティスは以下のようになります。
$app = New-Object -ComObject Excel.Application
$books = $app.Workbooks
$book = $books.Open("test.xlsx")
$sheets = $book.Sheets
$sheet = $sheets["Sheet1"]
$cells = $sheet.Cells
$cell = $cells[1,1]
Write-Host $cell.Text
$book.Close()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($cell) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($cells) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($sheet) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($sheets) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($book) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($books) | Out-Null
$cell = $null
Remove-Variable cell -ErrorAction SilentlyContinue
$cells = $null
Remove-Variable cells -ErrorAction SilentlyContinue
$sheet = $null
Remove-Variable sheet -ErrorAction SilentlyContinue
$sheets = $null
Remove-Variable sheets -ErrorAction SilentlyContinue
$book = $null
Remove-Variable book -ErrorAction SilentlyContinue
$books = $null
Remove-Variable books -ErrorAction SilentlyContinue
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
$app.Quit();
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app) | Out-Null
$app = $null
Remove-Variable app -ErrorAction SilentlyContinue
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()C#の例
using Excel = Microsoft.Office.Interop.Excel;
// 略
static void test1()
{
{
Excel.Application app = new Excel.Application();
{
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
Excel.Sheets sheets = book.Sheets;
Excel.Worksheet sheet = sheets["Sheet1"];
Excel.Range cells = sheet.Cells;
Excel.Range cell = cells[1, 1];
Console.WriteLine(cell.Value);
book.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.ReleaseComObject(cell);
Marshal.ReleaseComObject(cells);
Marshal.ReleaseComObject(sheet);
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
}
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
app.Quit();
Marshal.ReleaseComObject(app);
}
// Application オブジェクトのガベージ コレクトを強制します。
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
}いわゆるベストプラクティスではコードのステップ数が数倍になっていることがわかります。
また、ReleaseComObjectによるオブジェクトの解放漏れを検知することが非常に厄介です。
上記のコードで仮にReleaseComObjectをいくつか漏らしても、それを検知することは困難です。
先に説明したようにEXCELのプロセスが終了するなどの事象で解放漏れが起きているかどうかを検知することは難しいです。
また、暗黙的に作成されるCOMオブジェクトは、プログラマが意図せぬタイミングでおこなわれます。
たとえば以下のコードを10分ほど読んで見て解放漏れを考えてみてください。
Excel.Application app = new Excel.Application();
{
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
Excel.Sheets sheets = book.Sheets;
foreach(Excel.Worksheet sheet in sheets)
{
Console.WriteLine(sheet.Name);
Marshal.ReleaseComObject(sheet);
Console.ReadLine();
}
Console.WriteLine("Excel起動済み");
Console.ReadLine();
book.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
}
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ReleaseComObject");
Console.ReadLine();
}
// Application オブジェクトのガベージ コレクトを強制します。
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.WriteLine("ガベージコレクション済み");
Console.ReadLine();実は下記のコードのforeach句で「System.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariant」からCOMオブジェクトが作成されてしまいます。
foreach(Excel.Worksheet sheet in sheets)
{
Console.WriteLine(sheet.Name);
Marshal.ReleaseComObject(sheet);
Console.ReadLine();
}そのため、以下のようにforeachを使わずにCOMオブジェクトを操作した方が安全です。
for (int i = 1; i <= sheets.Count; ++i)
{
Excel.Worksheet sheet = book.Sheets[i];
Console.WriteLine(sheet.Name);
Marshal.ReleaseComObject(sheet);
Console.ReadLine();
}このように、挙動を理解した上でソースコードを読み込まないとベストプラクティスのメモリ解放を実現することができないのです。
いわゆる「ベストプラクティス」の問題点の対応策
ソースコードを読まないと適切にメモリ解放をしているかわからない、かつ、タスクマネージャーだけではメモリが正しく解放されたかどうかを検知するのが困難であることがわかりました。
さすがに令和の時代にメモリ解放を気にして実装するのは辛いものがあるので、この状況を改善する方法について検討してみます。
NetOfficeを使用してCOMオブジェクトの解放を任せる
NetOfficeというMIT Licenseのオープンソースのライブラリが存在します。
https://github.com/NetOfficeFw/NetOffice
Officeの各オブジェクトをラッパーしてReleaseComObjectを行わなくてもすむようになっています。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Excel = NetOffice.ExcelApi;
namespace NetOfficeSample
{
class Program
{
static void Main(string[] args)
{
using (Excel.Application app = new Excel.Application()) {
Excel.Workbook book = app.Workbooks.Open(@"test.xlsx");
Excel.Worksheet workSheet = (Excel.Worksheet)book.Worksheets[1];
Console.WriteLine(workSheet.Cells[1, 1].Value);
Console.WriteLine("起動済み");
Console.ReadLine();
book.Close();
app.Quit();
}
Console.WriteLine("Application終了");
Console.ReadLine();
}
}
}ただし、NetOfficeのコードをみるかぎりガベージコレクトを明示的にやっていないようにみえるので、いわゆるベストプラクティスとは違う部分があります。
RCWのオブジェクトの状況を監視する。
RCW (ランタイム呼び出し可能ラッパー) のオブジェクトの解放状況を監視しながら実装する方法もあります。
そのためには、マネージドヒープを監視するためのライブラリ、Microsoft.Diagnostics.Runtime.dll (nicknamed "CLR MD")を利用します。
https://github.com/microsoft/clrmd
なお、ウィルスバスターなどのウィルス対策ソフトは、このライブラリを使用して別プロセスにアタッチしてマネージドヒープを調べる操作を「怪しい操作」とみなすので、除外リストに入れて対応してください。
以下で説明するCOMの解放漏れをチェックするツールについては下記にソースコードとバイナリがあるので必要に応じて使用してください。
https://github.com/mima3/MemoryCheck
RCWのオブジェクトを列挙するサンプル
マネージドヒープ中のRCWのオブジェクトを列挙するサンプルを以下に記載します。
using Microsoft.Diagnostics.Runtime;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace EnumRcw
{
class Program
{
static void Main(string[] args)
{
foreach (var process in System.Diagnostics.Process.GetProcessesByName(args[0]))
{
int pid = process.Id;
Console.WriteLine("{0} {1} =======================================================", args[0], pid);
using (var dataTarget = DataTarget.AttachToProcess(pid, 1000))
{
Console.WriteLine(dataTarget.Architecture);
var clrVersion = dataTarget.ClrVersions.First();
var dacInfo = clrVersion.DacInfo;
ClrRuntime runtime = clrVersion.CreateRuntime();
foreach (var obj in runtime.Heap.EnumerateObjects())
{
ClrType type = obj.Type;
ulong size = obj.Size;
if (type.IsRCW(obj))
{
RcwData rcw = type.GetRCWData(obj);
if (rcw != null)
{
string ifname = "";
foreach (var i in rcw.Interfaces)
{
ifname += i.Type.Name + ",";
}
Console.WriteLine("{0,16:X} {1,12:n0} {2} {3} {4} {5}", obj.Address, size, type.Name, rcw.RefCount, rcw.Disconnected, ifname);
}
else
{
Console.WriteLine("{0,16:X} {1,12:n0} {2} (GetRCWDataに失敗)", obj.Address, size, type.Name);
}
}
}
}
}
}
}
}
このプログラムは指定のプロセスにアタッチして、マネージドヒープ中のRCWオブジェクトを列挙します。
この際、アタッチ対象のプロセスと同じになるように、プラットフォームのターゲットをX86/X64を明示してください。
コマンドラインからプロセス名🅂を指定することで、現在のヒープ中のRCWのオブジェクトを列挙します。
以下のサンプルは「foreach(Excel.Worksheet sheet in sheets)」のブロック内におけるRCWのオブジェクトを列挙した例になります。
>EnumRcw プロセス名
memorycheck 18688 =======================================================
Amd64
25601C57CE8 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
25601C57D08 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
25601C58348 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
25601C58368 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Sheets,
25601C58C78 32 System.__ComObject 1 False
25601C58DA8 32 System.__ComObject (GetRCWDataに失敗)指定のオブジェクトを参照しているオブジェクトを探す
Microsoft.Diagnostics.Runtime.dll では指定のオブジェクトがGCのルートから、どのパスで参照されているか確認することもできます。
https://blog.maartenballiauw.be/post/2017/01/03/exploring-.net-managed-heap-with-clrmd.html
using Microsoft.Diagnostics.Runtime;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace WalkHeap
{
class Program
{
static void Main(string[] args)
{
string name = args[0];
foreach (var process in System.Diagnostics.Process.GetProcessesByName(args[0]))
{
int pid = process.Id;
Console.WriteLine("{0} {1} =======================================================", args[0], pid);
ulong taregetPtr = ulong.Parse(args[1], System.Globalization.NumberStyles.HexNumber);
using (var dataTarget = DataTarget.AttachToProcess(pid, 1000))
{
var clrVersion = dataTarget.ClrVersions.First();
var dacInfo = clrVersion.DacInfo;
ClrRuntime runtime = clrVersion.CreateRuntime();
var stack = new Stack<ulong>();
var heap = runtime.Heap;
if (heap.CanWalkHeap)
{
Console.WriteLine("-----");
foreach (var ptr in heap.EnumerateObjectAddresses())
{
var type = heap.GetObjectType(ptr);
if (type == null || taregetPtr != ptr)
{
continue;
}
Console.WriteLine("find");
// todo: retention path
Console.WriteLine("roots...");
foreach (var root in heap.EnumerateRoots())
{
stack.Clear();
stack.Push(root.Object);
if (GetPathToObject(heap, ptr, stack, new HashSet<ulong>()))
{
// Print retention path
var depth = 0;
foreach (var address in stack)
{
var t = heap.GetObjectType(address);
if (t == null)
{
Console.WriteLine("{0} {1,16:X} ", new string('+', depth++), address);
continue;
}
Console.WriteLine("{0} {1,16:X} - {2} - {3} bytes", new string('+', depth++), address, t.Name, t.GetSize(address));
}
break;
}
}
break;
}
}
}
}
}
// https://blog.maartenballiauw.be/post/2017/01/03/exploring-.net-managed-heap-with-clrmd.html
private static bool GetPathToObject(ClrHeap heap, ulong objectPointer, Stack<ulong> stack, HashSet<ulong> touchedObjects)
{
// Start of the journey - get address of the first objetc on our reference chain
var currentObject = stack.Peek();
// Have we checked this object before?
if (!touchedObjects.Add(currentObject))
{
return false;
}
// Did we find our object? Then we have the path!
if (currentObject == objectPointer)
{
return true;
}
// Enumerate internal references of the object
var found = false;
var type = heap.GetObjectType(currentObject);
if (type != null)
{
type.EnumerateRefsOfObject(currentObject, (innerObject, fieldOffset) =>
{
if (innerObject == 0 || touchedObjects.Contains(innerObject))
{
return;
}
// Push the object onto our stack
stack.Push(innerObject);
if (GetPathToObject(heap, objectPointer, stack, touchedObjects))
{
found = true;
return;
}
// If not found, pop the object from our stack as this is not the tree we're looking for
stack.Pop();
});
}
return found;
}
}
}
コマンドラインから以下のようにプロセス名とオブジェクトのアドレスを指定して実行することで、指定のプロセスのオブジェクトが、どのように参照されているか表示します。
>WalkHeap.exe memorycheck 25601C58C78
memorycheck 18688 =======================================================
-----
find
roots...
25601C58C78 - System.__ComObject - 32 bytes
+ 25601C58CD0 - System.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariant - 40 bytes
RCWの解放状況の検証
ヒープ上のRCWの状況を検査する方法が分かったので様々なケースで実験してみようと思います。
OS
Windows10 64bit
Excel
Office16 Excel32bit
PowerSehll
5.1.17134.858(64bit)
操作側のアプリ:
.NET Framework4.5.2
64bit
Releaseビルド
debugビルドだと挙動が変わる可能性があります。
実験１ アプリケーションの解放漏れがあるケース
//using Excel = Microsoft.Office.Interop.Excel;
static void t1()
{
Excel.Application app = new Excel.Application();
app.Quit();
Console.WriteLine("ここでヒープのチェックを行う");
Console.ReadLine();
}結果：
memorycheck 20140 =======================================================
Amd64
19880007BE0 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,Microsoft.Office.Interop.Excel.ApplicationClassが解放されずに残っていることがわかります。
実験２ アプリケーションの解放をReleaseComObjectで行った場合
//using Excel = Microsoft.Office.Interop.Excel;
static void t1_2()
{
Excel.Application app = new Excel.Application();
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う");
Console.ReadLine();
}
結果：
memorycheck 16108 =======================================================
-----Microsoft.Office.Interop.Excel.ApplicationClassが解放されていることが確認できます。
実験３ アプリケーションの解放をガベージコレクションだけで行った場合
//using Excel = Microsoft.Office.Interop.Excel;
static void t1_3()
{
Excel.Application app = new Excel.Application();
app.Quit();
app = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.WriteLine("ここでヒープのチェックを行う t1_3");
Console.ReadLine();
}結果:
memorycheck 8664 =======================================================
Amd64Microsoft.Office.Interop.Excel.ApplicationClassが解放されていることが確認できます。
なお、デバッグビルドの場合は以下のようになります。
memorycheck 19908 =======================================================
Amd64
1B583A77BD8 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,これはデバッグ実行の場合、オブジェクトの生存期間が異なるためです。
実験４ 暗黙の参照が作成されるケース
//using Excel = Microsoft.Office.Interop.Excel;
static void t2()
{
Excel.Application app = new Excel.Application();
// Workbooksの暗黙のオブジェクトの作成
Excel.Workbook book = app.Workbooks.Open(@"test.xlsx");
Console.WriteLine("ここでヒープのチェックを行う1");
Console.ReadLine();
book.Close();
Marshal.ReleaseComObject(book);
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う2");
Console.ReadLine();
}結果：
1回目のメモリの内容
memorycheck 21916 =======================================================
Amd64
1D04E377CE8 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
1D04E377D08 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
1D04E378348 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
2回目のメモリの内容
memorycheck 21916 =======================================================
Amd64
1D04E377D08 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
1D04E378348 32 System.__ComObject (GetRCWDataに失敗)Microsoft.Office.Interop.Excel.Workbooksのオブジェクトが暗黙的に作成されていることがわかります。
この暗黙的なオブジェクトを解放しない場合、「Microsoft.Office.Interop.Excel._Workbook」のオブジェクトが中途半端に残っていることも確認できます。
実験５ 暗黙の参照が作成しないように修正したケース
static void t2_1()
{
Excel.Application app = new Excel.Application();
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
Console.WriteLine("ここでヒープのチェックを行う1 t_1");
Console.ReadLine();
book.Close();
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う2");
Console.ReadLine();
}結果：
1回目のメモリの状態：
memorycheck 22292 =======================================================
Amd64
12E47377CF0 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
12E47377D10 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
12E47378350 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
2回目のメモリの状態：
memorycheck 22292 =======================================================
Amd64作成したオブジェクトが全て削除されていることが確認できます。
実験６ for eachを用いた繰り返しの場合
static void t3()
{
Excel.Application app = new Excel.Application();
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
foreach (var sheet in book.Sheets)
{
Console.WriteLine("ここでヒープのチェックを行う1(ループ内) t3");
Console.ReadLine();
Marshal.ReleaseComObject(sheet);
}
Console.WriteLine("ここでヒープのチェックを行う2 ループ完了 t3");
Console.ReadLine();
book.Close();
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う3");
Console.ReadLine();
}結果：
1:ループ内のメモリの状態
memorycheck 17784 =======================================================
Amd64
1C74A3B7D50 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
1C74A3B7D70 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
1C74A3B83B0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
1C74A3B83D0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Sheets,
1C74A3B8CE0 32 System.__ComObject 1 False
1C74A3B8E10 32 System.__ComObject 1 False
2: 1C74A3B8CE0の参照箇所を調べる
-----
find
roots...
1C74A3B8CE0 - System.__ComObject - 32 bytes
+ 1C74A3B8D38 - System.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariant - 40 bytes
3: 1C74A3B8E10 の参照箇所を調べる
-----
find
roots...
1C74A3B8E10 - System.__ComObject - 32 bytes
4： ループ外でのメモリの状態
memorycheck 17784 =======================================================
Amd64
1C74A3B7D50 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
1C74A3B7D70 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
1C74A3B83B0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
1C74A3B83D0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Sheets,
1C74A3B8CE0 32 System.__ComObject 1 False
1C74A3B8E10 32 System.__ComObject (GetRCWDataに失敗)
5: 1C74A3B8CE0の参照箇所を調べる
-----
find
roots...
6: 1C74A3B8E10の参照箇所を調べる
-----
find
roots...
7: Officeアプリケーション終了後
memorycheck 17784 =======================================================
Amd64
foreachでループを行った場合、1C74A3B8CE0が暗黙的に作成されていることがわかります。このオブジェクトはSystem.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariantから参照されていましたが、ループを抜けると、どこからも参照されずゴミとして残ってしまいます。
※Officeの終了で削除されるが、その間、予期せぬオブジェクトが残り続ける
実験７ for eachを排除した繰り返しの場合
static void t3_1()
{
Excel.Application app = new Excel.Application();
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
Excel.Sheets sheets = book.Sheets;
for (int i = 1; i <= sheets.Count; ++i)
{
var sheet = sheets[i];
Console.WriteLine("ここでヒープのチェックを行う1(ループ内) t3-1");
Console.ReadLine();
Marshal.ReleaseComObject(sheet);
}
Console.WriteLine("ここでヒープのチェックを行う2 ループ完了 t3");
Console.ReadLine();
book.Close();
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う3");
Console.ReadLine();
}ループ内のメモリの状態：
memorycheck 17612 =======================================================
Amd64
29107A77D90 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
29107A77DB0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
29107A783F0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
29107A78410 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Sheets,
29107A78480 32 System.__ComObject 1 False
ループ外のメモリの状態：
memorycheck 17612 =======================================================
Amd64
29107A77D90 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
29107A77DB0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
29107A783F0 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
29107A78410 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Sheets,
29107A78480 32 System.__ComObject (GetRCWDataに失敗)
Officeアプリケーション終了後のメモリの状態
memorycheck 17612 =======================================================
-----
foreachで暗黙的に作成されたSystem.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariantからの参照されているSystem.__ComObjectが存在しないことがわかります。
実験８ RCWのオブジェクトを別の変数に格納した場合
//using Excel = Microsoft.Office.Interop.Excel;
static void t4()
{
Excel.Application app = new Excel.Application();
Excel.Workbooks books = app.Workbooks;
Excel.Workbook book = books.Open(@"test.xlsx");
var book2 = book;
Console.WriteLine(book.Name);
Console.WriteLine(book2.Name);
Console.WriteLine("ここでヒープのチェックを行う1 t_1");
Console.ReadLine();
book.Close();
Marshal.ReleaseComObject(book);
Marshal.ReleaseComObject(books);
app.Quit();
Marshal.ReleaseComObject(app);
Console.WriteLine("ここでヒープのチェックを行う2");
Console.ReadLine();
}結果：
1回目：
MemoryCheck 15648 =======================================================
Amd64
1FC94A97CF0 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False Microsoft.Office.Interop.Excel._Application,
1FC94A97D10 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,Microsoft.Office.Interop.Excel.Workbooks,
1FC94A98350 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel._Workbook,
2回目：
MemoryCheck 15648 =======================================================
Amd64
1回目のメモリの内容確認でExcel.Workbookをbookとbook2変数に格納していますが、RCWのオブジェクト自体が増加しておらず、かつ、参照カウンタが１のままであることが確認できます。
2回目のbook変数のみにたいしてReleaseComObjectを行うことでRCWオブジェクトが削除されることも確認できます。
実験９：PowerShellで実行した場合
test2.ps1
Read-Host "初期状態"
$app = New-Object -ComObject Excel.Application
$books = $app.Workbooks
$book = $books.Open("test.xlsx")
$sheets = $book.Sheets
$sheet = $sheets["Sheet1"]
$cells = $sheet.Cells
$cell = $cells[1,1]
Write-Host $cell.Text
#Write-Host $cell.Value # Variant Value (Variant)が表示される
#$cell.Value = "TEST"
#Write-Host $cell.Text
$book.Close()
Read-Host "①起動済み"
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($cell) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($cells) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($sheet) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($sheets) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($book) | Out-Null
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($books) | Out-Null
Read-Host "②ReleaseComObject"
$cell = $null
Remove-Variable cell -ErrorAction SilentlyContinue
$cells = $null
Remove-Variable cells -ErrorAction SilentlyContinue
$sheet = $null
Remove-Variable sheet -ErrorAction SilentlyContinue
$sheets = $null
Remove-Variable sheets -ErrorAction SilentlyContinue
$book = $null
Remove-Variable book -ErrorAction SilentlyContinue
$books = $null
Remove-Variable books -ErrorAction SilentlyContinue
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
$app.Quit();
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($app) | Out-Null
$app = $null
Remove-Variable app -ErrorAction SilentlyContinue
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
[System.GC]::Collect()
Read-Host "すべて終了"結果：
1: スクリプト実行前
powershell 1656 =======================================================
Amd64
2873E065E98 32 System.__ComObject 1 False Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics,
2: スクリプト実行して「初期状態」が表示された時点の状態
powershell 1656 =======================================================
Amd64
2873E065E98 32 System.__ComObject 1 False Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics,
2873E709130 32 System.__ComObject (GetRCWDataに失敗)
※2873E709130はルートから検索できない
3:「①起動済み:」が表示された時点の状態
powershell 1656 =======================================================
Amd64
2873E065E98 32 System.__ComObject 1 False Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics,
2873E7B2618 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False System.Management.Automation.IDispatch,Microsoft.Office.Interop.Excel._Application,
2873E7BA850 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E87F860 32 System.__ComObject 1 False Microsoft.Office.Interop.Excel.Workbooks,System.Management.Automation.ComInterop.IDispatch,
2873E891FE0 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E8DD090 32 System.__ComObject 1 False System.Management.Automation.ComInterop.IDispatch,
2873E8EF398 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E93BB10 32 System.__ComObject 1 False System.Management.Automation.ComInterop.IDispatch,
2873E94AE08 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E9A66A0 32 System.__ComObject 1 False System.Management.Automation.ComInterop.IDispatch,
2873E9B7928 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E9F5C90 32 System.__ComObject 1 False System.Management.Automation.ComInterop.IDispatch,
2873EA05D48 32 System.__ComObject 2 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873EA6ED78 32 System.__ComObject 1 False System.Management.Automation.ComInterop.IDispatch,
※2873E709130は消えている
4:「②ReleaseComObject:」が表示された時点の状態
powershell 1656 =======================================================
Amd64
2873E065E98 32 System.__ComObject 1 False Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics,
2873E6B77C0 32 System.__ComObject (GetRCWDataに失敗)
2873E6C5288 32 System.__ComObject (GetRCWDataに失敗)
2873E6DBB58 32 System.__ComObject (GetRCWDataに失敗)
2873E6E0058 32 System.__ComObject (GetRCWDataに失敗)
2873E6F11D8 32 System.__ComObject (GetRCWDataに失敗)
2873E715028 32 System.__ComObject (GetRCWDataに失敗)
2873E7B2618 32 Microsoft.Office.Interop.Excel.ApplicationClass 1 False System.Management.Automation.IDispatch,Microsoft.Office.Interop.Excel._Application,
2873E7BA850 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
5:「すべて終了」が表示された時点の状態
powershell 1656 =======================================================
Amd64
2873E065E98 32 System.__ComObject 1 False Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics,
2873E7BA850 32 System.__ComObject 1 False System.Runtime.InteropServices.ComTypes.ITypeInfo,
2873E7BA850の検索結果は以下の通り
2873E7BA850 - System.__ComObject - 32 bytes
+ 2873E7BAEA8 - System.Management.Automation.ComProperty - 64 bytes
++ 2873E7E1738 - System.Collections.Generic.Dictionary+Entry<System.String,System.Management.Automation.ComProperty>[] - 10368 bytes
+++ 2873E7BA950 - System.Collections.Generic.Dictionary<System.String,System.Management.Automation.ComProperty> - 80 bytes
++++ 2873E7BA918 - System.Management.Automation.ComTypeInfo - 56 bytes
+++++ 2873E7EC398 - System.Management.Automation.DotNetAdapterWithComTypeName - 32 bytes
++++++ 2873E7EC3B8 - System.Management.Automation.PSObject+AdapterSet - 32 bytes
+++++++ 2873E7EC3D8 - System.Collections.Concurrent.ConcurrentDictionary+Node<System.Type,System.Management.Automation.PSObject+AdapterSet> - 48 bytes
++++++++ 2873E3FD9B8 - System.Collections.Concurrent.ConcurrentDictionary+Node<System.Type,System.Management.Automation.PSObject+AdapterSet>[] - 272 bytes
+++++++++ 2873E3FDAC8 - System.Collections.Concurrent.ConcurrentDictionary+Tables<System.Type,System.Management.Automation.PSObject+AdapterSet> - 48 bytes
++++++++++ 2873E3FD8B8 - System.Collections.Concurrent.ConcurrentDictionary<System.Type,System.Management.Automation.PSObject+AdapterSet> - 64 bytesPowerShellでは初期状態で「Windows.Foundation.Diagnostics.IAsyncCausalityTracerStatics」のCOMオブジェクトが存在しています。
いわゆるベストプラクティスを守ったスクリプトを実行しても、操作終了後に「System.Runtime.InteropServices.ComTypes.ITypeInfo」が残ります。このオブジェクトはSystem.Collections.Concurrent.ConcurrentDictionary<System.Type,System.Management.Automation.PSObject+AdapterSet>から参照されています。
※以下のs_adapterMappingのように見えるが詳細は不明。
https://github.com/PowerShell/PowerShell/blob/c684902fba5b5e63fa750e66270a25b6889b4ec6/src/System.Management.Automation/engine/MshObject.cs
まとめと意識の低い対応策
.NETでOfficeオートメーションを使用する場合、いわゆるベストベストプラクティスは以下のようになります。
・アプリケーションで作成したRCWオブジェクトはReleaseComObjectで解放します
・RCWオブジェクトは暗黙的に作成される場合があります。
例：
foreach句
「app.WorkBooks.Count」で2ドット含む場合
・Officeオートメーションの解放だけを考えた場合、Officeの終了前後でガベージコレクトを実行する。
正直面倒…さらにいうとサーバー側のプログラムでガベージコレクトを実行するのは、よくないです。
ここでは、意識を低くして対応策を考えてみます。
「Office オートメーションで割り当てたオブジェクトを解放する – Part1」によると以下のような記述があります。
なお、コンソール アプリケーション等では、処理が一通り実行された後、プロセスが終了する際に CLR ランタイムが終了するのに合わせて、Application オブジェクトの解放および EXCEL.EXE プロセスの終了が実施されます。そのため、解放漏れがあったとしても、プログラム終了時に解放されるため、ほとんどの場合大きな影響がない傾向があります。
すなわち、 Officeの操作をして、すぐプロセスを終了すると影響が少なくできると考えられます。
なので、別プロセスで起動して単一のOfficeの操作を行い、すぐ終了するという設計にすることで、Officeの解放漏れを抑えられると考えられます。
たとえばPowerShellを実行する場合も以下のように別プロセスで実行してしまいます。
# PowerShellのコマンドプロンプトを落とすまで影響がのこる
./test1.ps1
# 別プロセスで実行することで影響を抑える
powershell ./test1.ps1あとはわりきって、完璧なリソース解放はあきらめて、操作中はOfficeを使用しないでくださいとか運用でカバーしたり、予期せぬOfficeのプロセスが起動してたら終了させるなどの意識の低い対処案が考えられます。
