.NET DLL を呼び出す VB6 アプリがあります。場合によっては、VB6 アプリが長時間実行され、.NET コードを何度も呼び出した後、.NET 側で OutOfMemory 例外がスローされることがあります。これは、マシンに十分なメモリがある場合でも発生します。VB6 のメモリ空間も、限界に近いところにはありません。
.NET 側は別のメモリ プールを保持していますか? それとも、VB6 アプリのメモリ プールの一部ですか?
分離している場合、大きさを確認する方法はありますか？タスク マネージャーの唯一の巨大なメモリ アイテムは、SQL Server と VB6 アプリです (両方とも予想されます)。
これはあまり頻繁には発生しませんが、発生した場合、システムがより多くのメモリを割り当てない理由を突き止めるのは困難です。
どこかでメモリ リークが発生しているようで、dll と呼び出し元のアプリが正しいと仮定すると、呼び出しに含まれている可能性があります。パラメーターのデータ型、および byref と byval を確認してください。.net のパラメータのデフォルトは byval で、vb6 では byref です。ライブラリへの呼び出しで常に適切に変換されるとは限らない、それぞれにさまざまな文字列型があります。
答えは非常にシンプルになりました。
DEBUG 構成でビルドされた .NET DLL は、実行中にリークします。
RELEASE ビルドに切り替えると、問題が解決しました。
バックグラウンド：
最終的に ANTS に VB6 アプリをデバッグして .NET プロセスを確認してもらいました (できるだけ早く .NET コードをロードするように VB6 コードを変更する必要がありました)。これを実行すると、親が __ENCList である弱い参照オブジェクトが多数表示されました。このクラスを使用すると、デバッグ中にエディット コンティニュを使用できます。Google で簡単に検索すると、これは DEBUG ビルドの使用が原因であることがすぐにわかりました。
リンク:
多くの場合、このエラーは out of GDI Objectsとして読み取られる必要があります。タスク マネージャーの [プロセス] タブで GDI/Handles カウンターを確認するか、GDIViewを使用します。
最初に確認することは、メモリ内のオブジェクトの固定です。マルチスレッド環境では、コードの書き方によっては、これがすぐに制御不能になる可能性があります。.NET がより多くのメモリを取得しようとすると、8、16、または 32 MB のブロックが使用され、これらのブロックは完全にクリーンである必要があります。つまり、数百 MB の空きメモリがあるかもしれませんが、他に何もない 32 MB の空きブロックがない場合は、これまで見てきた OOM が得られます。ANTS などのメモリ プロファイラーを入手して、詳しく調べてみることを強くお勧めします。