This is the last post related to the internals of structured exception handling (SEH). In this post, we look at the summary of the exception handling and dispatching, a WinDbg extension ‘exchain’ to view the chain of registered exception handlers. We start by inspecting the disassembly of the exception handling code. We look at how the exception handler frames are created on the stack and unwinded as the programs execute. Next, we use the WinDbg extension to display the exception registration records and understand the nested structure in case of nested __try, __except block. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.
Let’s take a look at the code and compiler-generated disassembled code again to understand how the registration record is created:
Continue reading “Everybody likes automation (!exchain) – Exception Handling (Part 5)”
The C programming language does not offer any support to handle exceptions in the program and this is one of the major differences between C and C++. The Structured Exception Handling (SEH) is an extension to Microsoft C++ and C language support. Although, it is recommended to use the in-built exception handling mechanism if you are using C++ because it helps with the portability of the code across platforms. But, Microsoft compiler allows us to use SEH with C++ and C. The SEH provides a way to handle resources (memory buffers, synchronization primitives, etc) in case the program flow is interrupted due to software or hardware exceptions.
The SEH mechanism which was mentioned in the first post is :
- Exception handler – __except block: called in response to an exception.
- Termination handler – __finally block: always called.
When the developer defines the SEH block (aka exception frame), it gets installed on the stack and with the unwinding of the stack, it gets removed. The exception can be caught in the same function or the caller function. In terms of unwinding the stack, if the exception is unhandled in the callee, it goes higher up the stack in the previous or caller’s frame and appropriate action is taken. So the above two SEH mechanisms may be different in terms of functionality but as far as unwinding the stack is concerned, they are similar.
In this post, we dig into the flow of the exception in user-mode (supported by OS) and in the developer’s code (exception or termination handler written by the developer). It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.
The Thread Environment
Let’s take a look at the stack once we return to the user-mode after the ‘First Chance’ exception (see previous post).
Continue reading “Back to the Start – Exception Handling (Part 4)”
The exception hierarchy of the operating system allows the developers to handle both hardware and software exceptions in a unified way and also improves the modularity of the code being developed. In the previous post we observed how the disassembly of a guarded code (__try, __except) block is different. In this post and explore how the system takes control when the exception happens. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.
Catching Exception In Debugger
Using WinDbg, load the application symbols during loader break and set a breakpoint on ‘main’ routine Continue reading “The Trap of Operating System: Exception Handling (Part 2)”