我們有一個調用.NET DLL的VB6應用程序。偶爾，在VB6應用程序運行了很長時間並且已經調用了.NET代碼之後，事情的.NET方面會拋出OutOfMemory異常，即使計算機上有足夠的可用內存。 VB6內存空間也沒有接近它的限制。VB6應用程序調用.NET DLL OutOfMemory異常
.NET端是否保留單獨的內存池？還是它的VB6應用程序的內存池？
如果它是分開的，有沒有辦法看到它有多大？我的任務管理器中唯一的巨大內存項目是SQL Server和VB6應用程序（都是預期的）。
這並不經常發生，但是當它發生時，很難確定系統爲什麼不分配更多內存。
答案最終是很簡單的：用DEBUG配置內置
一個.NET的DLL運行時會泄漏。
切換到RELEASE構建修復了我的問題。
背景：
我終於得到了螞蟻調試VB6應用程序，看到了.NET程序（不得不改變VB6代碼儘快加載.NET代碼）。一旦我這樣做了，我看到大量的弱引用對象，其父對象是__ENCList。這些類允許在調試過程中進行編輯和繼續。快速谷歌搜索立即顯示這是由使用DEBUG構建造成的。
鏈接：
要檢查的第一件事是鎖定內存中的對象。在多線程環境中，根據編寫代碼的方式，這可能會很快失去控制。當.NET去獲取更多的內存時，它會佔用8,16或32 MB塊，並且這些塊需要完全清理。也就是說，您可能擁有數百MB的可用內存，但如果沒有任何其他內容的情況下沒有32 MB的塊，那麼您將獲得您所看到的OOM。我強烈建議讓內存分析器（如ANTS）仔細研究一下。
往往不是這個錯誤應該被讀作GDI對象。檢查任務管理器進程選項卡中的GDI /手柄計數器，或使用GDIView。
我也會看看。我似乎記得任務管理器中有大約100個GDI對象。似乎遠低於註冊表中的10,000個限制。 – 2009-11-12 17:54:31
這似乎是一個內存泄漏的地方，並假設DLL和調用應用程序是正確的，它可能在通話中。檢查參數數據類型，byref與byval。 .net中的參數默認爲byval，位於vb6 byref中。每種類型都有不同的字符串類型，這些字符串在調用庫時並不總是正確轉換。
不幸的是，這是一個單線程的應用程序。但我會用ANTS來看看事情。也許我有一些嚴重的內存碎片。 – 2009-11-12 17:14:50
Bugger，當父進程是加載.NET DLL的VB6可執行文件時，似乎很難使用ANTS。 – 2009-11-12 17:55:27