Приложение VB6 вызывает исключение .NET DLL OutOfMemory

Question

У нас есть приложение VB6, которое вызывает .NET DLL. Иногда, после того, как приложение VB6 долгое время работало и часто вызывало код .NET, сторона .NET выдает исключение OutOfMemory, даже если на компьютере достаточно памяти. Память VB6 также находится далеко от предела.

Сохраняет ли сторона .NET отдельный пул памяти? Или это часть пула памяти приложения VB6?

Если он отдельный, есть ли способ увидеть, насколько он велик? Единственные огромные элементы памяти в моем диспетчере задач - это SQL Server и приложение VB6 (оба ожидаются).

Это происходит не слишком часто, но когда это происходит, трудно определить, почему система не будет выделять больше памяти.

Answer 1

Ответ оказался очень простым:

.NET DLL, созданная с конфигурацией DEBUG, будет работать во время работы.

Переход на RELEASE-сборку исправил мою проблему.

Справка:

Я наконец получил ANTS для отладки приложения VB6 и просмотра процесса .NET (пришлось изменить код VB6, чтобы загрузить код .NET как можно скорее) Как только я это сделал, я увидел огромное количество объектов со слабыми ссылками, чьим родителем был __ENCList. Этот класс позволяет редактировать и продолжить во время отладки. Быстрый поиск в Google сразу показал, что это вызвано использованием сборки DEBUG.

Мой поиск Google

Ссылки:

Слабые ссылки в отладочной сборке

Answer 2

Кажется, что где-то утечка памяти, и, если dll и вызывающее приложение верны, это может быть в вызове. Проверьте типы данных параметров, а также byref и byval. Параметры в .net по умолчанию - byval, в vb6 - byref. В каждом есть различные типы строк, которые не всегда правильно конвертируются при обращении к библиотеке.

Answer 3

Чаще всего эту ошибку следует читать как из объектов GDI . Проверьте счетчик GDI / Handles на вкладке процессов диспетчера задач или используйте GDIView .

Answer 4

Первое, что нужно проверить - это закрепление объектов в вашей памяти. В многопоточной среде это может довольно быстро выйти из-под контроля в зависимости от того, как написан код. Когда .NET начинает захватывать больше памяти, он занимает 8, 16 или 32 МБ блоков, и эти блоки должны быть полностью чистыми. То есть, у вас может быть сотни МБ свободной памяти, но если нет 32 МБ свободного блока без чего-либо еще, тогда вы получите ООМ, который вы видели. Я настоятельно рекомендую приобрести профилировщик памяти, такой как ANTS, и более внимательно посмотреть на вещи.