Sometimes my psychic powers are weak

Date:September 18, 2006 / year-entry #316
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060918-01/?p=29703
Comments:    11
Summary: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...

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. Eric D. Burdo says:
    September 18, 2006 at 11:40 am

    > 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:
    September 18, 2006 at 11:41 am

    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:
    September 18, 2006 at 1:31 pm

    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:
    September 18, 2006 at 7:55 pm

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

  5. Scott Tringali says:
    September 18, 2006 at 10:35 pm

    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:
    September 19, 2006 at 3:55 am

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

  7. KiwiBlue says:
    September 19, 2006 at 4:32 am

    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:
    September 19, 2006 at 9:05 am

    Releasing source code would remove this problem?

  9. KiwiBlue says:
    September 19, 2006 at 10:12 am

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

  10. Vipin says:
    September 19, 2006 at 2:40 pm

    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:
    September 19, 2006 at 5:30 pm

    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.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index