5 days after I posted that it started working again (albeit with the rather confusing "ContentLab" moniker) so if some individual took some action as a result of my posting then thankyou!

I have the same issue - no newsletters for some months. Nothing from CodeProject in my Junk mail folder, which is where emails from any blocked senders would end up. I suspect it started happening when I changed my email address (employer changed it's name & domain) but I can't be sure.

Agreed, it's not something I would rely on. I was just intrigued to discover that there is some sort of undocumented queue for sent (as opposed to posted) messages.

Understood, thanks for your reply. I'm looking at some not-very-well-designed legacy code and trying to work out whether its attempts to deal with a potential deadlock are flawed. Given that it's over 20 years old and nobody has complained it's probably better to just leave it alone.

This is an observation rather than a question - if it's not appropriate I will happily delete it. I was wondering what would happen if multiple calls were made to SentNotifyMessage() (where the receiving window is owned by a different thread) during the period that the receiving thread was still processing the first such message it received. My guess as that the thread would be deemed hung and that SendNotifyMessage() would fail. Wrong! The documentation says "...If the window was created by a different thread, SendNotifyMessage passes the message to the window procedure and returns immediately; it does not wait for the window procedure to finish processing the message." Saying that it "passes the message" I think makes it clear that the message doesn't go into the same queue as messages posted with PostMessage(). I set up an experiment (on Windows 10) where the thread which owns the window 'hangs' itself (simply by sitting in a tight loop waiting for a period time to expire) for a substantial period of time when it first receives a message. The thread which sends the messages sits in a loop continuously sending a large number of messages (using SendMessageNotify). Using TRACE output to monitor what was happening I could see that all of the calls to SendMessageNotify() succeeded and happened whilst the receiver was hung processing the the first message. When that hung period expired it then received all of the remaining sent messages in succession. This worked with 100,000 "queued" messages. I was surprised. Windows obviously queues these messages and can cope with a very large number of them.

Yes, good idea. Thinking about it I probably should have posted this under Windows Development not C/C++ (ditto my following post about SendNotifyMessage()).

If I call SendMessageTimeout() with the flag SMTO_ABORTIFHUNG and a finite timeout period then it could fail (return 0) due to either of these reasons: 1. Timeout (the thread which owns the window started processing the message but didn't complete it within the timeout period). 2. The thread which owns the window was considered to be hung, so didn't (and won't) process the message. In the first case GetLastError() returns ERROR_TIMEOUT (1460). I can't find any error codes in winerror.h which look relevant to the second case (hung thread). What I actually want to know, immediately after SendMessageTimeout() returns, is whether the thread which owns the window has or will actually start processing the message. I don't need nor want to wait until it has finished processing the message. I've spent a couple of hours searching the web and reading various articles, questions etc. but not found an answer to this. A little while later... I've set up a test case where the window owning thread is spinning in a loop, and then I call SendMessageTimeout(hWnd, WM_MY_MESSAGE, wParam, lParam, SMTO_NORMAL|SMTO_ABORTIFHUNG, 1000, &dwResult). SendMessageTimeout() immediately returns 0 as expected, and calling GetLastError() returns [drumroll...] 18 (ERROR_NO_MORE_FILES)!!! Go figure... So it seems there are 2 yucky ways to trap this: 1) Wrap a timer around the call to SendMessageTimeout(), and if it returns in less than the timeout period (1000ms in the example above) then we know it failed because the thread is hung. 2) Test GetLastError(), if it's ERROR_TIMEOUT then we know it's a timeout, if it's ERROR_NO_MORE_FILES then we assume it's because the thread is hung. Or maybe if it's NOT ERROR_TIMEOUT then assume it's because the thread is hung. Method 1 is smells of kludge, method 2 relies on undocumented behaviour. And while we are on undocumented behaviour, it seems that passing a timeout value of 0 means "infinite timeout" although no doc I can find for SendMessageTimeout() mentions that. And some time later again... Well the behaviour is inconsistent. I've also had it fail (return 0) immediately with ERROR_TIMEOUT, and bizarrely sometimes fail immediately with error code 0 (ERROR_SUCCESS). This is Windows 10. It seems that all bets are off in trying to interpret the return value and/or error code.