Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1963
  • Last Modified:

Exception Handling in Windows Message Loop

We have found something interesting out with an win32 C/C++ application (vc6 & vc8)and the message pump handling (in this case WM_TIMER).

A 3rd party dll could cause an exception without exception protection without the application crashing. In our case this was bad because the state of internal code became indeterminate because the DLL entry point did not have an exit point, i.e. the WM_TIMER called a function which crashed, then just called it again on the next timer.

Some sample code will follow which shows this behaviour :

>> The question is does anyone know of something definitive on why this behaviour is happening ? Under MSDN and elsewhere, we can't find any doco on message loop handling that references that it protects the function call from crashes .

To ensure that the call is "stateful" we will need to try / catch many code points within the WM_TIMER function .

Sample code :


#include "stdio.h"
#include "windows.h"
#include "resource.h"


//Timer callback function
void CALLBACK RecvTimer(HWND hwnd, UINT msg, UINT idTimer, DWORD dwTime)
{
      char *test = NULL;
      *test = 'a'; //Throw SEH exception (access violation)
}

//Initilise the timer
bool InitTimer()
{
      return SetTimer(NULL, 1199, 100, (TIMERPROC)RecvTimer);
}

void main( int argc, char** argv )
{
    // create the dialog window
    HWND hWnd = ::CreateDialog(NULL,
        MAKEINTRESOURCE(IDD_DIALOG),NULL,NULL);

    if ( hWnd!=NULL )
    {
        // show dialog
        ShowWindow(hWnd,SW_SHOW);
    }
    else
    {
        printf("Failed to create dialog\n");
        exit(1);
    }

      //Initilise the timer.
      if (!InitTimer())
      {
            printf("Failed to initilise timer\n");
            exit(1);
      }
    // message loop to process user input
    MSG msg;
    while (GetMessage(&msg, // message structure
            NULL,           // handle to window to receive the message
            NULL,           // lowest message to examine
            NULL)          // highest message to examine
           != 0 && GetMessage(&msg, NULL, NULL, NULL) != -1)
    {
 
        // Post WM_TIMER messages to the hwndTimer procedure.
 
        if (msg.message == WM_TIMER)
        {
            msg.hwnd = hWnd;
        }
 
        TranslateMessage(&msg); // translates virtual-key codes
        DispatchMessage(&msg);  // dispatches message to window
    }
}

/************************** end ************************/
0
greg_roberts
Asked:
greg_roberts
  • 2
1 Solution
 
Deepu AbrahamR & D Engineering ManagerCommented:
RecvTimer() is the callback function which user has written and is nothing to do with the message loop. What message loop will do is, it will just call the callback funtion which we have already registerd in the SetTimer function.Also modified your code to catch the exception properly.

Hope it helps!,
Best Regards,
DeepuAbrahamK
//---------------------8<---------------------------------------------8<------------------//
#include "stdio.h"
#include "windows.h"
#include "resource.h"

//Timer callback function
void CALLBACK RecvTimer(HWND hwnd, UINT msg, UINT idTimer, DWORD dwTime)
{
      try
      {
            char *test = NULL;
            *test = 'a'; //Throw SEH exception (access violation)
      }
      catch(...)
      {
            printf("Exception !!");
            PostMessage(hwnd,WM_DESTROY,0,0);
      }
}

//Initilise the timer
bool InitTimer()
{
     return SetTimer(NULL, 1199, 100, (TIMERPROC)RecvTimer);
}

void main( int argc, char** argv )
{
    // create the dialog window
    HWND hWnd = ::CreateDialog(NULL,
        MAKEINTRESOURCE(IDD_DIALOG),NULL,NULL);
      
    if ( hWnd!=NULL )
    {
        // show dialog
        ShowWindow(hWnd,SW_SHOW);
    }
    else
    {
        printf("Failed to create dialog\n");
        exit(1);
    }
      
      //Initilise the timer.
      if (!InitTimer())
      {
            printf("Failed to initilise timer\n");
            exit(1);
      }
    // message loop to process user input
    MSG msg;
    while (GetMessage(&msg, // message structure
            NULL,           // handle to window to receive the message
            NULL,           // lowest message to examine
            NULL)          // highest message to examine
            != 0 )
    {
            
        // Post WM_TIMER messages to the hwndTimer procedure.
            
        if (msg.message == WM_TIMER)
        {
            msg.hwnd = hWnd;
        }
            
            if (msg.message ==WM_DESTROY)
            {
                  // Destroy the timer.
                  KillTimer(msg.hwnd, 1199);
                  PostQuitMessage(WM_QUIT);
            }
            else
            {
                  
                  TranslateMessage(&msg); // translates virtual-key codes
                  DispatchMessage(&msg);  // dispatches message to window
            }
            
            
    }
}
//---------------------8<---------------------------------------------8<------------------//
0
 
greg_robertsAuthor Commented:
Thanks for your interest but what you suggest is what we know.

>> We are after definitive information on the why / how this DispatchMessage protection exists, as on paper there is no reference to it in the MSDN documentation .

Please refer to the >> question above.

PLEASE NOTE TO OTHER READERS, THE QUESTION HAS NOT BEEN ANSWERED
0
 
NickGeorghiouCommented:
Hi,

This article may not give you a definitive answer. But it does point out that VC++ exception handling can in fact default to the application continuing in an inconsistant state. One quote from this article which sounds relevant is:

 "For example, if a program is required to use a third-party library, and the library has bugs of this kind, and the developers have no access to the library source code, then..."  
"   ... it may be considered better for the program to limp along rather than die."

It also points out that compiler optimisation (if used) will may affect exception handling.

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

Hope this helps,
Regds,
Nick
0
 
greg_robertsAuthor Commented:

Thanks Nick

This article is probably the best on the Web.

It is a great shame that Microsoft don't have this whole area spelled out as it can have a profound affect on your application.

Personally we would prefer that the handling could be turned on/off so we get a clean crash, especially during testing and beta use.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now