>>The one twist here is that this application is working with a bunch of VFP-based COM objects. They get instantiated pretty early, and in fact, I've seen at least one case where I can put an error in after that and I don't get the buffer overrun.
>>
>>It appears that the difference may be whether I have READ EVENTS in effect. If I stick an error in right before or right after READ EVENTS, the error handler works as expected. If I introduce an error in code that will run with READ EVENTS in effect, I get the crash.
>>
>>Anybody have any suggestions? For now, of course, I'm commenting that part of the code out, so that I can test other things, but I'd really like to have the memory and status info in the error log.
>>
>>Tamar
>
>I actually ran into this myself when com interop events are firing. Is there anyway to disable the com events from firing while you are doing this? Or can you unload them and do a clean disposal and then reinstantiate them? I work with a dotnet dll that fires events in my vfp app (VFP 9 sp1) and on some error handling this occurs when the com interop events fire while doing any type of memory dump in the error handler.

I'm getting this regularly when Aleksei Grigorjev's commandbars are instantiated (and he's got a .dll but I think it contains only images). I also had to comment out the list memory line from my error handler. If I skip the commandbars and try to reproduce the same error, list memory goes fine, even with a few other COM objects loaded (treeview, listview, some imaging thingy).