windows system, in order to ensure strong and stable system core, in order to ensure strong and stable user program provides exception handling mechanisms to help programmers and systems personnel to deal with exceptions. Simply put, when the CPU executes code exception occurs, an exception will inform the operating system, the operating system first program itself will handle the exception, the program itself has the ability to (registered in the program have an exception handler), the program continues run; the program itself is not capable of handling (exception handler is not registered in the program), this exception has not yet been processed, the operating system will have to deal with, the user is prompted to call the debugger to debug or end the program. If you have a debugger in participation, the program is abnormal, the operating system will not process an exception to the right of the program itself but the debugger, the debugger can continue to turn the handle to the right program, you can also deal with their own. In order to complete the process of speaking in front, Windwos information provides a mechanism SEH and VEH two treatments. The following are brief.
A, SEH exception handling mechanism
SEH is a windows operating system exception handling mechanism, called structured exception handling, use __try in the program source code, __ except, __ finally keyword to implementation.
Windows operating systems (from Windows95 onwards), each user thread, have set up a linked list of exception handling frame to handle unusual events. Each frame of the exception handler list by two members, namely, an address on the list, the current address of the exception handler, the composition of the structure _EXCEPTION_REGISTRATION_RECORD. Exception handler means a processing exception callback function (callback function). Thread information block (thread information block) at the beginning (i.e., FS: [0] at the memory, FS is a segment register of the CPU) contains the address of the head table entries exception handling frame list. Abnormal events encountered during program execution is interrupted, the operating system RtlDispatchException function from FS: [0] points to the head of the linked list calls each node contains the exception handler callback function until one exception handler callback function returns 0 It said it had handles the exception, the thread can resume execution. The last one is the list points to kernel32 operating system settings when loading thread! UnhandledExceptionFilter function, which always shows "Application error" dialog to the user. And the abnormality processor program list, the user program itself is installed. Each node list stored on the program call stack (call stack). Windows exception handling mechanism supports nested exception handling, that is an exception occurs again in the implementation of exception handling callback function. In this case still comply with the general exception handling mechanism, the operating system RtlDispatchException function reentry process nested exception emerging. Nested exception handler is the address of the parameter values obtained DispatcherContext new exceptional frame exception occurs during execution.
Various programming languages based on the Windows exception handling mechanism, designed their own exception handling statement control structure. Microsoft extends the C language syntax, designed the try-except structured exception handling with try-finally statement. Function in a try-except all function with a try-finally formed on a forest (data structure) comprising (the enclosing) relationship. If there is a function __try statement, at the inlet and at the end, is inserted into the Compiler and EH_epilog EH_prolog codes, all in the try block of code within the protected function wrapped up. EH_prolog create a _EXCEPTION_REGISTRATION_RECORD on the call stack, as exception handling list of the new header, which contains the address of the function __except_handler4 runtime library msvcrt.dll of the Visual C ++. At the end of the function block, EH_epilog the _EXCEPTION_REGISTRATION_RECORD removed from the head of the list, restore its original header. __except statement filter expression by hanging on the list of exception handling callback MSVCR100D! __ except_handler4 to call the execution, the return value is the filter expression evaluates to. In fact, when the compiler implementation structure exception, each of the linked list data structure consists of two expansion members 5 members, i.e., a pointer is added scopetable_entries type array of structures in the higher addresses, an integer execution term represents which try block in the current point in the function, a stored entry register integer of EBP. Thereafter (lower addresses) is followed by a pointer EXCEPTION_POINTERS structure (i.e., the intrinsic GetExceptionInformation function returns the pointer value).
When an exception occurs, ntdll exception handling mechanism of the operating system RtlDispatchException function from FS:! [0] points to the list header in turn call the exception handler callback function for each node exceptional frame linked list included MSVCR100D __ except_handler4, according to this callback! the return value to determine whether an abnormality has been processed, the thread may resume execution context abnormality (exception context). __except_handler4 callback function is actually just call MSVCR100D! __ except_handler4_common function. __except_handler4_common function is the actual workhorse, is responsible for finding the try-except statement in a function where the current exception frame that can handle the exception (ie the filter expression evaluates to 1). If such a try-except block does not exist, __ except_handler4_common function returns ExceptionContinueExecution (0), continue to access the exceptional frame RtlDispatchException next node in the list. If found to handle the current try-except block abnormal, __ except_handler4_common function first calls the global expansion functions _EH4_GlobalUnwind, where the function is abnormal from the list frame header, until you can deal with the current exception of the next layer function function, do the stack expand (unwinding); then, the function can handle this exception, the most memory containing the execution point __try statement until the try-except block to handle the exception, the function call partially deployed _EH4_LocalUnwind; try again performed to handle the exception -except exception handling code block; Finally, the code continues after the other try-except. Global expansion, calling ntdll by the _EH4_GlobalUnwind! RtlUnwind, RtlUnwind list traversal visits exceptional frame, from the frame to the target frame header (none) all exception handler callback with exception code (STATUS_UNWIND i.e. 0C0000027H), the abnormality flag (EXCEPTION_UNWINDING i.e. value 2) call. The exception handler callback code and the current abnormality abnormality flag, where abnormal function of the current frame, from the execution point comprises generating the abnormality innermost __try statement begins, until the outermost function within the try block, sequentially calls try -finally cleanup purpose code. This step is actually called _EH4_LocalUnwind function to complete.
Partially deployed, implemented by _EH4_LocalUnwind function, from the innermost layer containing the execution point __try statement generation start abnormality, comprising a pressing relationship until outwardly until the try-except certain statements, calling code successively cleaning of try-finally use code.
Second, the quantization exception handling under win32
Vectored exception handling (VEH) is an extension of structured exception handling, which was introduced in Windows XP, why vectored exception to emphasize that it is under win32, because 64-bit windows does not support this feature. Understand the properties or return to say before the operating system handles the above sequence abnormality is first to the debugger, and then processed by the user program, the exception being processed value determines whether the filter expression returns in accordance with, and this vectored exception processing, exception handling is to add the code before this, its code will be executed first before the filter expression. We know that look abnormal layer by layer from the inner to the outer layer, the inner layer if the process has been completed, then the outer layer is never have a chance process, in this case we use third-party libraries to develop applications, and this not provide source code library, and the library will simply terminate the thread when an exception occurs, and we want to deal with this anomaly, but due to internal processing, the outer try simply not catch, this time you can use vectored exception It dealt with. We write exception handling code first processing and return to continue, so the library would not have the opportunity to deal with this anomaly.
You can use AddVectoredExceptionHandler () function adds a vectored exception handler, the disadvantage is that it can only be VEH, so check at run time in WinXP and later versions AddVectoredExceptionHandler () function exists.
To remove the exception handler is previously installed can be used RemoveVectoredExceptionHandler () function.
VEH Allows viewing or processing application in all the exceptions. For maintaining backward compatibility, when some part of the program takes place SEH exception system in turn call VEH processor installed, until it finds useful SEH processor.
One advantage is the ability to link VEH exception handler (chain exception handlers), so if someone is vectored exception processor, you can still capture these anomalies before you install.
When you need something like a debugger as supervisor of all exceptions, use VEH is appropriate. The problem is that you need to decide which need to handle an exception, an exception which needs to be skipped. In program's code, some exceptions may be intentionally guarded by __try {} __ except () {} construction, and handling such exceptions in VEH and not passing it to frame-based SEH handler, you may introduce bugs into application logics.
VEH is not currently used by CrashRpt. SetUnhandledExceptionFilter () is more applicable, because it is the top-level SEH processor. If there is no exception handling, top-level SEH handler is called, and you do not have to decide whether to handle the exception.