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 [lower-alpha 1] function in msvcrt.dll, [lower-alpha 2] 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 [lower-alpha 3] 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. [lower-alpha 4] Then the list is traversed once more giving handlers a chance to clean up any resources used. Finally, the execution returns to kernel mode [lower-alpha 5] 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

In computing and computer programming, exception handling is the process of responding to the occurrence of exceptions – anomalous or exceptional conditions requiring special processing – during the execution of a program. In general, an exception breaks the normal flow of execution and executes a pre-registered exception handler; the details of how this is done depend on whether it is a hardware or software exception and how the software exception is implemented. Exception handling, if provided, is facilitated by specialized programming language constructs, hardware mechanisms like interrupts, or operating system (OS) inter-process communication (IPC) facilities like signals. Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted.

The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. The name Windows API collectively refers to several different platform implementations that are often referred to by their own names ; see the versions section. Almost all Windows programs interact with the Windows API. On the Windows NT line of operating systems, a small number use the Native API.

System call Way for programs to access kernel services

In computing, a system call is the programmatic way in which a computer program requests a service from the kernel of the operating system on which it is executed. This may include hardware-related services, creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

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.

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, and is a userland that originated in earlier versions of Windows and included up to Windows 10.

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

Architecture of Windows NT Overview of the architecture of the Microsoft Windows NT line of operating systems

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, they use 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.

As the next version of Windows NT after Windows 2000, as well as the successor to Windows Me, Windows XP introduced many new features but it also removed some others.

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 Windows NT booting process is the process by which Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize. In Windows Vista and later, this process has changed significantly; see Windows NT 6 startup process for information about what has changed.

The Native API is a lightweight application programming interface (API) used by Windows NT 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.

In computing ntoskrnl.exe, also known as kernel image, provides the kernel and executive layers of the Microsoft Windows NT kernel space, and is responsible for various system services such as hardware abstraction, process and memory management, thus making it a fundamental part of the system. It contains the cache manager, the executive, the kernel, the security reference monitor, the memory manager, scheduler (Dispatcher), and the text and some coding for the Stop Error Screen.

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 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.

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 and is included in Windows NT 3.1 and later. Because most of the Win32 subsystem operations have been moved to kernel mode drivers in Windows NT 4 and later, CSRSS is mainly responsible for Win32 console handling and GUI shutdown. It is critical to system operation; therefore, terminating this process will result in system failure. Under normal circumstances, CSRSS cannot be terminated with the taskkill command or with Windows Task Manager, although it is possible in Windows Vista if the Task Manager is run in Administrator mode. On Windows 7 and later, Task Manager will inform the user that terminating the process may result in system failure, and prompt if they want to continue. In Windows NT 4.0 however, terminating CSRSS without the Session Manager Subsystem (SMSS) watching will not crash the system. However in Windows XP, terminating CSRSS without SMSS watching will crash the system due to the critical bit being set in RAM for csrss.exe.

The booting process of Microsoft Windows varies between different releases.

Blue screen of death Error screen displayed after a fatal system error on a computer running Microsoft Windows or ReactOS

A blue screen of death (BSoD), officially known as a stop error or blue screen error, is an error screen that the Windows operating system displays in the event of a fatal system error. It indicates a system crash, in which the operating system has reached a critical condition where it can no longer operate safely, e.g., hardware failure or an unexpected termination of a crucial process.

Microsoft POSIX subsystem is one of four subsystems shipped with the first versions of Windows NT, the other three being the Win32 subsystem which provided the primary API for Windows NT, plus the OS/2 and security subsystems.

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—including Windows XP Professional x64 Edition, IA-64 and x64 versions of Windows Server 2003, as well as x64 versions of Windows Vista, Windows Server 2008, Windows 7, Windows 8, Windows Server 2012, Windows 8.1, Windows 10, Windows Server 2016, Windows Server 2019, and Windows 11, as well as ARM64 versions of Windows 10, Windows 11 and Windows Server 2022. In Windows Server Server Core, it is an optional component. It is not available in Windows Nano Server variants. 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.
  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.