>>>>All gave the exact same response. Namely: the external windows program opens for a moment and then closes. At the same location, (all serviced from same firewall with virus and spyware shut off) I installed the program and external windows program on several different computers. It is only one computer that is experiencing the problem.
>>>>
>>>>I then substituted notepad.exe for the external windows program. THAT WORKED FINE on all computers including the one in question.
>>>>
>>>>I then wrote a 1 form vfp program and compiled into an exe. That program was able to run the external windows program just fine on all computers.
>>>>
>>>>So the problem is specific to my initial vfp app installed on a particular computer. Everywhere else it is installed it operates fine.
>>>>

>>>Step one: Start vanilla vfp like you did start notepad.
>>>if step one works
>>>   Step two: Start your program via vfp.exe with 
>>>   set step on 
>>>   as second line 
>>>else
>>>   reinstall vfp

>>>
>>>HTH
>>>
>>>thomas
>>
>>Thomas,
>>I am clear on the reinstall vfp if everything else fails. I do not follow everything above that line. Please explain your steps once again.
>
>Oops, on rereading I see I did not specify working on the offending machine, but surmised that as given...
>Reasoning is: Your calling process worked for a long time with your programs [MenuCaller, RunningChild] and barked on the mystery machine. As MenuCaller works on the mystery machine, if you replace RunningChild with Notepad, the calling mechanism seems to be ok. A plain vfp.exe [the vfp IDE, not just a vfp compiled program] should come up like Notepad did. If that works, it is either
>- someting in the runtimes used by your RunningChild.Exe
>- something in the Dll's/OCX etc used by your RunningChild.Exe
>- something directly in the RunningChild.Exe
>
>If RunningChild.Exe works if called via the IDE-Version of vfp, it probably is a glitch in the runtimes used normally. If the program barfs in the IDE as well, running in the debugger may give you a better idea where the program crashes, as you have given no info on the reasons vfp gives for the crash - so I guess either your error handler was not set up at program crash time, the error bypasses the errorhandler or you don't set an errorhandler. Another way to get info on where/how the crash happened, you could run RunningChild.Exe with "set coverage to (aLogfile)" as first statement of the program - under the IDE and the runtimes of vfp. The log should show the last executed line of RunningChild.Exe under both environments. Might give you a better idea on how to proceed.
>
>better now ?
>
>HTH
>
>thomas


Nice,

But no errors are being thrown. The windows external program just opens, stays for a moment and then closes. I ran sysinternals Processmonitor and all file and registry reads and writes have been granted withno reported errors. I will however follow your instructions and get to work as per your suggested path.

Thank you for taking the time to detail this out for me.
BTW... Years ago, VFP9 came with a trial of Installsheild, which was very helpful in gathering up and installing all of the vfp support files necessary to run a vfp app on a target computer's installation. I lost that somewhere along the line. Can you suggest a free Installation package that would gather up, copy and register the necessary support files on the target computer? In this way I can be certain that the runtime files supporting my app are exactly what is running on my development computer.

Neil Gorin