2

I want to enable full logging of exception in my c++ program. All I want to do is to catch software/hardware exceptions in seh catch hanlder and then print full backtrace of exception (I am primarly interested in origin of exception - call stack is enough for me).

__try
{
     difficult_task();
}
__except(my_seh_filter(GetExceptionInformation()))
{
    // How to print full backtrace of exception here?
}

I know that I can print callstack (via StackWalk64 or CaptureStackBackTrace) and I can get address/context of exception from GetExceptionInformation. But I don't know how to get full backtrace of exception in catch handler. It seems like impossible because some special storage for storing exception backtrace is needed, because stack unwinding will change call stack. (SEH provides only states of registers and address of exception).

Alex Aparin
  • 4,393
  • 5
  • 25
  • 51
  • you need do this in `my_seh_filter`. inside `__except` block stack already unwinded and too late get stack trace – RbMm Feb 22 '18 at 10:04
  • @RbMm, As I understand stack will be changed even at the moment of execution of seh filter? – Alex Aparin Feb 22 '18 at 10:05
  • `my_seh_filter` is executed on stack *bellow* exception. here you can get full stack trace of exception. but inside `__except` block - stack already up and too late trace it – RbMm Feb 22 '18 at 10:08
  • @RbMm, I am not sure that You are right. Let's suppose exception occured inside `difficult_task` method (suppose such method does not have any exception handlers). In such case stack unwinding will be processed to our external exception handler. Stack will be changed at the moment. Then execution of seh filter will be performed - that's why we cannot get full information of exception backtrace – Alex Aparin Feb 22 '18 at 10:12
  • no, you mistake. all filter handlers will be executed on stack **below** exception. until some not return `EXCEPTION_EXECUTE_HANDLER` so the `my_seh_filter` right place to do stack back trace – RbMm Feb 22 '18 at 10:46
  • @RbMm, Oh thanks. It seems like I should learn seh more carefully. You are right - I checked out it. – Alex Aparin Feb 22 '18 at 11:08
  • 1
    when exception raised - kernel copy context and exception record to user stack (of course bellow exception esp(rsp)) and call `ntdll.KiUserExceptionDispatcher`. it call `RtlDispatchException`. this api walk by veh and seh handlers - call it, until some not return `EXCEPTION_EXECUTE_HANDLER` or `EXCEPTION_CONTINUE_EXECUTION`. so handlers called in stack **below** exception. but after unwind on `EXCEPTION_EXECUTE_HANDLER` code in `__except` block already called with stack pointer equal to `__try` block - so exception stack already lost here – RbMm Feb 22 '18 at 11:16
  • @RbMm, IS such behaviour guaranted for all application supported seh exception (not matter whether it x86 or x64)? I definitely should reread documentation about it – Alex Aparin Feb 22 '18 at 11:29
  • yes, this is platform independed – RbMm Feb 22 '18 at 11:31
  • Why do you want to re-implement this? You could use [MiniDumpWriteDump](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680360.aspx), and have the system do all the heavy lifting. Load the dump up in a debugger, and get all the symbolic information you want. Unlike `StackWalk64`, this doesn't require you to ship debug symbols. – IInspectable Feb 22 '18 at 13:21
  • @IInspectable, it seemed for me as more complex API for working. And I did not dive deeply to it for learning. – Alex Aparin Feb 22 '18 at 13:39
  • 1
    The only complexity is, that you need to call it from a separate process (and implement some sort of IPC). On the upside, it provides really helpful information, such as variable content. A stack trace usually doesn't provide enough insight to analyze anything but the most trivial errors. – IInspectable Feb 22 '18 at 13:52
  • @RbMm, you are maybe interested, I figured out that such approach is not worked on x64. For more information you can see at https://stackoverflow.com/questions/48985041/different-seh-filtering-in-x86-and-x64 – Alex Aparin Feb 26 '18 at 13:57
  • @LmTinyToon - what you mean under *not worked* ? all perfect worked on both x86 and x64 – RbMm Feb 26 '18 at 14:01

0 Answers0