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

Question

我们有一个VB6应用程序，它调用.NET DLL。偶尔，在VB6应用程序运行了很长时间并多次调用.NET代码后，即使机器上有大量可用内存，.NET方面也会抛出OutOfMemory异常。而且，VB6内存空间也远未达到极限。

.NET是否保留单独的内存池？还是它属于VB6应用程序的内存池？

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

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

- Patrick Burleson

Answer 1

答案最终非常简单：

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

切换到 RELEASE 构建解决了我的问题。

背景：

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

链接： 我的谷歌搜索 Debug 构建中的弱引用

- Patrick Burleson

Answer 2

首先要检查的是内存中对象的固定。在多线程环境下，这可能会很快失控，具体取决于代码编写方式。当.NET需要获取更多内存时，它将以8、16或32 MB块获取，并且这些块需要完全干净。也就是说，你可能有数百MB的空闲内存，但如果没有一个32 MB的块是空闲的且没有其他东西，则会出现OOM错误。我强烈建议使用ANTS等内存分析工具，仔细查看问题。

- Sonny Boy

---

不幸的是，这是一个单线程应用程序。我会用ANTS来检查一下情况。也许我有一些严重的内存碎片化问题。 - Patrick Burleson

看起来当父进程是一个加载了.NET dll的VB6可执行文件时，使用ANTS相当困难。 - Patrick Burleson

Answer 3

往往情况下，这个错误应该被理解为超出了GDI对象。请检查任务管理器进程选项卡中的GDI/句柄计数器，或使用GDIView。

- wqw

---

我也会看一下。 我记得在任务管理器中有大约100个GDI对象。 似乎远低于注册表中设置的10,000限制。 - Patrick Burleson

Answer 4

看起来有一个内存泄漏的问题，假设dll和调用应用程序是正确的，可能是在调用中出现了问题。检查参数数据类型，以及byref与byval。在.net中，参数默认为byval，在vb6中为byref。在每个中都有各种字符串类型，这些类型在调用库时不总是正确转换。

- xpda