+
+ /* __except (mswindows_handle_hardware_exceptions (GetExceptionCode ())) {}
+
+ The line above is original. Unfortunately, when an error is tripped
+ inside of the handler (e.g. during Fbacktrace()), and the handler for
+ the handler is invoked, it correctly notices that something is amiss
+ and it should just return -- but it returns EXCEPTION_CONTINUE_SEARCH,
+ which causes the debugger to be invoked debugging the handler code in
+ this function -- and WITH THE STACK UNWOUND so that you see main()
+ calling mswindows_handle_hardware_exceptions(), calling Fbacktrace(),
+ and a crash a couple of frames in -- AND NO SIGN OF THE ORIGINAL CRASH!
+
+ There's some real weirdness going on in the stack handling -- unlike
+ in Unix, where further crashes just keep adding to the stack, it seems
+ that under the structured-exception-handling, the stack can actually
+ bounce back and forth between the full stack at the location of the
+ exception and the unwound stack at the place where the __try clause was
+ established. I don't completely understand it. What I do know is that
+ returning EXCEPTION_EXECUTE_HANDLER on nested crash has the effect of
+ aborting execution of the handler and going back to the outer filter
+ function, which returns EXCEPTION_CONTINUE_SEARCH and everything is
+ hunky-dorey -- your debugger sees a crash at the right location with
+ the right stack.
+
+ I'm leaving in the trickier Unix-like code in the handler; someone who
+ understands better than me how the stack works in these handlers could
+ fix it up more. As it is, it works pretty well, so I'm not likely to
+ touch it more. --ben
+ */
+
+ __except (EXCEPTION_EXECUTE_HANDLER) {}
+