A customer discovered a bug in their control that resulted in a crash: <\/p>\n
\nLRESULT CALLBACK MyWindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)\n{\n switch (uMsg) {\n ...\n default:\n if (uMsg == g_customRegisteredMessage) {\n \/\/ For this message, the lParam is a pointer\n return HandleCustomMessage((SOMETHING*)lParam);\n }\n break;\n }\n return DefWindowProc(hwnd, uMsg, wParam, lParam);\n}\n<\/pre>\nThe problem is that under certain conditions, the control doesn’t initialize the g_customRegisteredMessage<\/code> variable. If a WM_<\/code>NULL<\/code> message arrives, the test <\/p>\n\n if (uMsg == g_customRegisteredMessage) {\n<\/pre>\nis true<\/code>, and we take the lParam<\/code> of the WM_<\/code>NULL<\/code> message and treat it as a pointer. Since the lParam<\/code> of the WM_<\/code>NULL<\/code> message is usually zero, this causes the program to crash with a null pointer. <\/p>\nThe customer fully acknowledged the bug. But their question was one of risk management. How likely is a window going to receive the WM_<\/code>NULL<\/code> mesasge? Knowing the likelihood of the scenario would help them decide how critical the fix is. (And they weren’t able to reproduce the problem in-house, so as far as they could determine, the likelihood was effectively zero. And yet it was happening.) <\/p>\nThe WM_<\/code>NULL<\/code> message is not a common one, but it’s not uncommon either. Posting a WM_<\/code>NULL<\/code> is usually done by a window to itself in order to wake up its message loop<\/a>. This is typically done when the program has a custom message loop, and it needs some of the non-message code to run. We saw an example of this some time ago<\/a> where we posted a WM_<\/code>NULL<\/code> to let our message loop know that the pseudo-dialog has exited. <\/p>\nPosted WM_<\/code>NULL<\/code> messages are usually done from a program to itself, and they are usually posted as thread messages, not window messages, so they don’t normally come through the window procedure. <\/p>\nSending a WM_<\/code>NULL<\/code> is a different story, though. It is a relative common technique to send a WM_<\/code>NULL<\/code> message to a window for the purpose of checking whether the window is responding to messages. We used it to wait for a window to finish processing a foreground change<\/a>. Some system monitoring tools will periodically call SendMessageTimeout<\/code> to send a WM_<\/code>NULL<\/code> to all windows, just to see if they are responding. Windows UI Automation uses WM_<\/code>NULL<\/code> messages help determine the window interaction state<\/a>. <\/p>\nThe customer could try running system monitoring tools or accessibility tools to increase the likelihood of receiving a WM_<\/code>NULL<\/code> message under normal use. (I mean, sure, they could write a program that explicitly sends a WM_<\/code>NULL<\/code> message to their window, but that wouldn’t be anything a normal end-user would have.) <\/p>\nI suspect the customer will bump up the priority of this issue due to the accessibility angle. People who use accessibility tools tend to really need them. It’s not like you can tell a person with poor visual acuity, “Oh, just suck it up for a while.” <\/p>\n