マネージド アプリケーションに関連するいくつかのメモリの問題をデバッグしています。perfmon を使用してアプリケーションを監視していたときに、すべてのヒープ内の .NET バイト数と Process Explorer (タスク マネージャーの場合は Mem Usage 列) で報告されるワーキング セットのメモリの違いについて混乱しました。Bytes in all heaps カウンターの値は 15MB と表示されますが、プロセスのワーキング セットは 78MB です。これは大きな違いです。メモリにロードされたファイルである程度のメモリが消費されることは理解していますが、それでも数値が加算されません。
手がかりはありますか？
RicoMarianiのPerformanceTidbitsブログ投稿管理されたメモリリーク（GCリークを見つける方法）を追跡することは、あなたの質問に直接答えることはありません：すべてのヒープとワーキングセットのバイト数、しかしそれはあなたのタスクの再：いくつかのメモリ問題のデバッグにかなり役立つはずです管理対象アプリケーションに関連します。
また、メモリ使用量を増やすために避けるべき2つのことと、廃棄されていないオブジェクトによるメモリリークを追跡するための3つの手法を確認することもできます。
すべての記事はかなり古いですが、提示された情報はまだあなたに役立つはずです。
この記事では、さまざまなメモリ カウンターの概要について説明します。
ワーキング セット– これは、プロセスの (コミットされた) 仮想メモリ ページのセットであり、物理 RAM に配置されます。ワーキング セットは、「これらのページで現在/最近作業している」リストのようなものです。
あなたの質問の説明から、あなたはおよそ持っているようです。63MB のアンマネージ メモリが使用されています。
FXCopを試してみてください。IDisposable 型での dispose の呼び出しの失敗に関するルールを探してください。
.net でのメモリ リークの主な原因は 2 つあります。IDisposable の呼び出しの失敗 (P/Invoke コードのアンマネージ デストラクタを呼び出す手法) と、オブジェクトへの参照の解放の失敗です。ガベージコレクション。たとえば、オブジェクトをリストに保存している場合、誤ってリストへの参照を保持しているため、オブジェクトがまだメモリ内にある可能性があります。