一定の間隔が経過した後、MSExchangeをポーリングして新しいメールメッセージを検出するEWSマネージAPIを使用しています。ポーリング呼び出しを呼び出すたびに（PullSubscription.GetEvents()）-Microsoft APIは適切に処理できず、NetworkStreamそれに比例してメモリが増加します。これは以前にここで説明されましたが、解決されることはありませんでした。ANTS Profilerを使用して、メモリ内で継続的に成長しているオブジェクトを特定し、問題を特定することができました。
問題が特定されたので、参照のない外部APIで作成されたNetworkStreamを破棄する方法はありますか？GC.Collect（）はまだアクティブな参照を持っているため、それを破棄していないようです。ぶら下がっている参照をクリーンアップするために何ができますか？バグのあるSDKを強制的にクリーンアップするために使用できるラッパーはありますか？
GCに参照オブジェクトのメモリを強制的に解放させる方法はありません。
まず最初に、このバグのヘルプについてマイクロソフト自体に連絡することをお勧めします。
第二に、あなたは「廃棄」について話しているのですか、それとも単にメモリの解放について話しているのですか？それらは2つのまったく異なるものです。（IDisposableパターン、ファイナライザー）。
第三に、これらのオブジェクトを参照しているオブジェクトを逆参照することはできますか？
第4に、考えられる解決策の1つは、問題の原因となっているコードをリフレクターで逆コンパイルし、参照オブジェクトを保持しているフィールドに到達する方法を理解し、コードでリフレクションを使用してプライベートフィールドにアクセスし、ヌル。非常に汚いハックですが、他に方法がない場合は、私が考えることができる唯一のことです。他の方法で行けない場合にのみこれを行ってください。
最も簡単な方法は、SDKを独自のインターフェースに接続し、AppDomain完了したらAppDomainをアンロードする部分を実行することです。これにより、AppDomainに割り当てられているすべてのメモリが解放されます。
AppDomainただし、オブジェクトとのみ交換できるMarshalByRefか、としてマークされているため、プロジェクトにいくつかの作業を追加する必要がありますserilizable。
これにより、AppDomainによって消費されるメモリの量を監視することもできます。したがって、AppDomainを作成し、その中でバグのあるSDKを実行し、メモリ消費の特別な制限に達した場合は、それをアンロードできます。