Win32 Structured anomaly Handling (SEH) (i)

Of all the features provided by the Win32 operating system, perhaps the most widely used but most lacking document description is structured exception handling (SEH), and when you consider Win32 structured exception handling, you may think of terms such as _try,_finally and _except. You can find a good description of SEH (even remedial) in any book about Win32. Even the Win32 SDK has a fairly complete overview of structured exception handling using _try,_finally and _except.

With these documents, why do you say SEH lacks documentation? In fact, Win32 structured exception handling is a service provided by the operating system. All the documentation you can find about SEH is a run-time library that describes the specific compiler that wraps the operating system implementation. _try,_finally and _except These keywords do not have any magical place. Microsoft's operating system and its compiler series define these keywords and usage. Other compiler providers simply follow these semantics. Although the use of the compiler layer of SEH can restore some of the original operating system level SEH deal with bad Word-of-mouth, but in the public eye on the original operating system SEH details of the processing feel still.

I received a large number of people e-mail, all want to implement compiler-level SEH processing, and can not find the operating system features provided by the relevant documents. Usually I recommend referencing Visual C + + or Borland C + + run-time Library source code. Alas, for some unknown reason, compiler-level SEH seems to be a big secret, and neither Microsoft nor Borland provides the core source code for SEH support.

In this article, I dissect a layer of SEH to reveal its most basic concepts. I intend to separate the functionality provided by the operating system from the functionality provided by the compiler through code generation and Run-time library support. When I drill down into the key operating system routines, I will use Windows NT4.0 on the Intel platform as a basis. But most of what I'm about to describe also applies to applications running on other processors.

I intend to avoid involving real C + + exception handling, which uses catch () rather than _except. In fact, the real C + + exception handling implementation is very similar to what is described in this article. But C + + exception handling has some additional complexity that affects the concepts I want to involve.

Through an in-depth study of obscure. H and. INC file to summarize Win32 SEH composition, I found one of the sources of information is the IBM OS/2 header file (especially bsexcpt. H). Don't make a fuss about that. The SEH mechanism described here was defined at its source, and Microsoft still developed the OS/2 platform (OS/2 platform was originally developed by IBM and Microsoft, and then for a variety of reasons the two companies did not continue). So you'll find that the SEH under the Win32 is very similar to the OS/2 under the SEH.

A brief analysis of SEH

Overall, the SEH is mighty, absolutely overriding, I will start from the nuances, in my own way a layer of research. If you're a piece of white paper and you've never been exposed to structured exception handling before, that's best. If you have used SEH before. Try to clean up the words of _try,getexceptioncode and Exception_execute_handler in your head, and be a novice. Take a deep breath, are you ready? Okay, here we go.

Imagine that I told you that a thread was wrong and that the operating system gave you an opportunity to notify the thread of the error, or, more specifically, the operating system calls a user-defined callback function after the thread has failed. This callback function can be anything it wants to do. For example, it can fix any error caused by any cause, or play a. wav file. Whatever the callback function does, it finally returns a value that tells the system what to do next. (The situation described here is not necessarily exactly the same, but close enough.) ）

Assuming that your code is confusing, you have to come back and see what the callback function looks like? In other words, what kind of exception information do you want to know? In fact, it doesn't matter, because Win32 has helped you decide. An exception callback function is as follows:

EXCEPTION_DISPOSITION
__cdecl　_except_handler(
struct　_EXCEPTION_RECORD　*ExceptionRecord,
void　*　EstablisherFrame,
struct　_CONTEXT　*ContextRecord,
void　*　DispatcherContext
);

The prototype is derived from the standard Win32 header file EXCPT. H, at first glance it's a little bit extraordinary. If you study slowly, it's not that bad. For example, the return type (exception_disposition) is ignored. Basically what you see is a function called _except_handler, which has four parameters.

The first parameter is a pointer to the EXCEPTION_RECORD structure, which is in WINNT. H is defined as follows:

typedef struct _EXCEPTION_RECORD {
DWORD Exceptioncode;
DWORD ExceptionFlags;
struct _exception_record *exceptionrecord;
PVOID ExceptionAddress;
DWORD numberparameters;
DWORD Exceptioninformation[exception_maximum_parameters];
} Exception_record;

The Exceptioncode parameter is a number assigned by the operating system to the exception. You can be in WINNT. H file in search of "Status_" start #defines content can get a series of different exception codes. For example, Status_access_violation is a familiar exception code, its value is 0xc0000005. More complex exception encodings can be NTSTATUS from Windows NT DDK. H files found in. The fourth element in the EXCEPTION_RECORD structure is the address where the exception occurred. The rest of the Exception_record field can now be ignored, without having to worry about it.

The second parameter of the _except_handler callback function is a pointer to the build frame (establisher frame) structure, which is a vital parameter in SEH, but it can now be cared for.

The third parameter of the _except_handler callback function is a pointer to the context structure. The context structure is WINNT. H, which represents the value of a register when a particular thread exception occurs:

typedef　struct　_CONTEXT
{
DWORD　ContextFlags;
DWORD　Dr0;
DWORD　Dr1;
DWORD　Dr2;
DWORD　Dr3;
DWORD　Dr6;
DWORD　Dr7;
FLOATING_SAVE_AREA　FloatSave;
DWORD　SegGs;
DWORD　SegFs;
DWORD　SegEs;
DWORD　SegDs;
DWORD　Edi;
DWORD　Esi;
DWORD　Ebx;
DWORD　Edx;
DWORD　Ecx;
DWORD　Eax;
DWORD　Ebp;
DWORD　Eip;
DWORD　SegCs;
DWORD　EFlags;
DWORD　Esp;
DWORD　SegSs;
}　CONTEXT;