Home/ Questions/Q 7709979
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T00:59:51+00:00

When a command is invoked via a keyboard shortcut in an MFC application under

  • 0

When a command is invoked via a keyboard shortcut in an MFC application under Windows 7, the application won’t crash even if some illegal operation such as divison by zero or an access violation occurs during the execution of the command handler. How ever The same command invoked via the menu will crash as expected.

This behaviour occurs under Windows 7 but not under Windows XP (I have no Vista to check). It doesn’t matter if the application has been compiled with Visual Studio 6 or with Visual Studio 2010 and if MFC is linked statically or not and if it’s the release or the debug build.

This is obviously a major problem, because in case of an access violation or some other problem, the command stops prematurely, potentially leaving data in an undefined state and the application just continues as if nothing had happened. Every MFC application in the world is potentially concerned by this problem.

The problem can be circumvented by implementing a special stub command handler for every keyboard shortcut. These stub commands then just put the WM_COMMAND back into the message via the PostMessage function.

The complete Visual Studio 6 and 2010 projects of a very simple stub application that demonstrates the problem and the solution can be found here:

http://www.epsitec.ch/download/mfccrash/mfccrash.zip

So the the actuel question is: does anybody know what’s going on ? And can anyone suggest a more elegant sulution that the one I have found ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is actually a KB976038 issue. The reason why only keyboard shortcut invoked commands are concerned is because MFC calls them via the ::TranslateAccelerator(m_hWnd, hAccel, pMsg) function. This function goes into kernel mode at some time (see stack dumps below) and then goes back into user mode and there lies the problem.

    The idea of implementing a special stub command handler for every keyboard shortcut and then putting the WM_COMMAND back into the message queue, as I mentioned in the question, is definitely not good.

    To cure the problem properly I reimplemented the OnCommand function in the CMainFrame class as this:

    BOOL CMainFrame::OnCommand(WPARAM wParam, LPARAM lParam)
{
   __try
  {    
    if (LOWORD(wParam) != ID_PAGEUP && LOWORD(wParam) != ID_PAGEDOWN)
      GetApp()->DestroyIntellisenseDlg() ;

    return CMDIFrameWnd::OnCommand(wParam, lParam) ;

  }
  __except(RecordExceptionInfo(GetExceptionInformation(), ""))
}

    Now every time a crash occurs in one of the commands, it will be catched by the RecordExceptionInfo function. For implementing the RecordExceptionInfo function, have a look at Hans Dietrich’s excellent article on Codeproject.

    Stack dumps

    Stack dump for command invoked via menu: We don’t go into kernel mode before arriving in the OnAppAbout function:

    testcrash1.exe!Ctestcrash1App::OnAppAbout()  Line 151   C++
testcrash1.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void)* pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 82    C++
testcrash1.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 381 + 0x27 bytes   C++
testcrash1.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 978 + 0x23 bytes    C++
testcrash1.exe!CMainFrame::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 198    C++
testcrash1.exe!CWnd::OnCommand(unsigned int wParam, long lParam)  Line 2729 C++
testcrash1.exe!CFrameWnd::OnCommand(unsigned int wParam, long lParam)  Line 371 C++
testcrash1.exe!CFrameWndEx::OnCommand(unsigned int wParam, long lParam)  Line 367 + 0x10 bytes  C++
testcrash1.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2101 + 0x1e bytes   C++
testcrash1.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam)  Line 2087 + 0x20 bytes C++
testcrash1.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 257 + 0x1c bytes   C++
testcrash1.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420 C++
user32.dll!_InternalCallWinProc@20()  + 0x23 bytes  
user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes  
user32.dll!_DispatchMessageWorker@8()  + 0xed bytes 
user32.dll!_DispatchMessageW@4()  + 0xf bytes   
testcrash1.exe!AfxInternalPumpMessage()  Line 183   C++
testcrash1.exe!CWinThread::PumpMessage()  Line 900  C++
testcrash1.exe!CWinThread::Run()  Line 629 + 0xd bytes  C++
testcrash1.exe!CWinApp::Run()  Line 832 C++
testcrash1.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 47 + 0xd bytes C++

    Stack dump for command invoked via a keyboard shortcut. We go into kernel mode before arriving in the OnAppAbout function, watch out for the line starting with NTDLL:

    testcrash1.exe!Ctestcrash1App::OnAppAbout()  Line 151   C++
testcrash1.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void)* pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 82    C++
testcrash1.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 381 + 0x27 bytes   C++
testcrash1.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 978 + 0x23 bytes    C++
testcrash1.exe!CMainFrame::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 198    C++
testcrash1.exe!CWnd::OnCommand(unsigned int wParam, long lParam)  Line 2729 C++
testcrash1.exe!CFrameWnd::OnCommand(unsigned int wParam, long lParam)  Line 371 C++
testcrash1.exe!CFrameWndEx::OnCommand(unsigned int wParam, long lParam)  Line 367 + 0x10 bytes  C++
testcrash1.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2101 + 0x1e bytes   C++
testcrash1.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam)  Line 2087 + 0x20 bytes C++
testcrash1.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 257 + 0x1c bytes   C++
testcrash1.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420 C++
user32.dll!_InternalCallWinProc@20()  + 0x23 bytes  
user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes  
user32.dll!_DispatchClientMessage@24()  + 0x51 bytes    
user32.dll!___fnDWORD@4()  + 0x2b bytes 
ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes  
user32.dll!_NtUserTranslateAccelerator@12()  + 0x15 bytes   
user32.dll!_TranslateAcceleratorW@12()  + 0x1c464 bytes 
testcrash1.exe!CFrameWnd::PreTranslateMessage(tagMSG * pMsg)  Line 254 + 0x1b bytes C++
testcrash1.exe!CFrameWndEx::PreTranslateMessage(tagMSG * pMsg)  Line 290    C++
testcrash1.exe!CWnd::WalkPreTranslateTree(HWND__ * hWndStop, tagMSG * pMsg)  Line 3311 + 0x14 bytes C++
testcrash1.exe!AfxInternalPreTranslateMessage(tagMSG * pMsg)  Line 233 + 0x12 bytes C++
testcrash1.exe!CWinThread::PreTranslateMessage(tagMSG * pMsg)  Line 777 + 0x9 bytes C++
testcrash1.exe!AfxPreTranslateMessage(tagMSG * pMsg)  Line 252 + 0x11 bytes C++
testcrash1.exe!AfxInternalPumpMessage()  Line 178 + 0x18 bytes  C++
testcrash1.exe!CWinThread::PumpMessage()  Line 900  C++
testcrash1.exe!CWinThread::Run()  Line 629 + 0xd bytes  C++
    • 0