>>>LOCAL cOldSafety, cMemFile, cStatFile
>>>cOldSafety = SET("Safety")
>>>SET SAFETY OFF
>>>cMemFile = FORCEPATH("ListMemo.txt", SYS(2023))
>>>LIST MEMORY TO (m.cMemFile) NOCONSOLE
>>>cStatFile = FORCEPATH("ListStatus.txt", SYS(2023))
>>>LIST STATUS TO (m.cStatFile) NOCONSOLE
>>>SET SAFETY &cOldSafety
>>>
>>>
>>
>>I'm coming back to this issue after a long time. Wonder whether anybody's run into anything in the last few years that might shed any light here or provide a solution. Not being able to have a memory dump in the error log is a PITA (though, to date, I have been able to fix virtually every bug that's turned up, other than this one).
>
>Swap name creation and list status first, to see if the problem stays at list memory or surfaces at writing to that location with fixed name.

The problem is definitely related to the LIST MEMO, not its location in the code.

>
>IAC and similar to Bill's idea I would make certain to have a unique file name by adding machine name and datetime info into the file names.
>Yes, that adds some housecleaning routines later on - or try to shell out that task to the next lines with pure file handling on
>the still available names. Separates at least possible file locked handling problems from vfp internals.

Good thought, but no dice.

>And if you have solid naming conventions, perhaps play with several lines excluding some variables,
>ga, pa, la and go, po, lo at first...

Interesting idea. Unfortunately, for historical reasons, naming conventions aren't all that strong.

In testing this time, though, it appears that the problem occurs when the error occurs during code in the main app that's called by one of the COM objects (albeit indirectly). The good news is that I now have a test case that seems to always cause the crash.

Tamar