That's exactly what I was thinking of. Thanks for posting the contents, Fred.

>>>I havent really been able to pinpoint the exact line that bums rushes to DOS but basically I have a simple PRG and it scans through all the records of a table and tries to find a corrsponding record in the MAster DBF. It goes upto 22 records successfully then rushes out to DOS not error nothing.
>>>
>>>Any idea what may be happening I have tried REINDEXing
>>
>>Are you running FPDOS under NT (or possibly W2K)? FPDOS may drop out to DOS exactly as you have described.
>>
>>There used to be an MSKB article on this but MS removed all the 2.x specific stuff some time ago. I seem to recall that the problem happened most often when using looping programming constructs.
>>
>>Does anyone have an old (pre-January 2000) MSDN Library and could they look this up?
>
>This may solve some of your problems with FPDOS and NT:
>
>
>PRB: Windows NT 4.0 May Close FoxPro for MS-DOS Application
>Last reviewed: November 26, 1997
>Article ID: Q168396
>
>
>----------------------------------------------------------------------------
>----
>
>The information in this article applies to:
>Microsoft FoxPro for MS-DOS, versions 2.5, 2.5a, 2.5b, 2.6, 2.6a on the
>following platform: NT
>
>
>SYMPTOMS
>If a FoxPro 2.6a for MS-DOS application executes a looping program
>structure, Windows NT 4.0 terminates the FoxPro application without warning.
>No error message or other information appears on the screen. This happens
>both to FoxPro for MS-DOS executable files and programs running in the
>development version of the product. The behavior also occurs on machines
>upgraded to Service Pack 1 and 2.
>
>
>
>RESOLUTION
>You must add a new value to the Windows NT 4.0 registry. Under the
>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Wow key, add a new
>value, DisableVme, by following the steps listed below:
>
>
>Start Registry Editor (Regedt32) and go to the following subkey:
>
>
>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Wow
>
>From the Edit menu, select Add Value.
>
>Enter the following Value name:
>
>
>DisableVme
>
>In the Add Value dialog box, make sure the Date Type is REG_SZ and click OK.
>
>Enter the following in the String Editor dialog box:
>
>
>1
>
>Shut down Windows NT, turn off the computer's power and then restart the
>computer and boot into Windows NT.
>
>Alternatively, you can run the FoxPro 2.6a for MS-DOS program on Windows NT
>3.51, Windows 95 or Windows 3.11. This behavior is not seen using FoxPro
>2.6a for Windows or Visual FoxPro 3.0, 3.0b, or 5.0 for Windows.
>
>
>MORE INFORMATION
>This problem is most frequently encountered when FoxPro 2.6a for MS-DOS
>executes a looping program structure. Examples of this are DO WHILE...ENDDO,
>SCAN...ENDSCAN, and IF...ENDIF statements that place a program in a
>repetitive cycle. Normally, FoxPro 2.6 for MS-DOS runs normally in all other
>circumstances. For instance, developing in FoxPro's development environment
>(interactively with the Command window) or even running a screen with a READ
>CYCLE does not provoke a shut down. However, if any FoxPro for MS-DOS
>application unexpectedly shuts down without producing a error message
>regardless of the activity it is performing, you should consider the problem
>described in this article as a possible cause.
>
>This behavior is not totally consistent across different machines. Some
>machines are able to run looping program structures for many hours before
>the application shuts down. Other machines, however, execute these commands
>for only a few moments before termination of the FoxPro application.
>
>
>
>Steps to Reproduce Behavior
>
>Create a program that contains the following lines of code:
>
>
>DO WHILE .T.
>? FILE("C:\Config.aaa")
>ENDDO
>
>
>Start FoxPro 2.6a for MS-DOS on a machine running Windows NT Server 4.0.
>
>Run the program. Usually, the NT Server 4.0 shuts down the FoxPro
>application in less than five minutes. Some machines, however, may take much
>several hours before terminating the FoxPro application.
>
>While this code example simply executes an indefinite loop while searching
>for a non-existent file, in essence it duplicates behavior that legitimate
>programs perform. Often, programs are written to run in the background while
>passively checking for a file or a condition.
>
>Keywords : FoxDos FxenvOs winnt kberrmsg
>Version : 2.5 2.5a 2.5b 2.6 2.6a
>Platform : MS-DOS
>Issue type : kbprb