All geek questions in one place

VB6 App Calling.NET DLL OutOfMemory Exception

We have a VB6 application that is called in the .NET DLL. Sometimes, after a VB6 application has been running for a long time and quotes a lot of .NET code, the .NET side throws an OutOfMemory exception, although there is enough memory on the computer. VB6 memory is also not where it is limited.

Does the .NET side support a separate memory pool? Or is it separate from the VB6 application memory pool?

If it is separate, is there any way to see how big it is? The only huge memory elements in my task manager are SQL Server and the VB6 application (both are expected).

This does not happen too often, but when this happens, it is difficult to determine why the system does not allocate more memory.

+2
source share
4 answers

The answer turned out to be very simple:

A .NET DLL built using the DEBUG configuration will leak during operation.

Switching to the RELEASE assembly fixed my problem.

Background:

I finally got ANTS to debug the VB6 application and view the .NET process (I had to change the VB6 code to load the .NET code as soon as possible). As soon as I did this, I saw a huge number of weak reference objects whose parent was __ENCList. These classes allow you to edit and continue during debugging. A quick Google search showed that this was caused by using the DEBUG assembly.

My Google Search

References:

WeakReferences in Debug Build

+1
source

There seems to be a memory leak somewhere, and assuming that the DLL and the calling application are correct, it could be in a call. Check parameter data types and byref vs byval. Parameters in .net by default are byval, in vb6 byref. Each of them has different types of strings that are not always correctly converted when called to the library.

+1
source

The first thing to check is fixing objects in your memory. In a multi-threaded environment, this can get out of hand pretty quickly depending on how the code is written. When .NET is about to grab more memory, it will take 8, 16, or 32 MB of blocks, and these blocks should be completely clean. That is, you can have hundreds of MB of free memory, but if there is no 32 MB block in the block without anything else, then you get the OOM that you saw. I highly recommend getting a memory profiler such as ANTS and taking a closer look at things.

0
source

Most often, this error should be read as from GDI objects. Check the GDI / Handles counter on the Process Manager tab or use GDIView .

0
source

Source: https://habr.com/ru/post/1493542/

More articles:


All Articles