Memory Errors in Large Application

I'm working on a poorly-designed app with 97 forms, 38 bas modules, and 61 classes, all contained in one executable (over 7 megs). In addition, there are calls to 10 external dlls, including some Win APIs. The clients have 64 or 80 megs of memory, and plenty of available disk space.

The problem is that we're experiencing random, intermittent VB application errors - memory couldn't be written/read - that typically aren't reproduceable. 7 machines can be running the exact same source code, but don't experience the same problems at the same time.

Can anyone point out some areas that should be investigated as the source of these problems? Surely executable size is one of them. How large can VB reasonably handle one exe? What other culprits might be involved?
Who is Participating?
I have had this problem with one of my projects in the past and the following has helped

(1) reduce the number of forms that are displayed simultaneously
(2) Clear all objects when a form is discarded
ie. Set ObjectVar = nothing, Set Form1 = nothing
(3) When loading a form check for available system resources and memory. If it gets low (set a limit, you need to investigate what is an acceptable level), display a message to the user to close some forms or other apps and stop loading.
(4) It may be the way you are using the API that can cause memory leaks in your program. The easiest way to determine this is to use a package such as BoundsChecker - which can be identify memory leaks and improper usage of APIs
(5) Remove unused code
(6) If some forms are similar in design and only have a few extra/less controls then create a generic form and add/remove controls via code
(7) If you use bitmaps in your forms then store them in a resource file instead and load them in your form at run time (ie. via code)
(8) Try creating OLE Servers (called ActiveX EXEs now) which contain the different functionality of your modules
eg, 1 form as an ActiveX EXE that you call from within your code, this way if an error occurs you can identify which form is causing the error

Cut your application in several little application.

It seems that this is not a good written application
I think You're running near the limit of objects VB can handle, that is, VB doesn't give You warnings whenever compiling the app but at run time it hits its limits and crashes miserably, I suggest You to take a look at VB documents about project limitations (objects, forms and so on) and to check out if it's the case, it the problem is this then You'll need to sit back and think about redesigning Your app splitting it in different pieces (EXEs) and linking them together by wrapping them inside some ActiveX "macro" classes

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Does this code have any error handling?  Do you know exactly what is happening when the sporatic crashes occur?

FYI  NuMega makes a product called FailSafe (I have downloaded a trial version, but haven't had the time to unzip and play with) which presumably would aid in identifying the failure points, i.e., call stack, memory state, blah, blah .... However this wouldn't necessarily tell U squat about the root of the problem.  NuMega business is predominately (to my knowledge) debugging and they have branched into the VB.  They have other tools which are diagnostic in nature, but my experience with their C/C++ tools (possibly not relevant to the VB tools) is that the tools gag on large complex applications.  I suspect that the utility of these IDE add-ons is when it is used during development to avoid problems as the are developing, not just looking at the resultant beast and expecting a magic bullet, like fix this one memory leak and life will be good.

Ok, I'm off my soapbox.

BTW, I would be interested to here from anyone who is using the NuMega VB Suite and has comments.

The most common memory related errors are caused by:

Running out of GDI resources because of having too many windows open - and/or hiding windows instead of unloading them.  Be sure that when the application closes a window it unloads it, then sets [form name] = nothing.

Too many controls on a form - usually not an intermittant problem - limit of 255 controls per form.

Dynamically allocating too much string space.  I think there is a 64K limit to the amount of space you can dynamically allocate (try redimming an array to hold 10,000 text lines and you'll probably hit this error). Be careful of recursive routines that declare a lot of local variables, as this will cause the same problems.

Coding forms or modules with more than 64K of code (codespace is limited to 64K per module)

You can also get the error you mentioned when calling external DLL functions if you are not careful about passing the parameters correctly.  Remember, VB passes everything by reference (by default) except Strings which it always passes by value - however when passing strings you should always explicity put the word ByValue in front of the string parm in the declare statement as this tells VB to append a null termination character to the string (which most C programs expect).

Also, be aware that some of the Declare statements in the WinAPI help file are incorrect, they might miss the ByValue in front of some strings, or they might declare something as Long (or whatever) when it might be an optional parameter and should be declared "as Any".

Very rarely, will you have problems with referencing deallocated variables, but if you are doing any multi-threading, this is a constant cause of this error.

Hope this gives you something to go on.


Looks like dm_14 and I were typing at the same time, sorry for the duplication.  Also, as for the size of the EXE.  Yes, it is excessive, but I have seen VB apps that size that were successful.  Windows swaps code in and out of memory if necessary, but with the amount your users have, it shouldn't be a problem (maybe it will be slower).  Perhaps, as someone suggested, you could split this out into two or three related applications?
cdickersonAuthor Commented:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.