Sergey and Hank have already written most of my thoughts - as coverage logs are opened exclusively to the process for perf reasons, chances are that the last entries will not be on disk after C000005 crash or termination via task kill. This is the reason I argued for traditional logging a few days ago for Dmitry in a similar question (where the task is not killed), but you could be lucky if you add a set coverage off to the start of the unsatisfactiry error handler and if this line is reached you should be ok. But as Coverage itself induces different timing into the runtime, the error might be avoided under coverage operation.-((

Coverage good for a quick test, if sufficiently close to the error - but if it does not work, either sprinkle in generic hooks to logging calls / doevent cascades or hook those more elegantly and with less source locations to modify via bindevent. Probably better in situations time or event critical - create a special eventhooker prg and call when suspended earlier or at special afterinit time...

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