Thanks, everyone.

I might have given the wrong impression - the app isn't C5 crashing, it's just throwing an unexpected error.

It turned out to be not too hard to graft in my own error handler, which pinpointed the line of code throwing the error. An object that is expected to exist does not; next step, to find out why that object doesn't exist.

>Hi Al:
>
>To add something over what Sergey, Hank and Thomas have said, I think the problem could be a bad garbage collection caused in the code added to the framework.
>
>If the code added is not too much (I mean, not tooooo much:) then you could compare the changes between the original framework and the changed one.
>
>One typical gc error is not nulling/releasing object references adequately, which causes a C0000005 error because the nature of the execution do not allow VFP to gc it automatically in time, so some references keep accumulating until the C5 error shows up. That's why in some cases youcan see that debugging by hand --line by line-- the error is not reproducible, because in this situation the act of debugging this way introduces the sufficient delay and IDLE time to allow proper automatic gc, and that's why I always say to do gc manually.
>
>Best Regards.-
>
>
>>I'm trying to debug a (mostly) reproducible app crash. The code is somewhat abstract/complex (based on a modified Visual MaxFrame Professional 5 framework). The framework has an error/crash handler but in this case it's not yielding useful information.
>>
>>I believe I know roughly where it's crashing. I've created a debug version that includes debug info and SET STEP ON ahead of the crash. This also seems to be of limited use in this case:
>>
>>- If I hit Resume in the Debugger, I get the crash
>>- If I single step through the (tons of) code, it does not crash.
>>
>>My next thought was to inject my own crash handler and see what it records. However given the nature of the framework that might be tricky.
>>
>>Then I thought about SET COVERAGE - turn it on at some point before it crashes, let the app crash, then see what gets recorded. That's easy to implement and I duly get an output file.
>>
>>Having never used it before what I was hoping to see was a sequential log of the commands that were run but at first glance that doesn't seem to be the case. I've tried looking at the log using both the native VFP Coverage app and Martina Jindrova's CVP.exe but I don't see any way to examine a log of commands that were run towards the end of the log file.
>>
>>Again, I'm new to using SET COVERAGE so I may be misunderstanding what it is/what it can do, or maybe I'm missing something obvious.