I doubt it'll help you. Most likely info you are looking for will still be in memory (buffer) and not written to file at time of crash.

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