Microsoft-specific exception handling mechanisms

Last updated

The Microsoft Windows family of operating systems employ some specific exception handling mechanisms.

Contents

Structured Exception Handling

Microsoft Structured Exception Handling is the native exception handling mechanism for Windows and a forerunner technology to Vectored Exception Handling (VEH). [1] It features the finally mechanism not present in standard C++ exceptions (but present in most imperative languages introduced later). SEH is set up and handled separately for each thread of execution.

Usage

Microsoft supports SEH as a programming technique at the compiler level only. MS Visual C++ compiler features three non-standard keywords: __try, __except and __finally — for this purpose. Other exception handling aspects are backed by a number of Win32 API functions, [2] for example, RaiseException to raise SEH exceptions manually.

Implementation

IA-32

Each thread of execution in Windows IA-32 edition or the WoW64 emulation layer for the x86-64 version has a link to an undocumented _EXCEPTION_REGISTRATION_RECORD list at the start of its Thread Information Block. The __try statement essentially calls a compiler-defined EH_prolog function. That function allocates an _EXCEPTION_REGISTRATION_RECORD on the stack pointing to the __except_handler3 [a] function in msvcrt.dll, [b] then adds the record to the list's head. At the end of the __try block a compiler-defined EH_epilog function is called that does the reverse operation. Either of these compiler-defined routines can be inline. All the programmer-defined __except and __finally blocks are called from within __except_handler3. If the programmer-defined blocks are present, the _EXCEPTION_REGISTRATION_RECORD created by EH_prolog is extended with a few additional fields used by __except_handler3. [3]

In the case of an exception in user mode code, the operating system [c] parses the thread's _EXCEPTION_REGISTRATION_RECORD list and calls each exception handler in sequence until a handler signals it has handled the exception (by return value) or the list is exhausted. The last one in the list is always the kernel32!UnhandledExceptionFilter which displays the General protection fault error message. [d] Then the list is traversed once more giving handlers a chance to clean up any resources used. Finally, the execution returns to kernel mode [e] where the process is either resumed or terminated.

The patent on this mode of SEH, US5628016, expired in 2014.

x86-64

SEH on 64-bit Windows does not involve a runtime exception handler list; instead, it uses a stack unwinding table (UNWIND_INFO) interpreted by the system when an exception occurs. [4] [5] This means that the compiler does not have to generate extra code to manually perform stack unwinding and to call exception handlers appropriately. It merely has to emit information in the form of unwinding tables about the stack frame layout and specified exception handlers.

Support

GCC 4.8+ from Mingw-w64 supports using 64-bit SEH for C++ exceptions. LLVM clang supports __try on both x86 and x64. [6]

Vectored Exception Handling

Vectored Exception Handling was introduced in Windows XP. [7] Vectored Exception Handling is made available to Windows programmers using languages such as C++ and Visual Basic. VEH does not replace Structured Exception Handling (SEH); rather, VEH and SEH coexist, with VEH handlers having priority over SEH handlers. [1] [7] Compared with SEH, VEH works more like kernel-delivered Unix signals. [8]

Notes

  1. ↑ The name varies in different versions of VC runtime
  2. ↑ ntdll.dll and kernel32.dll, as well as other programs linked statically with VC runtime, have this function compiled-in instead
  3. ↑ More specifically, ntdll!RtlDispatchException system routine called from ntdll!KiUserExceptionDispatcher which is in turn called from the nt!KiDispatchException kernel function. (See Ken Johnson (November 16, 2007). "A catalog of NTDLL kernel mode to user mode callbacks, part 2: KiUserExceptionDispatcher". for details)
  4. ↑ The message can be silenced by altering the process's error mode; the default last handler can be replaced with SetUnhandledExceptionFilter API
  5. ↑ ntdll!KiUserExceptionDispatcher calls either nt!ZwContinue or nt!ZwRaiseException

Related Research Articles

<span class="mw-page-title-main">Windows API</span> Microsofts core set of application programming interfaces on Windows

The Windows API, informally WinAPI, is the foundational application programming interface (API) that allows a computer program to access the features of the Microsoft Windows operating system in which the program is running. Programs access API functionality via dynamic-link library (DLL) technology.

Win32s is a 32-bit application runtime environment for the Microsoft Windows 3.1 and 3.11 operating systems. It allowed some 32-bit applications to run on the 16-bit operating system using call thunks. A beta version of Win32s was available in October 1992. Version 1.10 was released in July 1993 simultaneously with Windows NT 3.1.

In computing, the Windows Driver Model (WDM) – also known at one point as the Win32 Driver Model – is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1, as well as the Windows NT Driver Model.

<span class="mw-page-title-main">Windows 9x</span> Discontinued series of Microsoft Windows operating systems

Windows 9x is a generic term referring to a line of discontinued Microsoft Windows operating systems from 1995 to 2000, which were based on the Windows 95 kernel and its underlying foundation of MS-DOS, both of which were updated in subsequent versions. The first version in the 9x series was Windows 95, which was succeeded by Windows 98 and then Windows Me, which was the third and last version of Windows on the 9x line, until the series was superseded by Windows XP.

Virtual DOS machines (VDM) refer to a technology that allows running 16-bit/32-bit DOS and 16-bit Windows programs when there is already another operating system running and controlling the hardware.

The Thread Information Block (TIB) or Thread Environment Block (TEB) is a data structure in Win32 on x86 that stores information about the currently running thread. It descended from, and is backward-compatible on 32-bit systems with, a similar structure in OS/2.

<span class="mw-page-title-main">Phar Lap Software</span> Software company

Phar Lap Software, Inc., was a software company specializing in software development tools for DOS operating systems. The company was named after the champion New Zealand racehorse Phar Lap. They were most noted for their software allowing developers to access memory beyond the 640 KiB limit of DOS and were an author of the VCPI standard.

<span class="mw-page-title-main">Architecture of Windows NT</span> Structure of the operating system

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, it uses packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.

In computer programming, the term hooking covers a range of techniques used to alter or augment the behaviour of an operating system, of applications, or of other software components by intercepting function calls or messages or events passed between software components. Code that handles such intercepted function calls, events or messages is called a hook.

In computer security, executable-space protection marks memory regions as non-executable, such that an attempt to execute machine code in these regions will cause an exception. It makes use of hardware features such as the NX bit, or in some cases software emulation of those features. However, technologies that emulate or supply an NX bit will usually impose a measurable overhead while using a hardware-supplied NX bit imposes no measurable overhead.

The Native API is a lightweight application programming interface (API) used by Windows NT's kernel and user mode applications. This API is used in the early stages of Windows NT startup process, when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API, the API based on which most of the Windows components are created.

ntoskrnl.exe, also known as the kernel image, contains the kernel and executive layers of the Microsoft Windows NT kernel, and is responsible for hardware abstraction, process handling, and memory management. In addition to the kernel and executive layers, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death.

In computer programming, DLL injection is a technique used for running code within the address space of another process by forcing it to load a dynamic-link library. DLL injection is often used by external programs to influence the behavior of another program in a way its authors did not anticipate or intend. For example, the injected code could hook system function calls, or read the contents of password textboxes, which cannot be done the usual way. A program used to inject arbitrary code into arbitrary processes is called a DLL injector.

The Session Manager Subsystem, or smss.exe, is a component of the Microsoft Windows NT family of operating systems, starting in Windows NT 3.1. It is executed during the startup process of those operating systems.

The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.

The Client/Server Runtime Subsystem, or csrss.exe, is a component of the Windows NT family of operating systems that provides the user mode side of the Win32 subsystem. In modern versions of Windows, it is primarily involved with process and thread management, console window handling, side-by-side assembly loading and the shutdown process. Historically, it had also been responsible for window management and graphics rendering, however, these operations have been moved to kernel mode starting with Windows NT 4.0 to improve performance.

windows.h is a source code header file that Microsoft provides for the development of programs that access the Windows API (WinAPI) via C language syntax. It declares the WinAPI functions, associated data types and common macros.

Windows NT is a proprietary graphical operating system produced by Microsoft as part of its Windows product line, the first version of which, Windows NT 3.1, was released on July 27, 1993. Originally made for the workstation, office, and server markets, the Windows NT line was made available to consumers with the release of Windows XP in 2001. The underlying technology of Windows NT continues to exist to this day with incremental changes and improvements, with the latest version of Windows based on Windows NT being Windows 11 in 2021.

In computing on Microsoft platforms, WoW64 is a subsystem of the Windows operating system capable of running 32-bit applications on 64-bit Windows. It is included in all 64-bit versions of Windows, except in Windows Server Server Core where it is an optional component, and Windows Nano Server where it is not included. WoW64 aims to take care of many of the differences between 32-bit Windows and 64-bit Windows, particularly involving structural changes to Windows itself.

In computing the Process Environment Block is a data structure in the Windows NT operating system family. It is an opaque data structure that is used by the operating system internally, most of whose fields are not intended for use by anything other than the operating system. Microsoft notes, in its MSDN Library documentation — which documents only a few of the fields — that the structure "may be altered in future versions of Windows". The PEB contains data structures that apply across a whole process, including global context, startup parameters, data structures for the program image loader, the program image base address, and synchronization objects used to provide mutual exclusion for process-wide data structures.

References

  1. 1 2 "Vectored Exception Handling in Windows Server 2003 (Through Internet Archive)". Archived from the original on 2008-01-18.
  2. ↑ Microsoft Corp. (2009-11-12). "Structured Exception Handling Functions". MSDN Library. Retrieved 2022-07-23.
  3. ↑ Peter Kleissner (February 14, 2009). "Windows Exception Handling - Peter Kleissner". Archived from the original on October 14, 2013. Retrieved 2009-11-21., Compiler based Structured Exception Handling section
  4. ↑ "Exceptional Behavior - x64 Structured Exception Handling". The NT Insider.
  5. ↑ "x64 exception handling". VC++ 2019 documentation. 8 February 2022.
  6. ↑ "MSVC compatibility". Clang 11 documentation.
  7. 1 2 "Under the Hood: New Vectored Exception Handling in Windows XP". Archived from the original on 2008-09-15.
  8. ↑ "Windows Server 2003 Discover Improved System Info, New Kernel, Debugging, Security, and UI APIs". Archived from the original on 2008-05-05.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.