Hi Jerry,

No, there usually is no simple way to determine what exact code causes the
C5, as a C5 typically references memory that has been corrupted in some
manner, which may have happened in a very different section of the code.
I've personally always referred  to that as the "poison dart syndrome".  VFP
kind of staggers around after the corruption and falls over in a totally
unrelated piece of code.   Some times, it may even be a corrupted piece of
data or a corrupted index that causes the problem.  These types of
corruptions may be caused by hardware or cabling that's not quite up to
snuff, or on systems that aren't up on the latest patches, etc..  Some OS's
are just more prone to these kinds of problems, or particular printer and
video drivers.  The possibilities/combinations are nearly endless. :(

The only effective mechanism I know is to keep removing code until it stops
doing it.  And then adding it back in until you see exactly what triggered
it.

A C5 dump can provide Microsoft with additional information, so when it
prompts you to send that info to Microsoft, please do so.  You probably
won't hear from anyone about your particular crash, but it is still
evaluated and may help in producing a better product.

Fred
Microsoft Visual FoxPro MVP

PS:
it helps if you at least quote some of the previous conversation, so it can
be determined what the thread is about.  I use IE and have it set so that
once a message is read, I no longer see it, so there is no "thread" to
follow.  When all you do is an empty message, it's extremely difficult to
follow or to even know just who it is your corresponding with.