I do not agree with Sergey, Hank and Thomas,

I've use the SET COVERAGE command in several cases to debug these types of errors.
Just let it crash and when the error occurs, just terminate the process.

The last line in the log should give you the point where it breaks

Walter,



>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.