We have an arev program that when run will in about 1 out of 10 times cause the ntvdm to crash. The pc then reboots since the Win2k "System Recovery" is set to restart on crash.

We suspect a memory issue and so what is 'enough' DPMI memory in the PIF Memory tab setting. Right now we are using 16384 which seems to be a default. Would 4096 be a better amount? Or more?

Also would checking the Protect box in the Conventional Memory section provide some 'protection'?

Finally I have tried to add an Initialize() call into our crashing arev program to reset the session before the program runs, but this causes some bizzare TCL behavior (menu drop-downs that are fixed and inoperable for example). Is there an acceptable way to reset an arev session to close to inital state?

Arev is not DPMI "aware" and will not use XMS so "AUTO" is probably the best setting.

The only DOS Database program that I knew of that was capable of running Protected Mode was FoxPro for DOS.

Are there any other symptoms prior to ntvdm crashing e.g. a string space format error or the like? Is it always the same workstation that crashes? And out of interest, what is your program actually doing?

I've seen similar things with dodgy memory as you suspect, especially if a host of expendable routines are called, say in a loop. I've also had ntvdm blow out sessions where a lot of screen updates were happening (progress bars, colour changes and the like.) I never worked out why this actually was - I just stopped doing so many fancy screen updates!

It is the same program on different workstations and the problem seems to be the triggered during the first PERFORM "SELECT…..". This program does toss up quite a few MSG boxes as it is going along, but seems to die before it gets past the first Select.

The session has been running other r/basic programs, usually for days or hours.

We do use the Status line updates A LOT. FYI

Follow up on the NTVDM question.

We have confirmed that there is a memory leak each time we shell out to another CMD shell from ARev (PCPERFORM or SUSPEND) and then return back to Arev. Each shell-return to Arev leaks 4K of memory.

This leak is reproducable from our Win2k session just running CMD (not from Arev just MS DOS pif) and then doing a shell to another CMD.

Does another know if there is a solution/fix to this leak?

We have a process that converts thousands of documents from the legacy system into HTML files. I've not noticed such a memory leak, and we perform thousands, if not tens or hundreds of thousands of performs sometimes per session (per day even). This is on Arev 2.12.

Now we reboot weekly but for reasons other than memory leak.

The NTVDM memory leak has been around since Windows NT 3.x. There was an old thread about it years ago and someone mentioned a memory manager to clear it up.

It used to be NTVDM would stay loaded in memory even after the processes it was running were closed.

On my Win2K workstation I use CMD.EXE exclusively rather than COMMAND.COM which seems to alleviate some of the problems with NTVDM memory leaks.

I would be suspicious that something in your select statement is causing problems.

Here is the select. It is the first select of several selects since the 'field' on which we are selecting is indexed and this gives us the most speed. Records are very small in this table (around 150 bytes) and with 3.5 million records.

stmt=SELECT table WITH field EQ 'R'

PERFORM stmt

where: table is the table name

     field is a symbolic that returns the 1st @VM of a mv'ed field

           that contains a list of codes (steps the record has

           has been thur in processing like N=new,R=Ready,I=Invoiced

Interesting. We use cmd.exe as well.

The main reason I gave up on Win2K's COMMAND.COM was that it didn't seem to recognize long file names for directories.

I had a "My Orders" folder on the root but doing a cd "c:\my orders" or cd c:\myorde~1 would not work. A dir command would show the folder fine but a dir "C:\my orders" dir "My Orders" from the root or dir "C:\myorde~1" wouldn't work either.

Are you sure you were specifying the right short name? To find the right short name, you can DIR /X, even from command.com.

I know this response is late, but… select statements using non-existent dict items will crash as you describe, as will function calls to non-cataloged or non-existent functions. If table and field are variables, are you sure you are calling a field that exists in table or dict.voc?

Also, we have arev process servers running constantly 24x7. Do not see memory leaks as you describe. BTW, don't count on Task Manager to accurately report memory usage (i.e., detect memory leaks).

Much delayed update: we are experiencing this leak now. We're now on a more current Windows version.

Seems to be happening both on Windows 2000 and Windows XP machines, actually. I didn't realize we still had Windows 2000 machines.

View this thread on the forum...