4 Nov
2010
4 Nov
'10
10:24 p.m.
Correct, that's exactly the same as what I found,
and the bug report I filed contains pretty much the
same explanation. I suspect the coder(s) of their
exception handler functions thought the first 2 parameters
should be passed to UnhandledExceptionFilter.
Intentional or not however, this doesn't make them correct.
The only reason I think they got away with it is
because UnhandledExceptionFilter doesn't tend
to use the context, but when it does.. fireworks.
As for "our way around it", I hope it's clear now that
this hack/feature would belong in UnhandledExceptionFilter
or maybe the function it calls, PrintStackTrace.
I've also noticed the additional debug output you arranged
today when the exception code is 0xeedfade.
You can't reuse the 0xeedface branch for this, it tends
to crash on printing the exception text then. A separate
if branch would be needed.
0xeedface was the Delphi 2 exception code, and I suspect
the semantics of the ExceptionInformation parameters
changed after that (which would explain why they changed
the code to 0xeedfade in the first place).
WBR,
Roel Messiant