I am currently developing an application (~1.2MB Exe) using
VB 4.0a EE. I am using Windows NT Workstation 4.0 (1381:SP2)
and Windows 95 (4.00.950a) as the development platforms.

The problem is, the application crashes (seriously) whilst running
on *Windows 95* within the VB development environment, often at random,
quite often *not* repeatably. The system crashes with a page fault,
for example:

   "VB32 caused an invalid page fault
    in module MFC40.DLL at 0137:5f80297a"

...and ultimately...

   "VB32 caused an invalid page fault in
    module KERNEL32.DLL at 0137:bff9a0cc."

Even when the application is built into an .Exe the system is still
unstable and the same errors occur, but we have only seen the crashes
with the .Exe more recently as the .Exe has grown in size (about the
last 200KB worth).

All said... we do not experience any of these problems when running
in the development environment or as an .Exe on Windows NT Workstation.

We are using Windows Sockets, and I am aware of the Kernel update to
fix memory leak problems (which is available from Microsoft's web site
http://www.*-*-*.com/ ), but this poses
us with a problem. We have a requirement to use non-US versions of
Windows 95, for which this patch isn't available. (And we're developing
on the Pan-Euro version at present (which also doesn't allow the use
of this patch)).

I am also inclinded the think this isn't the problem, since sometimes
the application can crash very quickly (within a few minutes - and very
few (3 or 4) Windows sockets calls).

What I'm looking for are...
1> Suggestions on how to minimise the crashing and ideally eliminate it!
   I think the general, freeing objects, trying some static functions,
   checking API calls are valid etc. are covered.
2> Suggestions on debugging the application, are there are Windows 95
   debugging tools (e.g. Dr. Watson type application (although I beleive
   Dr. Watson isn't available for '95)) that may provide more useful
   debugging information in the event of a page fault.
3> Are there any ways in which VB can report on stack use etc. so that
   it can be monitored within the application?
4> Is there a code profiler (as such) that will read VB code and spot
   nasties? (Like "Break on all errors" in Tools|Options).

As a rough guide, we are making API calls for Windows sockets (same .Dll
for both '95 and NT platforms), we are using Microsoft common controls,
TreeView, Tabs, ListView etc., DAO 3.x, DBGrid and standard Microsoft
Grid.

A reply to the newsgroup and e-mail would be very much appreciated.
--
Regards
Darren Jackson, Birmingham, England

Home : http://www.*-*-*.com/

I would tend to suspect one of the controls and not the size of your
application.  I have never had a problem with size but I have almost always
had a problem with one of the controls both 4rd party and the ones shipped
with VB4.  I usually am able to find a work around which is the good news;
the bad news is that it is often hard to find the offending control.

Try to eliminate each of the 3rd party controls 1 at a time.  This will be
difficult; but, replace the controls functionality with functions that
return dummy data.  Also try commenting out large routines to narrow the
problem area down.

Good luck
-Bruce Callen

Now, i've got a stable version of my program, but unfinished, then i got
to pursuit the developpement, with God looking at me for no crash again.

I remark that the 'Refresh' method of a DATACONTROL could cause ithis
failure in certain case. It's a first track to take care.

Well i hope i help you and give tou hope to continue with VB4 :)(

Bye

                                Tibo