#231 TWindow::EvEndSession crashes at system shutdown

[Vidar Hasfjord]

On some Windows editions, an OWLNext application will crash at system shutdown. The cause of the crash is the unreliable use of C++ exceptions across the Windows API boundary. In particular, TXEndSession is thrown in TWindow::EvEndSession.

This issue was reported by Tores in the Open Discussion forum. See topic "OWL application crashes on system shutdown on Windows 8 64-bit" [discussion:6fc35a74].

While [bugs:#230] "Unhandled exceptions escape event handlers" deals with the general issue, the purpose of this ticket is to find a binary compatible fix that circumvents the problem and can be back-ported to 6.30 and 6.32.

[Vidar Hasfjord]

• status: closed --> open
• milestone: 6.32.5 --> 6.32.7

I have reopened this issue since the proposed workaround and committed fix is not reliable. In particular it only works when the main message loop is processing messages. It does not work for modal dialogs, property sheets and other custom code that uses private message loops. In these cases, the special code for handling WM_ENDSESSION in the application message loop never gets a chance to run.

My immediate idea for a more robust solution is to call PostQuitMessage in TWindow::EvEndSession to break all message loops, and to revert the changes to the main message loop (i.e. remove the special handling of WM_ENDSESSION there).

Perhaps it also would be a good idea to introduce and set a new flag, so that the application can detect when it is shut down by WM_ENDSESSION and throw TXEndSession for backwards compatibility.

[Vidar Hasfjord]

The proposed workaround has now been implemented on the 6.32 branch [r1980].

For the 6.34 branch and the trunk, I propose that the code is reverted to use exception transport, i.e. that TWindow::EvEndSession is reverted to again throw TXEndSession as it originally did, and that the exception transport facilities are extended to properly transport it to the main message loop. This should already be supported on the trunk, as it uses the general std::exception_ptr to transport any exception. The 6.34 branch will have to add special handling.