我们有一个调用.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