Home/ Questions/Q 588131
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:17:10+00:00

We have a VB6 app that calls out to a .NET DLL. Occasionally, after

  • 0

We have a VB6 app that calls out to a .NET DLL. Occasionally, after the VB6 app has been running for a long time and has called the .NET code a lot, the .NET side of things throws an OutOfMemory exception, even though there is plenty of memory available on the machine. The VB6 memory space is also no where near it’s limit.

Does the .NET side keep a separate memory pool? Or is it apart of the VB6 app’s memory pool?

If it is separate, is there a way to see how big it is? The only huge memory items in my Task Manager are SQL Server and the VB6 app (both expected).

This doesn’t happen too often, but when it does, it’s hard to pin down why the system won’t allocate more memory.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The answer ended up being very simple:

    A .NET DLL built with DEBUG configuration will leak while running.

    Switching to a RELEASE build fixed my issue.

    Background:

    I finally got ANTS to debug the VB6 app and see the .NET process (had to change the VB6 code to load the .NET code as soon as possible). Once I did that, I saw a huge number of weak referenced objects whose parent was __ENCList. This classes allows for Edit and Continue during debugging. A quick Google search showed immediately this was caused by using a DEBUG build.

    My Google Search

    Links:

    WeakReferences in Debug Build

    • 0