【テクニカル・上級編】上級プロフェッショナル向け：VB.NETアプリケーションのメモリリーク検出と対策：WinDbgとdotMemoryを用いたマネージド・アンマネージド資源の徹底解析手法 – Visual Basic (VB / VB.NET)解析バイブル

伝説のチーフアーキテクトが贈る、VB.NETの真髄。
長年にわたり、VBAからVB.NET、そして最先端の.NET Coreに至るまで、数多のシステムと格闘してきた者として、今日のテーマは特に重い。それは「メモリリーク」。マネージド環境に身を置く開発者にとって、ある種の幻想と化しているこの問題に、我々は真摯に向き合わねばならない。

上級プロフェッショナル向け：VB.NETアプリケーションのメモリリーク検出と対策：WinDbgとdotMemoryを用いたマネージド・アンマネージド資源の徹底解析手法

長期稼働する業務システムにおいて、メモリリークは単なるパフォーマンス劣化に留まらず、システムダウン、データ破損、そしてビジネスロスの直接的な原因となる。特にVB.NETのようなマネージド環境下では、「ガベージコレクタがあるから大丈夫」という誤解が蔓延し、問題が深層化する傾向にある。しかし、我々は知っている。マネージド環境といえども、メモリリークは断じて発生する、という真実を。

本稿では、VB.NETアプリケーションにおけるメモリリークの深淵に迫り、その発生メカニズムから、WinDbgとdotMemoryという二つの強力な武器を用いた検出、そして根本的な対策までを、長年の経験と極限の知見に基づいて詳述する。対象読者は、現場でシステムの健全性を守るシニアエンジニア、そしてシステム管理者諸氏である。

1. メモリリークの真実：マネージド環境の落とし穴

ガベージコレクタ（GC）は、開発者のメモリ管理の負担を大きく軽減してくれる、まさに福音である。しかし、それは「参照されていないオブジェクト」を自動的に解放するメカニズムに過ぎない。もしオブジェクトへの参照がどこかに残り続けている限り、GCはそれを「生きているオブジェクト」と判断し、決して解放しない。これがマネージド環境におけるメモリリークの根源である。

VB.NETアプリケーションで特に注意すべきは以下の点だ。

• イベントハンドラの登録解除忘れ: `AddHandler`でイベントを購読したにも関わらず、`RemoveHandler`で解除しない場合、イベント発行元が破棄されない限り、購読側オブジェクトへの参照が残り続ける。`WithEvents`キーワードも例外ではない。
• 静的フィールド (Shared Field): アプリケーションの寿命と等しい寿命を持つため、ここに保持されたオブジェクトへの参照は、アプリケーション終了までGCの対象とならない。安易な利用はリークの温床となる。
• アンマネージド資源: Windows API経由で取得したファイルハンドル、ネットワークソケット、GDIオブジェクト、COMオブジェクト、ネイティブメモリなどはGCの管理外にある。これらは`IDisposable`パターンを用いて明示的に解放しなければならない。
• キャッシュやコレクションの肥大化: 適切に上限設定や破棄ロジックが組み込まれていないコレクションは、参照が残り続ける結果、無限にメモリを消費する。

これらの「意図しない参照」が、GCの目を掻い潜り、システムメモリを静かに、しかし確実に蝕んでいくのだ。

2. リーク検出の第一歩：メモリダンプの取得

メモリリーク解析の出発点は、問題発生時のアプリケーションの状態を正確に捉えた「メモリダンプ」の取得である。ダンプは、その瞬間のプロセスのアドレス空間全体をファイルに書き出したものであり、その後の解析の土台となる。

ダンプ取得ツールの選択

1. タスクマネージャー: 最も手軽な方法。プロセスの右クリックメニューから「ダンプファイルの作成」を選択する。これは「フルダンプ」に相当する。
2. Procdump (Sysinternals Suite): より高度な制御が可能。特定の条件（CPU使用率、メモリ使用量、例外発生など）で自動的にダンプを取得できるため、断続的に発生するリークの特定に非常に有効だ。

# 例: ProcessIDが1234のプロセスがPrivate Bytesが500MBを超えたらダンプを生成
procdump.exe -m 500 -o 1234 your_app_leak.dmp

# 例: ProcessNameが”YourApp.exe”のプロセスが、指定回数実行後または一定時間後にダンプを生成
# 複数ダンプを取得し、比較解析する際に有効
procdump.exe -s 5 -n 3 YourApp.exe your_app_leak_#.dmp

`-m` (メモリ閾値)、`-s` (秒数)、`-n` (ダンプ数) など、多くのオプションを使いこなすことで、狙った瞬間のダンプを確実に取得できる。

ダンプの種類と選択

• フルダンプ (Full Dump): プロセスの全メモリ空間、レジスタ情報、ハンドル情報など、あらゆる情報が含まれる。解析には最も有用だが、ファイルサイズが非常に大きくなる。
• ミニダンプ (Mini Dump): 必要最小限の情報のみを含む。ファイルサイズは小さいが、詳細な解析には不向きな場合がある。

リーク解析においては、情報量の多いフルダンプを基本とする。ただし、ディスク容量や転送時間を考慮し、状況に応じて判断する必要がある。

3. マネージドメモリの深層解析：dotMemoryの活用

JetBrains dotMemoryは、.NETアプリケーションのメモリプロファイリングに特化した商用ツールであり、その視覚的な参照グラフ解析能力は群を抜いている。マネージドメモリリークの原因特定において、これほど強力な武器は他にない。

典型的な解析フロー

1. スナップショットの取得:

• dotMemoryを起動し、リークが疑われるアプリケーションにアタッチする。
• アプリケーションの起動直後や、正常な状態の時に最初のスナップショット（ベースライン）を取得する。
• リークが進行すると予想される操作を何度か繰り返し、十分な時間が経過した後、二番目のスナップショットを取得する。

2. スナップショットの比較:

• 二つのスナップショットを比較することで、メモリ増加の原因となっているオブジェクトの種類と数を特定する。dotMemoryは、オブジェクトの生存期間、新しいオブジェクト、消滅したオブジェクトなどを明確に表示する。
• 特に「Dominator Tree」（支配的オブジェクトツリー）は重要だ。これは、あるオブジェクトがメモリから解放されるために、どのオブジェクトが解放される必要があるかを示す。ツリーの根元に近いオブジェクトほど、メモリリークの「真犯人」である可能性が高い。

3. 参照グラフの解析:

• リークが疑われるオブジェクト（例: 繰り返し生成されているにも関わらず、解放されていないカスタムクラスのインスタンス）を特定したら、そのオブジェクトの「参照グラフ」（`Object Set`タブの`Paths to Root`）を詳細に調査する。
• このグラフは、GCルート（スタック、静的フィールド、ハンドルなど）からそのオブジェクトに至るまでの参照パスを示す。このパス上に「意図しない参照」が存在すれば、それがリークの原因である。

コード例：イベントハンドラのリークシナリオとdotMemoryでの特定

.net
Imports System
Imports System.Threading
Imports System.Collections.Generic

‘ イベント発行元クラス
Public Class EventPublisher
Public Event MyEvent As EventHandler

Public Sub RaiseEvent()
‘ イベントを購読しているハンドラを呼び出す
RaiseEvent MyEvent(Me, EventArgs.Empty)
End Sub
End Class

‘ イベント購読側クラス
Public Class EventSubscriber
Private _name As String
Private WithEvents _publisher As EventPublisher ‘ VB.NETのWithEventsは便利だが注意が必要

Public Sub New(name As String, publisher As EventPublisher)
_name = name
_publisher = publisher
‘ WithEventsを使用しているため、明示的なAddHandlerは通常不要
‘ ただし、明示的にAddHandlerを行う場合もRemoveHandlerを忘れないこと
‘ AddHandler _publisher.MyEvent, AddressOf HandleMyEvent
Console.WriteLine($”{_name} がイベントを購読開始”)
End Sub

‘ イベントハンドラ
Private Sub HandleMyEvent(sender As Object, e As EventArgs) Handles _publisher.MyEvent
Console.WriteLine($”{_name}: イベントを受信しました！”)
End Sub

‘ 本来なら、このオブジェクトが不要になったときにイベント購読を解除すべき
‘ Public Sub Unsubscribe()
‘ RemoveHandler _publisher.MyEvent, AddressOf HandleMyEvent
‘ _publisher = Nothing ‘ 参照をクリア
‘ Console.WriteLine($”{_name} がイベント購読を解除”)
‘ End Sub

Protected Overrides Sub Finalize()
Console.WriteLine($”{_name} がFinalizeされました。”)
‘ FinalizeでRemoveHandlerを呼ぶことは推奨されない。
‘ イベント発行元の寿命がFinalizeより短い場合、エラーになる可能性があるため。
‘ 必ず明示的にDisposeまたはUnsubscribeメソッドで解除すべき。
MyBase.Finalize()
End Sub
End Class

Public Module LeakScenario
Private publishers As New List(Of EventPublisher)()
Private subscribers As New List(Of EventSubscriber)()

Public Sub Run()
Console.WriteLine(“リークシナリオ開始…”)

Dim publisher As New EventPublisher()
publishers.Add(publisher) ‘ 発行元はアプリケーション寿命まで保持

For i As Integer = 1 To 1000
‘ 1000個の購読者を作成
Dim subscriber As New EventSubscriber($”Subscriber-{i}”, publisher)
‘ ここでsubscriberをリストに保持しなければ、GCは回収してくれる…はず
‘ しかし、イベントハンドラがAddHandlerされている限り、publisherがsubscriberへの参照を持つ
‘ subscribers.Add(subscriber) ‘ この行をコメントアウトしてもリークは発生する

‘ publisherをローカル変数にして、GCが回収できるようにしても、
‘ WithEvents_publisherとイベントハンドラの参照によりリークは発生する
Next

‘ GCを強制的に実行してみるが、参照が残っているため回収されない
GC.Collect()
GC.WaitForPendingFinalizers()
Console.WriteLine(“GC実行後…”)

‘ イベントを発行
publisher.RaiseEvent()

Console.WriteLine(“任意のキーを押して終了…”)
Console.ReadKey()
End Sub
End Module

このコードでは、`EventSubscriber`のインスタンスが`EventPublisher`のイベントに購読登録されている。`WithEvents`を使用しているため、明示的な`AddHandler`は不要だが、その裏で参照が保持される。`EventSubscriber`のインスタンスは、`publisher`が破棄されない限り、イベントハンドラを通じて`publisher`から参照され続けるため、GCの対象とならない。
dotMemoryでこのアプリケーションをプロファイルし、スナップショットを比較すると、`EventSubscriber`のインスタンスが大量に残り続けていることが視覚的に確認できるだろう。`Paths to Root`を見ると、`EventPublisher`の内部イベントデリゲートを通じて、`EventSubscriber`への参照が残っていることが明らかになるはずだ。

4. アンマネージド資源の掌握：WinDbgによる徹底解析

dotMemoryはマネージドメモリの解析に優れるが、Windows API経由で取得したハンドル、GDIオブジェクト、COMオブジェクトなどの「アンマネージド資源」のリークは検出できない。そこで登場するのが、Microsoftが提供する究極のデバッガ「WinDbg」である。WinDbgは、ネイティブコードレベルでのデバッグ能力を持ち、SOS (Son of Strike) 拡張機能と組み合わせることで、.NETプロセスの深部に潜む問題を暴き出す。

WinDbgの基本操作とSOS拡張機能

1. ダンプファイルのオープン: WinDbgを起動し、「File」→「Open Crash Dump…」で取得したダンプファイルを開く。
2. SOS拡張機能のロード: .NETプロセスのダンプを解析するために、SOS拡張機能をロードする。

.loadby sos clr

または、.NET Core/5+の場合は

.loadby sos coreclr

環境に合わせてロードする。

アンマネージド資源のリーク検出コマンド

WinDbgとSOSコマンドを駆使することで、マネージドプロファイラでは見えない領域を解析する。

• ハンドルのリーク:

!handle 0 f

このコマンドは、プロセスが保持する全ハンドルを列挙し、その種類と数を表示する。特に、同じ種類のハンドル（例: File, Section, Event, Mutex）が異常に増加している場合、リークを疑う。`!handle f` で特定のハンドルの詳細も確認できる。

• GDI/USERオブジェクトのリーク:

!gdi
!leak

`!gdi`はGDIオブジェクト（Bitmap, Brush, Penなど）の数を表示する。`!leak`はUserオブジェクト（Window, Menuなど）のリークを検出する。GDI/USERオブジェクトはシステム全体で制限があるため、リークは非常に深刻な問題となる。

• マネージドヒープの概要:

!dumpheap -stat

これはSOSの強力なコマンドの一つで、マネージドヒープ上の全オブジェクトを種類ごとに集計し、その合計サイズとインスタンス数を表示する。dotMemoryのような視覚的な情報はないが、オブジェクトの種類と量の変化からリークを推測できる。

• 特定のオブジェクトの参照元を追跡:

!gcroot

`!dumpheap -stat`や`!dumpheap`で怪しいオブジェクトのアドレスを特定したら、そのアドレスを`!gcroot`に渡すことで、そのオブジェクトがGCルートからどのように参照されているかを追跡できる。これはdotMemoryの`Paths to Root`に相当する機能だが、より低レベルで、ネイティブな参照も考慮に入れる。

• 同期オブジェクトの状況:

!syncblk

ロックやミューテックスなど、同期オブジェクトのデッドロックやリークを調査する際に有用。

コード例：P/Invokeによるアンマネージド資源の利用とリークシナリオ

.net
Imports System
Imports System.Runtime.InteropServices
Imports System.Threading

Public Class NativeResourceHandler
‘ Windows APIを宣言 (P/Invoke)
‘ CreateFile関数を呼び出してファイルハンドルを取得

Private Shared Function CreateFile(
lpFileName As String,
dwDesiredAccess As UInt32,
dwShareMode As UInt32,
lpSecurityAttributes As IntPtr,
dwCreationDisposition As UInt32,
dwFlagsAndAttributes As UInt32,
hTemplateFile As IntPtr) As IntPtr
End Function

‘ CloseHandle関数を呼び出してハンドルを解放

Private Shared Function CloseHandle(hObject As IntPtr) As Boolean
End Function

‘ ファイルアクセス権
Private Const GENERIC_READ As UInt32 = &H80000000
Private Const GENERIC_WRITE As UInt32 = &H40000000

‘ ファイル共有モード
Private Const FILE_SHARE_READ As UInt32 = &H1
Private Const FILE_SHARE_WRITE As UInt32 = &H2

‘ ファイル作成モード
Private Const OPEN_EXISTING As UInt32 = 3

Private _fileHandle As IntPtr = IntPtr.Zero ‘ ネイティブファイルハンドル

Public Sub New(filePath As String)
_fileHandle = CreateFile(
filePath,
GENERIC_READ Or GENERIC_WRITE,
FILE_SHARE_READ Or FILE_SHARE_WRITE,
IntPtr.Zero,
OPEN_EXISTING,
0,
IntPtr.Zero
)

If _fileHandle = New IntPtr(-1) Then
Dim errorCode As Integer = Marshal.GetLastWin32Error()
Console.WriteLine($”ファイルハンドル取得失敗: {errorCode}”)
Throw New System.ComponentModel.Win32Exception(errorCode)
Else
Console.WriteLine($”ファイルハンドル取得成功: {_fileHandle}”)
End If
End Sub

‘ IDisposableインターフェースの実装で、明示的なリソース解放を促す
‘ しかし、この例では実装が不完全でリークを引き起こす可能性がある
‘ Public Sub Dispose() Implements IDisposable.Dispose
‘ ‘ ここでCloseHandleを呼び出すべき
‘ If _fileHandle <> IntPtr.Zero Then
‘ CloseHandle(_fileHandle)
‘ Console.WriteLine($”ファイルハンドル解放: {_fileHandle}”)
‘ _fileHandle = IntPtr.Zero
‘ End If
‘ End Sub

‘ Finalizeメソッドは、Disposeが忘れられた場合の最後の手段
Protected Overrides Sub Finalize()
Try
If _fileHandle <> IntPtr.Zero Then
CloseHandle(_fileHandle)
Console.WriteLine($”Finalizeでファイルハンドル解放: {_fileHandle}”)
End If
Finally
MyBase.Finalize()
End Try
End Sub
End Class

Public Module NativeLeakScenario
Public Sub Run()
Console.WriteLine(“ネイティブリソースリークシナリオ開始…”)

‘ ダミーファイルを作成 (事前にC:\temp\dummy.txtを作成しておくことを想定)
‘ もしくは、ファイルが存在しない場合はCreateFileが失敗するので注意
Dim dummyFilePath As String = “C:\temp\dummy.txt”
If Not System.IO.File.Exists(dummyFilePath) Then
System.IO.File.WriteAllText(dummyFilePath, “dummy content”)
Console.WriteLine($”ダミーファイル ‘{dummyFilePath}’ を作成しました。”)
End If

For i As Integer = 1 To 100
‘ ここでNativeResourceHandlerのインスタンスを生成するが、
‘ Disposeを呼び出さず、変数も保持しない
‘ GCがいつFinalizeを呼び出すかは保証されないため、ハンドルがリークする可能性が高い
Dim handler As New NativeResourceHandler(dummyFilePath)
‘ handler = Nothing ‘ 参照を失わせる
Next

‘ GCを強制的に実行してみるが、Finalizeがいつ実行されるかは不確定
GC.Collect()
GC.WaitForPendingFinalizers()
Console.WriteLine(“GC実行後…”)

Console.WriteLine(“任意のキーを押して終了…”)
Console.ReadKey()
End Sub
End Module

このシナリオでは、`NativeResourceHandler`がWindows APIの`CreateFile`をP/Invokeで呼び出し、ファイルハンドルを取得する。しかし、取得したハンドルを明示的に`CloseHandle`で解放する`Dispose`メソッドを呼び出していない。`Finalize`メソッドで解放する実装はあるものの、GCのタイミングは不確定であり、大量に生成されたハンドルがシステムリソースを圧迫し、リークとして現れる可能性がある。

WinDbgでこのダンプを解析すると、`!handle 0 f`コマンドでFileハンドルの数が異常に増えていることが確認できるだろう。これにより、P/Invokeによって取得されたアンマネージド資源が適切に解放されていないことが特定できる。

5. 対策とチューニング：リークを未然に防ぎ、性能を引き出す

メモリリークの検出は困難だが、対策はより戦略的でなければならない。設計段階から意識し、コードレビューで徹底することが、最も効果的な予防策となる。

5.1. 明示的解放と`IDisposable`パターン

アンマネージド資源を扱うクラスは、必ず`IDisposable`インターフェースを実装し、`Dispose`メソッドでそれらを明示的に解放するべきである。VB.NETでは`Using`ステートメントを用いることで、`Dispose`の呼び出しを確実に実行できる。

.net
‘ IDisposableを実装したクラスの正しい例
Public Class ManagedAndNativeResource : Implements IDisposable
Private _nativeHandle As IntPtr ‘ アンマネージド資源の例

‘ コンストラクタ
Public Sub New()
‘ ここでネイティブリソースを取得する
_nativeHandle = Marshal.AllocHGlobal(1024) ‘ 1KBのネイティブメモリを確保
Console.WriteLine($”ネイティブメモリ確保: {_nativeHandle}”)
End Sub

‘ Disposeパターン実装のためのフラグ
Private disposedValue As Boolean = False

‘ Disposeメソッド (Public, IDisposableインターフェースの要件)
Protected Overridable Sub Dispose(disposing As Boolean)
If Not Me.disposedValue Then
If disposing Then
‘ マネージド資源の解放 (例: イベントハンドラの解除、他のIDisposableオブジェクトのDispose呼び出し)
‘ ここでは例として省略
End If

‘ アンマネージド資源の解放
If _nativeHandle <> IntPtr.Zero Then
Marshal.FreeHGlobal(_nativeHandle)
Console.WriteLine($”ネイティブメモリ解放: {_nativeHandle}”)
_nativeHandle = IntPtr.Zero
End If
End If
Me.disposedValue = True
End Sub

‘ IDisposable.Disposeの実装
Public Sub Dispose() Implements IDisposable.Dispose
‘ このコードパスはGCによるFinalizeではなく、開発者による明示的なDispose呼び出し
Dispose(True)
‘ Finalizeが不要になるため、GCにそれを抑制するよう伝える
GC.SuppressFinalize(Me)
End Sub

‘ Finalizeメソッド (デストラクタ)
Protected Overrides Sub Finalize()
‘ Disposeが忘れられた場合に備えて、ここでアンマネージド資源を解放する
‘ ただし、GCのタイミングに依存するため、この呼び出しは保証されない
‘ また、FinalizeはDispose(False)を呼び出すべき
Dispose(False)
MyBase.Finalize()
End Sub

‘ このクラスの利用例
Public Sub DoSomething()
If _nativeHandle = IntPtr.Zero Then Throw New ObjectDisposedException(Me.GetType().Name)
Console.WriteLine(“リソースを使って何か処理を実行中…”)
End Sub
End Class

‘ 利用例
Public Module ResourceUsage
Public Sub DemonstrateDispose()
Console.WriteLine(“Disposeのデモンストレーション開始…”)

‘ Usingステートメントを使うことで、確実にDisposeが呼び出される
Using res As New ManagedAndNativeResource()
res.DoSomething()
End Using ‘ ここでres.Dispose()が自動的に呼び出される

Console.WriteLine(“Disposeのデモンストレーション終了。”)
Console.ReadKey()
End Sub
End Module

`GC.SuppressFinalize(Me)`は重要だ。`Dispose`が明示的に呼ばれた場合、`Finalize`の実行は不要となり、GCのパフォーマンス向上に寄与する。

5.2. イベントハンドラの徹底管理

前述の通り、イベントハンドラの登録解除忘れは主要なリーク原因の一つだ。

• 常に`AddHandler`と`RemoveHandler`をペアで記述する: オブジェクトのライフサイクルに合わせて、購読開始と同時に解除のタイミングも考慮する。
• `WithEvents`の適切な利用: `WithEvents`は便利だが、オブジェクト参照が有効な限りイベントデリゲートが保持される。参照が不要になったら、`_publisher = Nothing` のように参照をクリアするか、明示的に`RemoveHandler`を呼び出す。
• WeakReferenceの活用: イベント発行元が購読者を強く参照する必要がない場合、`WeakReference`を使って購読者を保持することも検討できる。

.net
‘ イベントハンドラの正しい管理例
Public Class ProperEventSubscriber : Implements IDisposable
Private _name As String
Private _publisher As EventPublisher ‘ WithEventsではない

Public Sub New(name As String, publisher As EventPublisher)
_name = name
_publisher = publisher
‘ 明示的にイベントを購読
AddHandler _publisher.MyEvent, AddressOf HandleMyEvent
Console.WriteLine($”{_name} がイベントを購読開始 (明示的AddHandler)”)
End Sub

Private Sub HandleMyEvent(sender As Object, e As EventArgs)
Console.WriteLine($”{_name}: イベントを受信しました！”)
End Sub

‘ IDisposableパターンでイベント購読を解除する
Private disposedValue As Boolean = False

Protected Overridable Sub Dispose(disposing As Boolean)
If Not Me.disposedValue Then
If disposing Then
‘ マネージド資源（イベントハンドラ）を解放
If _publisher IsNot Nothing Then
RemoveHandler _publisher.MyEvent, AddressOf HandleMyEvent
Console.WriteLine($”{_name} がイベント購読を解除 (Dispose)”)
_publisher = Nothing ‘ 発行元への参照もクリア
End If
End If
End If
Me.disposedValue = True
End Sub

Public Sub Dispose() Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize(Me)
End Sub

Protected Overrides Sub Finalize()
Dispose(False)
MyBase.Finalize()
End Sub
End Class

Public Module ProperLeakScenario
Public Sub Run()
Console.WriteLine(“正しいイベント購読シナリオ開始…”)

Dim publisher As New EventPublisher()
Dim subscribers As New List(Of ProperEventSubscriber)()

For i As Integer = 1 To 1000
‘ 1000個の購読者を作成し、リストに保持
Dim subscriber As New ProperEventSubscriber($”ProperSubscriber-{i}”, publisher)
subscribers.Add(subscriber)
Next

‘ ここで全ての購読者をDisposeすることで、イベント購読が解除され、オブジェクトがGC可能になる
For Each subscr As ProperEventSubscriber In subscribers
subscr.Dispose()
Next
subscribers.Clear() ‘ リストから参照をクリア

GC.Collect()
GC.WaitForPendingFinalizers()
Console.WriteLine(“GC実行後 (正しく解放されたはず)…”)

publisher.RaiseEvent() ‘ イベントは発行されるが、購読者がいないため何も表示されないはず

Console.WriteLine(“任意のキーを押して終了…”)
Console.ReadKey()
End Sub
End Module

5.3. 静的フィールドの利用：最小限に留める

静的フィールドはアプリケーション全体で共有されるため、そこにオブジェクトへの参照を保持すると、そのオブジェクトはアプリケーションの寿命が尽きるまで解放されない。

• 本当に必要か再考: グローバルな状態を保持する必要があるか、シングルトンパターンなどで代替できないか検討する。
• ライフサイクルを意識: 静的フィールドに保持するオブジェクトは、そのライフサイクルがアプリケーションのそれと一致することを確認する。

5.4. COMオブジェクトの扱い：`Marshal.ReleaseComObject`

レガシーなVBA/COMコンポーネントとの連携は、VB.NETアプリケーションにおいて特に注意が必要な領域だ。COMオブジェクトは参照カウントベースでメモリ管理されるため、.NETのGCとは異なる挙動を示す。
VB.NETからCOMオブジェクトにアクセスすると、CLRはRCW (Runtime Callable Wrapper) を生成し、COMオブジェクトへの参照カウントを管理する。しかし、RCWがGCによって回収されても、COMオブジェクトの参照カウントが適切に減少しない場合がある。

.net
Imports System.Runtime.InteropServices

Public Module ComObjectLeak
Public Sub DemonstrateComCleanup()
Console.WriteLine(“COMオブジェクトのクリーンアップデモンストレーション開始…”)

Dim excelApp As Object = Nothing ‘ Late Bindingの例

Try
‘ ExcelアプリケーションのCOMオブジェクトを作成
excelApp = CreateObject(“Excel.Application”)
excelApp.Visible = True
Console.WriteLine(“Excelアプリケーション起動。”)

Dim workbook As Object = excelApp.Workbooks.Add()
Dim sheet As Object = workbook.Sheets(1)
sheet.Cells(1, 1).Value = “Hello from VB.NET!”
Console.WriteLine(“Excelに書き込みました。”)

‘ ここで重要なのは、各COMオブジェクトへの参照を明示的に解放すること
‘ 参照のネストが深い場合、外側から順に解放するのが原則
‘ ただし、必ずしもすべてのCOMオブジェクトで必要というわけではないが、
‘ 複雑なCOM連携では、確実に解放するために実施することが推奨される
Marshal.ReleaseComObject(sheet)
Marshal.ReleaseComObject(workbook)
Marshal.ReleaseComObject(excelApp) ‘ これが最も重要

excelApp = Nothing ‘ 変数もクリア
workbook = Nothing
sheet = Nothing

Catch ex As Exception
Console.WriteLine($”エラーが発生しました: {ex.Message}”)
Finally
‘ 念のため、Finallyブロックでも解放処理を行う
If excelApp IsNot Nothing Then
Try
excelApp.Quit() ‘ Excelアプリケーションを終了
Marshal.ReleaseComObject(excelApp)
Catch
‘ エラー処理
End Try
End If
End Try

GC.Collect()
GC.WaitForPendingFinalizers()
Console.WriteLine(“GC実行後…”)

Console.WriteLine(“COMオブジェクトのクリーンアップデモンストレーション終了。”)
Console.ReadKey()
End Sub
End Module

`Marshal.ReleaseComObject()`を適切に呼び出すことで、RCWによって増えたCOMオブジェクトの参照カウントを減らし、COMオブジェクトが解放されるように促す。特に、繰り返しCOMオブジェクトを生成・操作するようなシステム間連携では、この処理を徹底しないと、大量のCOMオブジェクトが残り続け、システムリソースを食い潰すことになる。

5.5. GCの挙動チューニング：最終手段として

`GC.Collect()`や`GC.WaitForPendingFinalizers()`を安易に呼び出すことは、パフォーマンスを低下させるだけでなく、リークの原因特定を困難にする。GCは、アプリケーションの動作状況に応じて最適なタイミングで実行されるように設計されている。

• 原則としてGCの強制実行は避ける: パフォーマンス上の理由から、GCを強制的に呼び出すのは非常に稀なケースに限定すべきだ。
• メモリ監視と閾値設定: アプリケーションが特定のメモリ使用量を超えた場合に、問題の兆候として GCをトリガーすることは可能だが、これは根本的な解決策ではない。
• Large Object Heap (LOH) のフラグメンテーション: 大規模な配列や文字列操作が多い場合、LOHのフラグメンテーションが問題になることがある。.NET Core 3.0以降ではLOHのコンパクションが可能になったが、これもパフォーマンスとのトレードオフを慎重に検討する必要がある。

6. 結論：メモリリーク解析は芸術であり科学である

Visual Basic (VB / VB.NET) の領域で長年、泥臭い現場で戦ってきた我々にとって、メモリリークは常に手強い敵であった。しかし、その根源は常に「意図しない参照の保持」にある。ガベージコレクタは万能ではない。我々開発者が、オブジェクトのライフサイクル、参照の連鎖、そしてアンマネージド資源の責任を深く理解し、コードにその知見を反映させることが、リークのない堅牢なシステムを構築する唯一の道である。

dotMemoryはマネージドメモリの参照グラフを視覚化し、WinDbgはアンマネージド資源と低レベルのマネージド状態を暴き出す。これら二つのツールは、あなたの探偵能力を最大限に引き出すための強力な「メス」である。しかし、メスを振るうのはあなた自身だ。ツールの出力データを鵜呑みにするのではなく、その背後にあるメカニズムを洞察し、コードとシステムの全体像を掌握する「極限の知見」こそが、真の解決へと導く。

メモリリーク解析は、まさに芸術であり科学である。この深淵な旅路において、本稿があなたの確固たる羅針盤となることを願う。システムの健全性を守り、ユーザーに最高の体験を提供するために、我々は常に学び、進化し続けなければならない。これが、この道を極めた者からの、魂を込めたメッセージである。