虚拟化环境程序卡在NtUserPeekMessage，坚持该故障本不应发生是否正确？

你的判断完全正确，该问题属于虚拟化环境的实现缺陷，并非应用自身问题。

• 应用逻辑本身无错误
  你使用的MsgWaitForMultipleObjects + Application.DoEvents组合是WinForms场景下「等待内核事件同时保持UI响应」的常规实现，逻辑完全符合Win32消息循环设计规范，正常Windows环境下不会出现永久阻塞。
• API行为异常指向虚拟化层问题
  挂起点停在NtUserPeekMessage内核调用上，本身就不符合微软的API设计约定：PeekMessage是无等待的消息查询接口，无论消息队列是否有内容都应该快速返回，出现永久阻塞只能说明下层实现有问题。
• 应用侧异常已排除
  • 实体机环境完全无法复现，仅虚拟化环境可稳定复现，故障触发条件和虚拟化层直接绑定
  • 应用99.9%为托管代码，且长期运行无堆损坏记录，可排除内存破坏导致API调用异常的可能
  • Application.DoEvents未出现在调用栈属于正常的尾调用优化行为，和故障无关
• 补充信息直接锁定根因
  你观测到的异常输入队列附着操作，完全对应了故障的根因：原生Windows系统下，对未设置WS_CHILD标志的窗口调用SetParent不会触发输入队列附着，也不会生成异常的AttachThreadInput调用。虚拟化环境出现了不符合规范的队列附着操作，会直接导致不同线程的消息队列互相锁死，刚好匹配你观测到的NtUserPeekMessage永久阻塞现象。

你可以将输入队列附着的测试结论提交给虚拟化供应商，要求其修复User32/Win32u组件的窗口管理兼容缺陷。

内容的提问来源于stack exchange，提问作者Joshua