>here's the scenario:
>I am running a VFP 6.0 app in Win98 on a Novell network
>
>the user picks one menu choice that involves creating
>a cursor and 2 forms but no reports, then they select
>another option that prints a report. this works ok,
>but then if they try another option thats call another form,
>the system crashes - big ugly blue screen of death, message fatal exception error, etc basically lights out - requires complete reboot!.
>
>the above 3 options in the app are choices from a windows
>style pulldown menu.
>
>option 1:
>
> do form whatever.scx (this calls another form, then both are released)
>
>option 2:
> do form somethingelse
> (this allow the user to create a cursor and print a report
> then release the form)
>option 3:
> do form anotherone
> (crash happens here (right after the load and before the init))
>
>basically, the code is very simple and seems to work fine
>on machines with foxpro installed.
>One other machines I have all the required files in the executable
>directory (or at least I think all the files)
>
>questions:
>what exactly are the required files and DLLs for an exe to run?

In DISTRIB.SRC, there's a file VFP6R.DEP that lists the file dependencies for the VFP6 runtime. if you aren't using Setup Wizard to put your runtime files in place (something that I'd recommend doing), you need to become familiar with this file. Anything marked as VITAL is mandatory; you can see what files another file references in the Uses# lines in the .DEP file.

>why does this crash happen only if a report is run?
> (otherwise everything works ok)

This is very likely related to your print drivers, as Erik suggested; the ones I've had the most trouble with have been HP-supplied drivers. The best workaround for me has been to back off from using the HP driver, to instead use the drivers supplied by Microsoft in their operating system distributions, and in many cases this involves going back to an earlier, equivalent driver (I use the HP IIIsi driver on the NT distribution for the 5si printers, for example.) Severla people have posted workarounds suggested by Micrsoft involving resetting the floating point processor state, and these have helped to a greater or lesser degree; I've found that, for me, backing off to the earlier driver costs me very little and has avoided the problem entirely.

-snip-