OWL application crashes on system shutdown on windows8 64 bits

[Anonymous]

Description:

Hi,
This simple OWL application crashes at system shutdown on windows 8. While debugging I learned that TxEndSession exception which is thrown by the OWL framework when the OWL application receives WM_ENDESSION is unhandled. The application was built for win32 and was run on windows8 win64. This does not happen on Win7 64bits - meaning that at system shutdown, the application closes without crashing.

Any help with this is very much appreciated.
Thanks!

MyOWLApp.h

:::C++
#pragma once
#include <owl/applicat.h>

class MyOWLApp :
    public TApplication
{
public:
    MyOWLApp(void);
    virtual ~MyOWLApp(void);

public:
    void InitMainWindow();
};

MyOWLApp.cpp

:::C++
#include "MyOWLApp.h"
#include <owl/framewin.h>

MyOWLApp::MyOWLApp(void)
{
}

MyOWLApp::~MyOWLApp(void)
{
}

void MyOWLApp::InitMainWindow()
{
    SetMainWindow(new TFrameWindow(0, _T("My OWL")));
}

Main.cpp

:::C++
#include "MyOWLApp.h"

int
OwlMain(int argc, _TCHAR* argv[])
{
    MyOWLApp app;

    return app.Run();
}

[Anonymous]

I would add that the application is built with Visual Studio 2005, uses OWL (I think 2.0, i'll need to check, anyway it uses an older version of OWL).
Also, the same application doesn't crash on windows8 win32 either. It happens only on windows8 win64.

[Sebastian Ledesma]

Hi:

I can add a few of suggestions.

1. Create an account at sourceforge. It's free. This will allow to publish in the forums without being marked as suspicious post (and will require the administrator to review the post).
2. If you are using OWL2 I suggest you to upgrade to at least BC5 + OWL5. You can get the BC5.02 as used software in ebay and other sites. The switch from OWL2 to OWL5 is not difficult.

After that, the recommendation is to move to OWLNext 6.30.x (6.30.12 is the current version).

If you are already using Visual Studio as IDE/Compiler then you should be already using OWLNext. You can check the OWL/OWLNext version <owl version.h="">.</owl>

You can also do the switch from OWL2 to OWLNext, I prefer a two step approach.

Sebas.

Moderator: Formatted paragraphs.

[Tores]

Hi Sebastian,

Thanks for suggestions.

The version in my installed OWL is (from "include/owl/version.h"):

#define _OWL_VERSION(v) v(6,30,11,1111)

I think it is pretty recent.

Indeed I'm using Visual Studio 2005 IDE/compiler and with that, I get into the described situation.

I'm not sure what it could be: an OWL issue or a Windows 8 issue... but it manifests itself only on 64-bit (TXEndSession exception is unhandled — though OWL::WinMain which calls OWLMain has a catch (TXEndSession&) in it, but it seems that the exception handler for TxEndSession is not found on Windows 8 64-bit).

Thanks!

Moderator: Formatted paragraphs.

[Anonymous]

As a note (but it is probably already understood) - I compiled the application for Win32 and ran it on windows 8 win64.

[Tores]

Is it safe to comment the code inside the default window handler for WM_ENDSESSION provided by the framework like this?

:::C++
//
// Windows is shutting down.
//!TH Throw an exception that is to be caught only by Owl's WinMain,
//!TH which shuts down the entire application.
//
void
TWindow::EvEndSession(bool endSession, bool)
{
  // On Windows 8 x64 this causes a runtime error at system shutdown/reset/log off
  //if (endSession)
  //  throw TXEndSession();
  //else
    DefaultProcessing();
}

Or better I should take out the entire code for this handler from TWindow ?

Overwriting it is not an options because we derive alot from TWindow and also use alot of TWindow derived classes provided by the framework.

Thanks!

[Vidar Hasfjord]

Hi Tores,

though OWL::WinMain which calls OWLMain has a catch (TXEndSession&) in it

Right. OWLNext handles the TXEndSession exception in _tmain and _tWinMain, which are the wrappers around OwlMain (see "main.cpp" and "winmain.cpp", respectively). Both handlers return 0. It would be interesting to know if these handlers are executed at all in your case. Have you been able to test this? E.g. add a log statement to a file?

[Anonymous]

Hi Vidar,

The exception handler in _tWinMain is not executed. This is why the unhandled exception is reported (this is only on 64 bits).

Anyway, I posted a question on Windows dev forum:
http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/90ebf324-6f48-4805-abb6-7d9530d926a0/

and you can find a reply that talks about a known issue. Follow this link:

http://support.microsoft.com/kb/976038/en (thanks to William).

Maybe it is helpful and you will consider the info there if you plan to fix this.
In the mean time I have commented the "throw TXEndSession" statement in window.cpp in owlcore (I'm not sure about the side effects, but it seems to work.)

[Tores]

Sorry, I have posted again as Anonymous (https://sourceforge.net/p/owlnext/discussion/97175/thread/6fc35a74/#c6f1/1f22).

Please let me know whether and when the fix will be available.

Tores

[Ognyan Chernokozhev]

I can confirm that the same problem happens with both 32- and 64-bit builds of OWLMaker (VC2010+OWLNext6.33) during 64-bit Windows 8 shutdown. I will try to find a solution.

Jogy

[Ognyan Chernokozhev]

More findings: the problem can happen on any exception throw from a kernel callback, for example if you throw TXEndSession from an EvWinIniChange handler, again the app will crash without giving you a chance to catch and handle the exception.

The proposed solution with calling SetProcessUserModeExceptionPolicy() cannot be used, as this undocumented function is not exported from the kernel32.dll of Windows 8, nor I can find any other system dll that exports it.

I can't think of any solution for this problem except for not throwing TXEndSession() under Windows 8 and maybe using another way to force program exit.

Jogy

[Vidar Hasfjord]

It makes sense. Since the Windows API is a C API, it does not define the behaviour for unhandled C++ exceptions in a WindowProc. As far as I understand it, the remarks about exceptions in the WindowProc documentation only talks about Structured Exceptions defined by Windows.

I am surprised that OWL/OWLNext doesn't seem to consider this issue at all.

It seems we need an exception firewall in ReceiveMessage (since it forwards to an overridable virtual function, WindowProc, any handling further down the chain can be circumvented), and some mechanism for transporting unhandled exceptions to the TApplication message loop.

For TXEndSession in particular, I guess we can replace it by a flag. I.e. instead of throwing the TXEndSession exception, set a flag, and then check the flag in the message loop. Perhaps the existing flag BreakMessageLoop is already sufficient for this purpose?

[Vidar Hasfjord]

By the way, the linked forum post and SetProcessUserModeExceptionPolicy article above only concern Windows Structured Exception Handling (SEH), not C++ exceptions. I doubt we need to deal with SEH. In any case, SEH is irrelevant to the TXEndSession issue.

Anyway, for your information, here is a nice article talking about the interaction between C++ exceptions and SEH, and some particular issues with the Visual C++ compiler (esp. pre-2005):

http://thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/

And this article on MSDN talks about SEH and C++ exception handling:

http://msdn.microsoft.com/en-us/library/5skw957f.aspx

[Vidar Hasfjord]

I remembered vaguely that the obsolete 16-bit OWL code did have some special exception handling. So I had a look at the original OWL 5 source code, and it actually implements an exception firewall in ReceiveMessage, but only for Win16. The 16-bit code makes use of TApplication::SuspendThrow and ResumeThrow to transport the exception to the message loop.

:::C++
//
// First member function that receives messages from windows thru the
// thunk & then StdWndProc. Deals with exception suspension for non-NT
// environments.
//
TResult
TWindow::ReceiveMessage(uint msg, TParam1 param1, TParam2 param2)
{
  // If it's a "GetWindowPtr" message, then return pointer to this window
  //
  if (msg == ::GetWindowPtrMsgId && 
    (!param2 || param2 == TParam2(Application)))
    return TResult(this);

#if defined(BI_PLAT_WIN32)
  if (TSystem::SupportsExceptions())
    return HandleMessage(msg, param1, param2);
#endif
#if defined(BI_PLAT_WIN16) || defined(WIN32S_SUPPORT)
  TRY {
    return HandleMessage(msg, param1, param2);
  }
  CATCH( (TXOwl& x) {
    GetApplication()->SuspendThrow(x);
  })
  CATCH( (xalloc& x) {
    GetApplication()->SuspendThrow(x);
  })
  CATCH( (xmsg& x) {
    GetApplication()->SuspendThrow(x);
  })
#if !defined(BI_NO_NEW_CASTS)
  CATCH( (Bad_cast& x) {
    GetApplication()->SuspendThrow(TApplication::xsBadCast);
  })
  CATCH( (Bad_typeid& x) {
    GetApplication()->SuspendThrow(TApplication::xsBadTypeid);
  })
#endif
  CATCH( (...) {
    GetApplication()->SuspendThrow(TApplication::xsUnknown);
  })
  ENDCATCH
#endif

  // When exceptions are disabled CATCH is defined as empty, so the only code
  // is the TRY block, making this return unreachable
  //
# pragma warn -rch
  return msg == WM_CREATE ? -1 : 0;  // default when exception caught
# pragma warn .rch
}

For Win32 (except for WIN32S_SUPPORT), the code relies on system support. The code comment for TSystem::SupportsExceptions says:

:::C++
//
// Return true if the system has exception suport built in and the runtime
// library uses it for stack unwinding support.
//

So, in the 32-bit case, there is obviously some non-standard hocus pocus involved, where it is assumed that the implementation of C++ exceptions in the compiler and runtime interacts with SEH in a well-defined manner, so that C++ exceptions are magically transported across the Windows API boundary and rethrown in the message loop. Can anyone point me to documentation on how this works?

Anyhow, we now see that this is unreliable.

The advice I find about C++ exceptions and Windows callbacks on the web (e.g. this, this, this and this) is to not let C++ exceptions escape, and to treat C++ exceptions and SEH separately.

Hence I propose that we reinstate the exception firewall used for the 16-bit code.

[Vidar Hasfjord]

I've now registered a bug ticket for the general issue with unhandled exceptions in event handlers [bugs:#230].

[Vidar Hasfjord]

I have also added a more specific ticket [bugs:#231] for the shutdown issue.

[Vidar Hasfjord]

A workaround and a binary compatible patch for 6.32 have now been added to the shutdown issue [bugs:#231].

[Tores]

Thank you for your efforts in addressing this issue.

I understand that the fix in the patch is not binary compatible, reason for which you've made another fix that works around this by not throwing the exception.

Can the patch(es) (bug 230 and/or 231) be applied over 6,30,11,1111 (the version I'm using currently)?
When will the complete fix be availble in an official release ?

[Vidar Hasfjord]

Hi Tores, if you want to create your local branch of OWLNext, you can manually apply either patch as you wish. Otherwise, I recommend upgrading to OWLNext 6.32.5 which has the TXEndSession patch applied [bugs:#231]. I will recommend to Jogy to apply this patch to 6.30 as well, if there is a decision to release another 6.30 update. The general issue is fixed on the trunk for the next major release (milestone 6.40), but no date has been set, and it may take a while.

PS. If you stay on 6.30, I recommend upgrading to the most recent update, 6.30.12. It fixes a number of issues.

[Sebastian Ledesma]

I support Vidar opinion. You should move to 6.30.12 ASAP.
Then you can aply the patch manually.
We are working on the develpment of 6.33 / 6.40 and also mantaining 6.32, so there is no much time to support older versions.

Sebas