App App VB6 .NET DLL Exception OutOfMemory

Question

Nous avons une application VB6 qui appelle à une DLL .NET. Parfois, après que l'application VB6 ait fonctionné pendant longtemps et qu'elle ait beaucoup appelé le code .NET, le côté .NET produit une exception OutOfMemory, même s'il y a beaucoup de mémoire disponible sur la machine. L'espace de mémoire VB6 est également proche de sa limite.

Le côté .NET conserve-t-il un pool de mémoire distinct? Ou est-il à part du pool de mémoire de l'application VB6? Si elle est séparée, y a-t-il un moyen de voir à quel point elle est grande? Les seuls éléments de mémoire énormes dans mon Gestionnaire des tâches sont SQL Server et l'application VB6 (tous deux attendus).

Cela n'arrive pas trop souvent, mais quand c'est le cas, il est difficile de déterminer pourquoi le système n'allouera pas plus de mémoire.

Answer 1

La réponse a fini par être très simple:

Une DLL .NET construit avec une configuration Debug fuite en courant.

La modification d'une version RELEASE a résolu mon problème.

Contexte:

J'ai finalement eu ANTS déboguer l'application VB6 et voir le processus .NET (ont dû changer le code VB6 pour charger le code .NET, dès que possible). Une fois cela fait, j'ai vu un grand nombre d'objets référencés faibles dont le parent était __ENCList. Cette classe permet Edit et Continue pendant le débogage. Une recherche rapide sur Google a immédiatement montré que cela était dû à l'utilisation d'une version DEBUG.

My Google Search

Liens:

WeakReferences in Debug Build

Answer 2

La première chose à vérifier est l'épinglage des objets dans votre mémoire. Dans un environnement multithread, cela peut devenir assez rapidement hors de contrôle en fonction de la façon dont le code est écrit. Quand .NET va prendre plus de mémoire, il le prendra en blocs de 8, 16 ou 32 Mo et ces blocs devront être complètement propres. Autrement dit, vous pouvez avoir des centaines de Mo de mémoire libre, mais s'il n'y a pas un bloc de 32 Mo libre sans rien d'autre, alors vous obtenez le MOO que vous avez vu. Je suggère fortement d'obtenir un profileur de mémoire comme ANTS et de regarder de plus près les choses.

Answer 3

Le plus souvent, cette erreur doit être lue sur Objets GDI. Vérifiez le compteur GDI/Handles dans l'onglet des processus Gestionnaire des tâches ou utilisez GDIView.

Answer 4

Cela ressemble à une fuite de mémoire quelque part, et en supposant que la DLL et l'application appelante sont corrects, il peut être dans l'appel. Vérifiez les types de données de paramètre et byref vs. byval. Paramètres en .net par défaut à byval, en vb6 byref. Il existe différents types de chaînes dans chaque qui ne sont pas toujours convertis correctement lors d'un appel à une bibliothèque.