Hi there,

I have been working in a company for the last 4 years that develop a large vb6 app. For 3 of those years, we have been expierencing "Out of Memory" issues.

This manifests itself as an Out of Memory error when compiling.

As I said it is a fairly large vb6 app. We're talking over 500 Forms, Modules and classes. The .exe it creates is > 11MB. If it goes any larger than this (by adding new functionality forms, clasess or otherwise), it throws the out of memory

The way we've been dealing with this to date, is by moving parts of the system into a seperate module which would be run by a DDE call to this exe. Obviously this is not ideal..a bit like rearranging the deckchairs on the titanic. We have streamlined our code and have removed all dead variables and functions.

Has anyone expierenced this themselves? Is the only solution not to add more functionality i.e. have we reached the limit size of a vb app?
Any input would be most welcome.

Many Thanks


Applications what I Work, has got some 400 (Forms+modules+classes), We have never faced such Out of Memory issue..
May be, because, the system I work is with the latest Configuration, Good Memory and high RAM.
The best part is we use external Crystalreports.. So no need to embed reports into our proj..
Say, if you are using Datareports ,
then you can move that functionality to CR or excel reports..


You can gain as much memory as you want if you create DLLs.

Unfortunatly the app is at a stage where using DLLs now would require big rewrite of code and is unfeasible. If it was designed correctly from the outset this would of been the approach taken.

We are moving to vb.net in the next 2 years but this itself is a huge undertaking and will be an extremely slow process. Am I right in saying that with .net it is alot easier to include libraries?

There is constant development work which has now come to a stand still pending a fix of this, we actually can't fit any more into the app.

We're already using external CR and I dont think that latest Configuration, Good Memory and high RAM are the issue, its more the size of the vb project itself. The issue is the same on any machine. But thanks for your input QVeen.:) Just out of curiosity how big is the exe that is created from this project QVeen?



RAM Definately comes into picture,
You need a very High RAM..
You will get OUT OF MEMORY issue for lower RAm's..
Also, make sure, when you close your Project or while making EXE, Close all the Open Forms..

My Exe file is 11.5 MB


RAM Definately comes into picture,

Thanks for the reply veena

Does this mean that theres no set limit to a vb project but only how much the particular machine can handle?

Also what kinda RAM we talkin here?


RAM isn't the problem -- size of the executable program is. There is a maximum size of any executable that runs on MS-Windows -- I recall reading that somewhere awhile back but don't recall exactly where.

>>using DLLs now would require big rewrite of code and is unfeasible.
You don't have to convert the entire program to DLLs -- just enough to get you out of your current development standstill. unfeasible??? which is better -- rewriting parts of the code to use DLLs, or stopping all current and future program development. You need a fix to the problem and I think DLLs is the only solution you have.

I think DLLs is the only solution you have.

Ok thanks for the input Dragon. I'll look into it.


mine is 4mb of RAM..
Also while Compiling, Set your options to
"Compile to P-Code"
This compile is faster and will reduce your Exe Size by at least 20%..
I Myself have tried it..
and none of our Clients have problem with Exe (Compiled with P-Code)
and Most of the ERP's what I handle have Total Modules ranging from 300 to 450. And At times I would have opened at least 2-3 of these projects and work without any problem..
I always find shortage of Menus on the Main MDI(as VB supports Max 255 Controls on any module).. But have found solution by using MenuArrays..

If Talking of Maximum EXE Size, Windows can handle.. I have many applications in my System > 15mb... (e.g Oracle9i is 29 mb)


I agree with veena......compile to p-code (psuedo code)....it is faster and more efficient in porting data from comp to comp

One thing that is not mentioned is quoted strings.
These soak up lots of memory

This article has been dead for over six months. Start a new discussion instead.