{"id":107612,"date":"2022-12-23T07:00:00","date_gmt":"2022-12-23T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107612"},"modified":"2022-12-15T16:03:00","modified_gmt":"2022-12-16T00:03:00","slug":"20221223-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221223-00\/?p=107612","title":{"rendered":"The case of the recursively hung WM_DRAW­CLIPBOARD<\/CODE> message"},"content":{"rendered":"

An application hang report showed that the application was stuck in this stack:<\/p>\n

win32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nwin32u!ZwUserMessageCall+0x14\r\nuser32!SendMessageWorker+0x823\r\nuser32!SendMessageW+0xda\r\ncontoso!CContosoWindow::WndProc+0xa5d\r\nuser32!UserCallWinProcCheckWow+0x2f8\r\nuser32!DispatchClientMessage+0x9c\r\nuser32!__fnDWORD+0x33\r\nntdll!KiUserCallbackDispatcherContinue\r\nuser32!_InternalCallWinProc+0x2a\r\nuser32!InternalCallWinProc+0x1b\r\nuser32!DispatchClientMessage+0xea\r\nuser32!__fnDWORD+0x3f\r\nntdll!KiUserCallbackDispatcher+0x4c\r\nwin32u!NtUserGetMessage+0xc\r\nuser32!GetMessageW+0x30\r\ncontoso!WindowThreadProc+0x9b\r\nkernel32!BaseThreadInitThunk+0x14\r\nntdll!RtlUserThreadStart+0x21\r\n<\/pre>\n
Inspecting the local variables at each recursive call shows that the message is always WM_DRAW\u00adCLIPBOARD<\/code>. The Contoso window receives the WM_DRAW\u00adCLIPBOARD<\/code> message, does its work, and then forwards the message to the next clipboard viewer window, just like the book says. While waiting for that window to respond, another WM_DRAW\u00adCLIPBOARD<\/code> message arrives, and the cycle repeats.<\/p>\n
The clipboard viewer chain is a linked list of windows that have all subscribed to clipboard notifications. This linked list is managed cooperatively: When you add yourself to the chain, you are given the handle of the previous head of the chain. And when you finish dealing with a clipboard notification, you forward the notification to the next window in the chain. That way, all the windows in the chain eventually learn about the clipboard.<\/p>\n
The clipboard viewer chain was developed back in the days of 16-bit Windows, when all programs were cooperatively multi-tasked and generally were trusted to behave properly. The clipboard viewer chain used the same trick that  window hooks used<\/a> to save space: It externalized the cost.<\/p>\n
Here’s a sketch of how the clipboard viewer chain worked in 16-bit Windows:<\/p>\n
HWND hwndClipboardViewer;\r\n\r\nHWND SetClipboardViewer(HWND hwndNewViewer)\r\n{\r\n  HWND hwndOldViewer = hwndClipboardViewer;\r\n  hwndClipboardViewer = hwndNewViewer;\r\n  return hwndOldViewer;\r\n}\r\n\r\nHWND GetClipboardViewer()\r\n{\r\n  return hwndClipboardViewer;\r\n}\r\n\r\nHWND ChangeClipboardChain(HWND hwndRemove, HWND hwndNewNext)\r\n{\r\n  if (hwndClipboardViewer == hwndRemove) {\r\n    hwndClipboardViewer = hwndNewNext;\r\n  } else {\r\n    SendMessage(hwndClipboardViewer, WM_CHANGECBCHAIN,\r\n        (WPARAM)hwndRemove, (LPARAM)hwndNewNext);\r\n  }\r\n}\r\n\r\nvoid NotifyClipboardViewers()\r\n{\r\n  if (hwndClipboardViewer) {\r\n    SendMessage(hwndClipboardViewer, WM_DRAWCLIPBOARD, 0, 0);\r\n  }\r\n}\r\n<\/pre>\n
And that’s it! The entire clipboard viewer feature in 30 lines of code.<\/p>\n
Okay, so back to our customer’s problem.<\/p>\n
The window registered itself as a clipboard viewer, and the clipboard contents changed, causing it to receive a WM_DRAW\u00adCLIPBOARD<\/code> message. The window dealt with the clipboard change, and then dutifully called Send\u00adMessage<\/code> to forward the WM_DRAW\u00adCLIPBOARD<\/code> message down the chain. Every window in the chain deals with the message, and then calls Send\u00adMessage<\/code>.<\/p>\n
What happened here is that some window in the chain is hung, and that causes all the other windows in the chain to hang, since they are all blocked on each other via Send\u00adMessage<\/code>:<\/p>\n\n\n\n\n\n\n\n\n\n
Window 1<\/td>\n<\/tr>\n
\u2193<\/td>\nSendMessage<\/td>\n<\/tr>\n
Window 2<\/td>\n<\/tr>\n
\u2193<\/td>\nSendMessage<\/td>\n<\/tr>\n
Window 3<\/td>\n<\/tr>\n
\u2193<\/td>\nSendMessage<\/td>\n<\/tr>\n
Window 4<\/td>\nhung<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In order for Window\u00a01’s Send\u00adMessage<\/code> to complete, Window\u00a02 needs to return. But Window\u00a02 is stuck in a Send\u00adMessage<\/code> to Window\u00a03, which is in turn stock in a Send\u00adMessage<\/code> to Window\u00a04, which is hung. That one hung window has caused a chain of windows to stop responding.<\/p>\n
The Contoso window got caught in the chain of windows that are all waiting for that other hung window to process the WM_DRAW\u00adCLIPBOARD<\/code> message.<\/p>\n
So what can Contoso do about this?<\/p>\n
The best solution is to leave the game. Instead of using the old and busted clipboard viewer chain, use the new hotness Add\u00adClipboard\u00adFormat\u00adListener<\/code> function to  register to be notified when the clipboard contents change<\/a> and escape the clipboard viewer chain.<\/p>\n
Fortunately, converting from a clipboard viewer to a clipboard format listener is fairly simple and even involves deleting some code, so that’s a nice bonus.<\/p>\n