VB6应用程序调用.NET DLL OutOfMemory异常

Question

我们有一个调用.NET DLL的VB6应用程序。有时，在VB6应用程序运行了很长时间并且已经调用了很多.NET代码之后，即使机器上有足够的可用内存，.NET方面也会抛出OutOfMemory异常。 VB6的内存空间也没有接近它的极限。

.NET端是否保留单独的内存池？或者它是VB6应用程序的内存池的一部分？

如果它是分开的，有没有办法看看它有多大？我的任务管理器中唯一庞大的内存项是SQL Server和VB6应用程序（都是预期的）。

这种情况不会经常发生，但是当它发生时，很难确定为什么系统不会分配更多内存。

Answer 1

在某处似乎是内存泄漏，假设dll和调用app是正确的，它可能在调用中。检查参数数据类型和byref与byval。 .net中的参数默认为byval，在vb6 byref中。每种字符串类型都不会在调用库时始终正确转换。

Answer 2

答案最终非常简单：

使用DEBUG配置构建的.NET DLL在运行时会泄漏。

切换到RELEASE构建修复了我的问题。

背景：

我终于得到了ANTS来调试VB6应用程序并看到.NET进程（必须更改VB6代码以尽快加载.NET代码）。一旦我这样做，我看到了大量的弱引用对象，其父级是__ENCList。此类允许在调试期间编辑和继续。谷歌快速搜索显示这是由使用DEBUG构建引起的。

My Google Search

链接：

WeakReferences in Debug Build

Answer 3

要检查的第一件事是记忆中物体的固定。在多线程环境中，这可能会很快失控，具体取决于代码的编写方式。当.NET去占用更多内存时，它会占用8,16或32 MB块，而这些块需要完全清理。也就是说，你可能拥有数百MB的可用内存，但是如果没有其他任何内容的32 MB块可用，那么你就可以获得你所见过的OOM。我强烈建议你找一个像ANTS这样的内存分析器并仔细研究一下。

Answer 4

此错误通常应该从 GDI对象中读取。检查“任务管理器进程”选项卡中的GDI / Handles计数器，或使用GDIView。