WTL window/form crashes after infinite message loop causes stack overflow

I have a legacy project I need to fix bugs in, WTL/VC++. One of the problems - a crash of the main window (well, the entire application, of course) after Ctrl+X or Ctrl+Z keys are used. I don't have any custom accelerators assigned to those keys. I found that the "fatal" key combinations cause an infinite message loop with

uMsg == 273 (0x00000111)

that eventually crashes with stack overflow error:

 Command Code: 5, ID: 29892, HANDLE:  0xe091aFirst-chance exception at 0x007f88fa 
 in <myApp>.exe: 0xC00000FD: Stack overflow.
 Unhandled exception at 0x007f88fa in <myApp>.exe: 0xC00000FD: Stack overflow.

I simply patched it in the message processing function -

BEGIN_MSG_MAP(CMDIChildWindowImpl)

    MESSAGE_HANDLER(WM_CREATE, OnCreate)
    MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
    MESSAGE_HANDLER(WM_CLOSE, OnClose)
    MESSAGE_HANDLER(WM_TIMER, OnTimer)

* *

    COMMAND_ID_HANDLER(ID_FILE_NEW, OnNewDownload)
    COMMAND_ID_HANDLER(ID_UPLOAD_FOLDER_SET, OnUploadFolderSet)
    COMMAND_ID_HANDLER(ID_OPEN_RECORD_BY_ID, OnOpenOnline)

* *

    NOTIFY_CODE_HANDLER(HLN_PORTAL_RECORD_DOWNLOAD, OnPortalPageNotify);
    NOTIFY_CODE_HANDLER(HLN_SELCHANGED, OnWebFormNotify);
    if(uMsg == 273)
     return false;
    else
     CHAIN_MSG_MAP(baseClass)

END_MSG_MAP()

But I'm not satisfied with this band-aid patch, it would be nice to understand what's going on - and I actually want those key combinations do the Windows default things on my form, "cut" and "undo"

more info on the fatal messages:

Ctrl+X -

uMsg 273 unsigned int

wParam 123171 unsigned int

lParam 0 long

lParam 0 long

Ctrl+Z -

uMsg 273 unsigned int

wParam 123179 unsigned int

lParam 0 long

Sorry if this doesn't make sense, my VC++ kung fu is rather rusty; If anyone could give me a hint where to look for the ideas, that would be greatly appreciated.

Thank you!

O.

Found this, thanks to @Roman R. - in the window in question, there was no handler for the WM_COMMAND message, and in one of its base classes there was a function that generated the infinite loop by forwarding the message back to the active window. So I added this handler -

        if(uMsg == WM_COMMAND)
          return DefWindowProc(WM_COMMAND, wParam, lParam);

which seems like a good solution for me.

Thanks!