wRTOS supports ISO-standard C++ exception handling (catch/throw), Windows Structured Exception Handling (SEH) API, and C frame-based exception handling (try/except/finally), all as defined by the Windows Platform SDK.
In this topic:
- C++ Support
- Structured Exception Handling
- Differences Between Windows and RTSS Exception Handling
- General User Notes for Exception Handling
Note: For more information on the APIs referenced in this chapter, see the wRTOS SDK Help.
C++ Support
wRTOS supports the Visual C++ language, with some restrictions discussed in the note below. RTSS supports all C++ features usable in a Windows C++ wRTOS API console application, including new/delete operators and exception handling.
Note: wRTOS does not claim support for all C++ libraries. Support is limited to libraries
that depend upon the set of Windows functions supported in the RTSS environment.
Structured Exception Handling
RTSS supports Microsoft Structured Exception Handling and ISO-standard C++ exception handling, as described by the Windows Platform SDK, including:
- Windows 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-throw-catch.
- Handling for the following hardware exceptions in RTSS:
EXCEPTION_BREAKPOINT
EXCEPTION_SINGLE_STEP
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_ZEROEXCEPTION_DOUBLE_FAULT
Using Structured Exception Handling
To use Structured Exception Handling (SEH) in an RTSS application, the application must be linked with the Microsoft C Runtime libraries that contain run-time support for the SEH frame-based exception handlers.
Differences Between Windows and RTSS Exception Handling
The RTSS implementation follows Windows SEH semantics where possible. This section describes the differences.
UnhandledExceptionFilter
Windows 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 Windows, 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, depending on how the Subsystem is configured in the wRTOS Settings) 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 Windows behavior by using per-thread unhandled exception filter functions.
Nested exceptions and collided unwinds
RTSS follows Windows 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. Windows repeatedly re-asserts those; but repeated re-assertion of exceptions consumes stack space. A stack fault in RTSS causes a system shutdown (the "Blue 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 x86/x84 interrupt and exception codes (refer to Interrupt and Exception Handling in Intel® Developer’s Manual), thus differing from Windows exception codes caused by similar errors. For example, an errant Windows application gets an EXCEPTION_ACCESS_VIOLATION as defined by Windows, an RTSS application gets EXCEPTION_PAGE_FAULT as described in the wRTOS Reference Guide. A Windows EXCEPTION_ILLEGAL_INSTRUCTION is equivalent to the RTSS EXCEPTION_INVALID_OPCODE.
- Reads/writes of address 0 — Windows 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).
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 fails, 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 Windows is recommended, to avoid stack overflows in RTSS.
- To modify the behavior of how wRTOS treats exceptions, use the Settings tool.
- If wRTOS Structured Exception Handling (SEH) wants to access and modify floating point or processor extended registers within the CONTEXT record, the SEH filter and except body should access and modify the FltSave or XState field of CONTEXT. The FltSave field contains the processor legacy FPU/SSE state registers with the FXSAVE format. The XState field contains the processor AVX/AVX512/AMX/MPX, etc. extended state registers with the XSAVE format (starting from XSAVE Header), which is available in winnt.h.
