>So, just tested a bunch of things. DOEVENTS in various places doesn't help. Neither does a wait of up to 5 seconds after exiting the modal form. I confirmed again that the form reference variable was null after the form closed, so I don't think this is a dangling reference.
>
>But, as I learned before, stepping through the code prevents the problem. I'm wondering if, rather than timing, the issue is having focus get set elsewhere before the other form opens. I just tried setting focus to something on the app's main form, and that didn't help. Wonder if I can set focus outside my app and then bring it back?

It sounds to me like something is getting stepped on, and not reset. I'm not 100% sure the VFP debugger works this way, but some debuggers work by creating a sandbox for code. To do this, the debugger has to save state, and restore it afterwards. If the VFP debugger works that way, maybe that's why the problem doesn't occur during debugging.

If you store the results of LIST STATUS before and after, are there any differences? Or with any system variables using LIST MEMORY?

A few other out-there ideas to play around with:

- try the ancient CREATE VIEW / SET VIEW commands to store, then restore the VFP environment - or, your more modern equivalent, if you have one

- experiment with .LockScreen in strategic place(s) (maybe before you start your COM processing)

- experiment with any SYS() settings that may be COM-related