CAsyncSocket message handling

From:

neilsolent <n@solenttechnology.co.uk>

Newsgroups:

microsoft.public.vc.mfc

Date:

Wed, 16 Sep 2009 00:54:51 -0700 (PDT)

Message-ID:

<7ffc39d6-54d7-4b73-aa08-3d96dba3da90@d23g2000vbm.googlegroups.com>

My app is crashing with the following pop-up in a certain situation:

Socket Notification Sink
Blah blah write at 0x00000004
Unhandled exception MFCN42D.DLL 0xc0000005 (access violation)

The app listens on a TCP port using instances of a CAsyncSocket-
derived class. When a connection is accepted
but later rejected (if SSL handshake failed for example) the socket is
closed. After this point, the listening
loop is posted a message which seems to lead to the crash:

        MSG msg;
        while (GetMessage(&msg, NULL, 0, 0) == TRUE)
        {
            LOGWARN "Received msg: [message=%u, hwnd=%d, wParam=%u, lParam=%u,
x=%u, y=%u]",
                msg.message, msg.hwnd, msg.wParam, msg.lParam, msg.pt.x,
msg.pt.y);
            ..
            ..

            TranslateMessage(&msg);
            DispatchMessage(&msg); // <- Line 2688
        }

The last message received before the crash is logged as:

Received msg: [message=883, hwnd=2556196, wParam=524, lParam=32,
x=869, y=828]

The stack backtrace shows:

MFCN42D! 5f6052b8()
MFCN42D! 5f605ab6()
MFCN42D! 5f60633f()
MFC42D! 5f43177c()
MFC42D! 5f4310b8()
MFC42D! 5f42ec09()
MFC42D! 5f42f0f5()
MFC42D! 5f49265d()
USER32! 7739c3b7()
USER32! 7739c484()
USER32! 7739c73c()
USER32! 7738e406()
_tcomx(void * 0x001d011a) line 2688 + 12 bytes
KERNEL32! 77e66063()

I don't *know* what message 883 (0x0373) is - I have not posted it
myself, and it is not mentioned in any header files I can find. I
*assume* it is how the callbacks like CAsyncSocket::OnReceive() are
implemented.
Hence - the crash is probably because I am processing a callback on a
socket that has already been deleted. Question is - how can I fix the
code? I assume the callback messages were already in the queue before
I deleted the socket..
I could do some lookup using the wParam member of the MSG (which seems
to match the socket handle) - seems a bit messy though. Hopefully
someone has already got round this in a neater way ..