During development I've opted to using Windows SEH. As I'm still working on parts of the base code and haven't quite figured everything out yet, there are cases where I need to debug hardware exceptions that occur due to code changes that affect completely different parts of the program. This is further complicated by the fact that I'm running a heavily multithreaded environment with job stealing and issues can easily propagate across threads.
My current exception handling scheme is pretty straightforward: at root level each thread provides its own __try/__except block, which is the only handler for that particular thread. I guard most heavier functions I'm working on so I have access to a rough flow graph of my own, including a runtime stack trace of any guarded functions. The function guards track program flow per-thread, which means this information should be available when an exception is caught by that particular thread's handler. That is, it is available - at least when I throw an exception myself.
When a hardware exception occurs, however, the entire program state becomes corrupt. The __except handler is properly called, but two things happen:
1) the state that stores my own stack trace becomes invalid. When I step into the handler, the structure that holds the program state seems to have a moved to a base address of 0xFEFEFEFE. I'm not sure why this happens.
2) more importantly, when setting a breakpoint in the handler, the debugger provides no stack trace extending back further than the function in which the handler resides. This means that despite the extensive information that should be available to me, I can't even gen an estimate as to where the problem occurred either from the debugger's stack trace or my own
Why is this and/or what am I missing and/or doing wrong?
In short, what I want is a reliable way of localizing hardware exceptions - if the debugger won't show me where, I'd like to at least be able to access my program state inside the exception handler so I can get a rough idea.
