Out of Memory - Runtime error 7 on some user machines

Plenty of free ram does not mean plenty of free conventional memory.  You didn't mention it, but I would think your using DOS/Win3.1x.  That being the case, check the loading of TSR's and move them high.  You want as much free memory as possible in the first meg or conventional memroy space.

An easy way to do this is to backup autoexec.bat and config.sys and run memmaker.

My fault.  I should have mentioned this is 32 bit application on Win95.

Has anyone used it in an NT 4.0 environment?

Works fine on most 95 and NT machines.

Regarding, have you mentioned that it is a 32 bit application.  First, remember that VB5 is ONLY 32 bit.  Second, Windows 95 sits on top of good old dos and as such it does indeed care about how much conventional ram is available.  So, before dismissing the suggested answer,  try checking this also.

Taking hdbash's comment into consideration, look the mix and types of applications that are loaded stay resident on that 2%.  Then remove those that are not needed, if nothing else for testing, until the application works.  You can then make a determination as to what is needed and what can be permanently removed.  Worst case is  that on some machines apps would have to be stopped and started as needed.  Of course, knowing the problem, may allow you to modify your app to circumvent that.

Any thing you might be doing with big arrays, or keeping track of user histories etc.?

Is the error repeatable on the machines that are reporting it?

Might be an error that is not hit too offten, but is occuring because a user is doing something unexpected.

Lastly, Vb4 or vb5

Chris

D'oh!  just saw your vb 5 comment.  What Service pack are you running for vb 5?

Doing a lot with the TSRs isn't much of an option.  The program is distributed on the net, and many users aren't really willing to spend a lot of time helping debug.  I have SP2 for vb5.  I do have some pretty big arrays, it just bothers me that this works fine on most machines.

What is a good option instead of big string arrays I'm using to accomplish the same thing?

Depends a lot on how irritated they are with having to restart the app.  given the frequency of occurance, I would suspect itinerant 16 bit app or mix apps that you might find by simply looking at the active processes in the OS diagnostic.

Are you doing database access/manipulation?

The Access Jet relies on physical memory for transactions and transactions often use a lot more memory than expected.

no database access at all

mmm!

No recursive calls to anything?

no.  I really think it is a bad .dll file version mix of some sort.  One one users, I was able to remove a slider from the main form, and it went away.  On others though, it doesn't seem related to that control at all.

Are you using HUGE forms/modules? I've run into this problem 'quite' a few times though it has been in VB 3. But the root problem is the same. There's a fixed availability of memory allocated for a form - stack (for local declarations) and heap (for module/global) memory. Usually we use a lot of 'stack' memory as most of our varibles are declared locally. When Windows runs out of memory to allocate, you get this error.

Solution.
1.Check if you use too many variables, arrays in a local function.
2.Avoid long names(function names, variables, objects, forms...). Reducing a variable name's length can save you space.
3.Change a couple of variables (arrays) from local to module level declaration can help you avoid this.
4.Change module level (Private)declarations of Enums and user defined types to 'Public' declarations (I know, not a good programming practice).
5.VB5 recommends form/module size not to exceed 64K to avoid this problem.

This problem is related to something on installation, such as a wrong version or missing .dll file.  If I create install with InstallSheild, I sometimes see this problem on a few pcs, but if I do it with setupwizard, it will correct it on those machines.

In VB3 you can get an out of memory error when you attempt to do math on a declared single precision variable which happens to be zero. Sorry. I just have a lot of VB3 code laying around. But I would test it anyhow.

I'm shure that RAM or diskspace isn't the problem.
My tip:
Be careful with recursive subs or functions. You also can create recursive subs, even if you don't want to. For example, you have a control named Control1. Manual setting of the focus can cause a recursive loop in your prog. Look at this:

Sub Control1_GotFocus
  DoSomeThing
End Sub

Sub DoSomeThing
  ... bla
  ... bla
  ... bla
  Control1.SetFocus
End Sub

This is only an example. I don't know what your app really does. Maybe this tip will help you.

Tilmann