Sometimes my psychic powers are weak


Why does my MFC program exit unexpectedly? The stack trace at the point we hit ExitInstance goes like this:

CClientConsoleApp::ExitInstance
CWinThread::Run+0x88
AfxWinMain+0x84
_wWinMainCRTStartup+0x138
BaseThreadInitThunk+0xe
_RtlUserThreadStart+0x23

Thanks.

You can already see some of what's going on, but clearly more information is needed. My first psychic suggestion was to examine MFC's message pump to see what causes it to exit. Then follow the money backwards.

That's what we want to know and what we want to find out.

MFC comes with source code so you can do this yourself. Don't expect somebody to do your debugging for you. You have the tools to do it yourself: You have the source code and you have a brain.

Once you figure out what conditions make MFC's message pump exit, then try to figure out which of those conditions is actually occurring, and then set breakpoints to try to catch the condition being achieved.

I don't have the MFC source code memorized and I didn't feel like installing it just to help somebody solve their own problem, so I resorted to wild guessing in the guise of psychic powers:

I don't know what MFC's message pump looks like but my psychic powers tell me that it stops when it gets a WM_QUIT message. My psychic powers are losing strength from being so heavily stressed so early in the morning... I see a shadow, a vague form, it's not all that clear, kind of hazy, it might be... yes I think it says "PostQuitMessage"... hard to tell... connection fading...

(Sorry, I can't finish up this story with a snappy ending. It happened so long ago I forget what the problem was.)

Comments (11)
  1. > It happened so long ago I forget what the problem was.

    Boy… you need to work on those powers of yours.  Psychic powers shouldn’t be constrained by time.

  2. Ritchie Swann says:

    You’d expect PostQuitMessage() to be the root cause of this, but wouldn’t calling PostMessage() with WM_QUIT message cause it too?

    And what would happen if the message to post was stored in a variable, and just happened to (accidentally or otherwise) evaluate to WM_QUIT at that one point?

    Yes, the MSDN documentation says "don’t do this", but that doesn’t stop some people…

  3. Vipin says:

    yup, Ritchie is right, most of the time people end up posting WM_QUIT when they should be posting WM_CLOSE to terminate their application appropriately. The windows message loop shuts up when it catches the WM_QUIT because GetMessage(…) returns 0 when it gets the WM_QUIT from the message queue. It will be same in mfc.

  4. St. Alphonsos Pancake Breakfast says:

    I think the stack was trampled and simply ended up there.

  5. I love bug reports like this. It means either the person is so fundamentally lazy that they don’t deserve help, or, they are so fundamentally stupid no amount of help will make a difference.

    <DELETE>

  6. required says:

    Or simply so fundamnetally inexperienced that they did not know how to do the things themselves.

  7. KiwiBlue says:

    I’d call this person fundametally inexperienced. After all, he/she knows about the call stack. I remember dealing with guy who got an assert in the debug build and didn’t know where it came from.

  8. . says:

    Releasing source code would remove this problem?

  9. KiwiBlue says:

    Releasing source code of MFC? It has been released decades ago :)

  10. Vipin says:

    Sometimes call stack in itself don’t tell the entire story,especially with GUI model on windows. Windows being fundamentally an event driven stuff, a message posted to a queue from nowhere could cause something(random) like this to happen and you won’t be able to trace back to the original culprit unless you do some code level tracing by greping and figuring the possible WM_QUIT posting code.

  11. Igor Delovski says:

    I had a similar problem with 100% of pure my own win32 code – no MFC no any other library. I wasn’t pumping messages at the same rate as I was initiating them. There was a loop, there was a PeekMessage() call and there was a progress bar.

    Every iteration of the loop shaved one message only and incrementing the progress bar generated more than that. So, after a few hundred iterations Windows decided to get rid of me and my loop and it just sent me WM_QUIT so my application properly saved settings and terminated.

    I was staring at my code in debugger in total disbelief and after several hours of pulling my hair off I removed the progress bar and it all stopped. No more WM_QUIT messages.

    At that point I decided to reorginize the message pumping part somehow.

Comments are closed.

Skip to main content