C++ and Structured Exception Handling

RTX supports Microsoft C++ exceptions (catch/throw), Win32 Structured Exception Handling (SEH) API, and C frame-based exception handling (try/except/finally), all as defined by the Win32 Platform SDK.

This topic discusses:

C++ Support
Structured Exception Handling

C++ Support

RTX supports the Visual C++ language, with some restrictions discussed in the note below. RTSS should support any C++ features usable in a Win32 C++ RTX API console application, including new/delete operators and exception handling.

NOTE: RTX does not claim support for all C++ libraries. Support is limited to libraries that depend upon the set of Win32 functions supported in the RTSS environment. See the Matrix of C++ Standard Template Library Calls for more information.

Structured Exception Handling

RTSS supports Structured Exception Handling and C++ exceptions, as described by the Win32 Platform SDK, including:

Win32 Structured Exception Handling calls, which include RaiseException, SetUnhandledExceptionHandler, UnhandledExceptionFilter, AbnormalTermination, GetExceptionCode, GetExceptionInformation
Frame-based exception handlers: try-except and try-finally.
C++ exception handling: try-catch.
Handling for the following software exceptions in RTSS:

EXCEPTION_DATATYPE_MISALIGNMENT
EXCEPTION_BREAKPOINT
EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLT_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERFLOW
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_INT_DIVIDE_BY_ZERO

Using Structured Exception Handling

To use Stuctured Exception Handling (SEH) in an RTSS application, the application must be linked with one of the provided RTX C Runtime libraries which contain run-time support for the SEH frame-based exception handlers, or with static-linkage run-time support C++ libraries.

Differences Between Win32 and RTSS Exception Handling

The RTSS implementation follows Win32 SEH semantics where possible. This section describes the differences.

UnhandledExceptionFilter

Win32 UnhandledExceptionFilter semantics provide the option to disable the exception-related dialog box pop-up via SetErrorMode with the SEM_NOGPFAULTERRORBOX flag. On an exception, RTSS always displays a pop-up saying that the application has been frozen or unloaded.

Exception caused by a thread

When a thread of a multithreaded application causes an exception in Win32, the system displays a dialog box. Until the user responds to the box, other threads of the application continue running. Once the user has responded, all threads of the application terminate.

RTSS acts differently; it freezes (or unloads, if so configured) all threads of a process whenever any of them gets an exception, and produces an informational pop-up. This behavior is safer and more intuitive in the RTSS context. You can, however, emulate the Win32 behavior by using per-thread unhandled exception filter functions.

Nested exceptions and collided unwinds

RTSS follows Win32 rules for nested exceptions and "collided" unwinds, with a few minor differences:

Non-continuable exceptions — Non-continuable exceptions caused by the program directly or by exception handling run-time itself. Win32 repeatedly re-asserts those; but repeated re-assertion of exceptions consumes stack space. A stack fault in RTSS causes a system shutdown (the "green screen"), so for robustness, RTSS terminates a process that has generated a non-continuable exception.
Hardware exceptions — RTSS exception codes for hardware exceptions are tied to Pentium interrupt codes, thus differing from Win32 exception codes caused by similar errors. For example, an errant Win32 application gets an EXCEPTION_ACCESS_VIOLATION as defined by Win32, an RTSS application gets EXCEPTION_PAGE_FAULT as described in the RTX Reference Guide. A Win32 EXCEPTION_ILLEGAL_INSTRUCTION is equivalent to the RTSS EXCEPTION_INVALID_OPCODE.
Reads/writes of address 0 — Win32 explicitly guarantees that the first 64K of a user process's address space is unmapped, so any access of that area causes an exception. However, Windows occasionally makes this area valid for kernel processes and device drivers (and, therefore, for RTSS). This means that a write to/read from address 0 from an RTSS process may occasionally succeed, rather than cause an exception.

Debugging

For debugging options, see the Debug tab in the RTX Properties dialog box.

General User Notes for Exception Handling

Exception handling is a powerful mechanism with often subtle semantics. It is quite easy to write code that causes infinite re-assertion of an exception. For example, if a filter expression always faults, or always dismisses a hardware exception which gets re-executed, the process continues generating exceptions until it overflows the stack. Miscasting the handler argument to SetUnhandledExceptionFilter may be equally fatal.
Because stack faults in RTSS cause system shutdown, you must be careful when writing exception handlers. Testing your application in Win32 is recommended, to avoid stack overflows in RTSS.
To modify the behavior of a given type of exception, open the RTX Properties control panel, and click the Exception tab.
If RTSS Structured Exception Handling (SEH) wants to access and modify floating point registers within the CONTEXT record, the SEH filter and except body should access and modify the ExtendedRegisters field of CONTEXT, not the FloatSave field of CONTEXT. The format of ExtendedRegisters is of the XSAVE_FORMAT, which is available in winnt.h.

| |