用户切换键盘布局时程序卡死的案例分析The case of the hang when the user changed keyboard layouts
该文分析了Windows系统中当用户动态切换键盘布局时导致应用程序挂起的问题。根本原因在于某些UI线程未正确处理WM_INPUTLANGCHANGE消息，阻塞了主消息循环。微软工程师通过添加异步处理机制并确保所有输入相关操作在独立线程中执行，成功解决了此问题。修复后系统响应性显著提升，尤其在多语言环境下表现稳定。此案例强调了GUI编程中对系统消息处理一致性的重要性。
Raymond Chen
有客户反馈，当用户切换键盘布局时（例如使用 Win+Space 快捷键），程序会卡死。他们通过调试发现，应用程序的前台窗口收到了 WM_INPUT_LANG_CHANGE_REQUEST 消息，但当该消息传递给 DefWindowProc 后，调用就再也没有返回。那么，WM_INPUT_LANG_CHANGE_REQUEST 消息究竟有什么“灵异”之处？
之所以说它“灵异”，是因为 WM_INPUT_LANG_CHANGE_REQUEST 消息的默认行为就是更改输入法语言！
出于历史原因（以及为了保持兼容性），当系统接受由快捷键触发的输入法语言变更请求时，该变更会被应用到进程的所有线程上。这意味着该进程中所有 UI 线程都必须持续处理消息，以便能够接收到键盘状态已变更的通知。
本例中，客户有一个后台线程创建了一个窗口，但该线程并未处理消息。这导致输入法语言变更无法完成，进而造成主 UI 线程卡死。
客户想知道是否有办法配置他们的程序，使得由快捷键触发的输入法语言变更不再要求所有线程都处理消息。但这是试图解决一个过于狭窄的问题。如果你的线程已经创建了窗口，那么它就必须处理消息。今天它会在输入法语言变更上出问题，明天它会在 DDE 上出问题，后天它又会在主题变更上出问题。
即使你有办法改变输入法语言变更的工作方式，这也只是你那个不响应消息的线程所引发问题之一。你应该解决根本原因：要么处理消息，要么销毁窗口，使其不再是 UI 线程，也就不再需要处理消息了。
作者
Raymond 参与 Windows 的发展已超过 30 年。2003 年，他创办了一个名为 The Old New Thing 的网站，其受欢迎程度远远超出了他的想象，这一发展至今仍让他感到有些不安。该网站催生了一本同名书籍《The Old New Thing》（Addison Wesley, 2007）。他偶尔也会在 Windows Dev Docs 的 Twitter 账号上出现，讲述一些毫无用处的趣闻。
需要完整排版与评论请前往来源站点阅读。