Примерно так и есть. Не уверен, что реализация именно такая как написал MasterZiv на 5й странице, но суть думаю верная.

Причем была разница в поведении винды, раньше было не так, и произошла если моя память не врет на одном из сервис паков ХР. Раньше если приложение зависало, зависала и его кнопка закрытия, а потом перестала.
Изначально винда действительно была максимально невытесняюще многозадачная, как задумано, и при закрытии окна приложения оно получало сообщение WM_CLOSE, должно было на него реагировать, закрываться, и типа все хорошо. Но потихоньку стало расти число приложений, которые глючили и не закрывались по сообщению WM_CLOSE, или закрывались не сразу. И сначала в MS ввели таймер и появились сообщения "похоже, приложение перестало отвечать", но оказались недостатки и у этого решения, во-первых, тамаута и сообщения приходилось сравнительно долго ждать при зависании, а во-вторых кнопка закрытия продолжала быть зависшей вместе с приложением, и это некомильфо все видели. Поэтому еще позже и обработку NC вынесли из кода приложения, как минимум в части обработки этой кнопки закрытия, чтобы четче, быстрее реагировать на зависание. Ну и кнопка закрытия теперь в отличие от приложения продолжает работать, как и винда, что имиджевый плюс для MS.

Сделав обработку нажатия кнопки закрытия в NC внешней, в MS получили возможность дополнительного реагирования в этой области, и в том числе, блокировать попадание входящих сообщений в очередь приложения, придерживая их в ядре; и не дожидаясь срабатывания таймаута, по которому устанавливалось зависание приложения, а сразу, при нажатии кнопки закрытия, т.е. до самого сигнала закрытия от юзера (отпускания кнопки). Именно поэтому, как я понимаю, пропадает реакция внутри окна, - пропадают входящие сообщения, на которые приложение реагирует, включая WM_TIMER.