Window Ghosting（仍可拖动失去响应的窗口，因为我们真正的窗口已经让系统用Ghosting窗口替代了。使用IsHungAppWindow 探测）

最近工作中遇到Window Ghosting这个问题， 感觉挺有意思，这里简单记录下。

 

 

在XP时代我们的程序没有响应后只能通过任务管理器强制杀掉，但是Vista之后情况变了， 我们仍然可以拖动失去响应的窗口，甚至可以尝试最小化和关闭窗口， 我们把这个特性叫住Window Ghosting。

 

首先我们考虑下怎样判断一个窗口是否已经失去响应？

 

一般我们想到的是SendMessageTimeout，给窗口发送WM_NULL消息，判断返回是否超时。这当然也是一种方法，但是系统有更方便的API  IsHungAppWindow， 该API是判断窗口是否失去响应的标准方法。我们猜测IsHungAppWindow内部是否通过SendMessageTimeout来实现的， 跟踪下我们会发现不是我们想象的那样， IsHungAppWindow内部掉用了未公开的API NtUserQueryWindow。

 

接下来考虑下 IsHungAppWindow 是如何鉴定一个窗口是否在失去响应状态？

这是MSDN中的原话： 

Determines whether the system considers that a specified application is not responding. An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not calledPeekMessage within the internal timeout period of 5 seconds.

简单来说就是程序在非等待输入状态 ，不是在程序启动阶段， 并且5秒内没有从消息队列中取消息。 

 

下面我们思考系统是如何实现Window Ghosting的？

我们知道失去响应的窗口一般来说是因为UI线程正在做一些繁忙的工作， 或是UI线程死锁而没有在继续运行了。 那这里就很奇怪了， UI线程都失去响应了， 窗口怎么还能响应我们的鼠标拖动消息？我们的鼠标拖动事件需要运行在UI线程中才行 ，该实现有些颠覆我们现有的计算机知识。

 

这里的关键就是我们看到的失去响应的窗口是不是还是我们原来的窗口？ 实际上我们真正的窗口已经让系统用Ghosting窗口替代了。

 

完整过程是这样的， 当系统检测到我们程序窗口失去响应了， 系统进程(dwm.exe)会以相同的Z-order, 位置，大小和Style创建一个ghosting窗口（可以通过SPY查看 ，类名是Ghost）， 我 们看到的失去响应的窗口就是这个窗口， 该窗口的客户区内容是从老窗口中拷贝过来的。而我们原来真正窗口依旧在那里（style, 位置，大小和z-order都没有变 )， 但是dwm.exe合成屏幕内容是并不会把这个窗口画出来， 所以我们看起来就是原来的窗口给hide了。

 

这就是Window Ghosting的奥秘， 我们可以在程序中调用 API DisableProcessWindowsGhosting 来禁止系统对我们的程序使用 Window Ghosting.

 

Window Ghosting这个特性很不错， 让失去响应的程序也有很好的用户体验， 但是它也带来了一些问题。

我遇到的问题是我们在枚举窗口的过程中，我们通过GetWindowRect查询一个失去响应的程序窗口的位置，但是返回结果却和我们屏幕上看到的不一致， 因为我们看到的是被我们拖动过的Ghosting window，但是API返回的确是被hide的原窗口的位置。 这种情况下我们需要原窗口和Ghosting窗口的一张映射表， 但是我还没有找到他们对应关系的方法， 不知道系统又没有相关API提供？一种方法是通过查找类名是"Ghost"的窗口，判断进程是不是dwm.exe， 再通过标题匹配。但是该方法效率低，也不可靠。

http://www.cnblogs.com/weiym/p/3512680.html