The recent work encountered window ghosting this question, feel very interesting, here simple record.
In the XP era our program is not responding and can only be forced to kill by the task manager, but after Vista has changed, we can still drag the unresponsive window, and even try to minimize and close the window, we call this feature window ghosting. First, let's consider how to tell if a window has lost its response. In general, we think of SendMessageTimeout, sending a wm_null message to the window and judging if the return is timed out. This is certainly a method, but the system has a more convenient API Ishungappwindow, which is the standard way to determine if a window is unresponsive. We guessed whether the internal Ishungappwindow was implemented through SendMessageTimeout, following which we would find it was not as we imagined, Ishungappwindow internal unused API Ntuserquerywindow. Next consider how the Ishungappwindow is to determine if a window is in a unresponsive state? This is the exact words of MSDN: Determines whether the system considers that a specified application was not responding. An application was considered to being not responding if it was not waiting for input, was not in startup processing, and have no T called
PeekMessageWithin the internal timeout period of 5 seconds. In short,The
program is not waiting for input status, not in the program startup phase, and no messages are taken from the message queue within 5 seconds. Let's consider how the system implements window ghosting. We know that a window that is unresponsive is generally because the UI thread is doing some busy work, or the UI thread is deadlocked and not continuing to run. It's strange here that the UI thread is unresponsive, how can the window respond to our mouse drag messages? Our mouse drag events need to be run in the UI thread, which is a bit disruptive to our existing computer knowledge. The key here is that we see the unresponsive window is still our original window? As a matter of fact
our real window has replaced the system with the ghosting window. The complete process is like this, when the system detects that our program window is out of response,The
system process (Dwm.exe) creates a ghosting window with the same z-order, location, size, and style (can be viewed by the spy, the class name is Ghost), the window where we see the unresponsive window, where the client area content is copied from the old window. Our real window is still there (style, position, size and z-order), but the Dwm.exe compositing screen content is not going to draw this window, so we look like the original window to hide. This is the mystery of window ghosting, and we can call API disableprocesswindowsghosting in our program to prevent the system from using window ghosting for our programs. Window ghosting is a good feature, so the unresponsive program also has a good user experience, but it also poses some problems.
The problem I encountered was that we were in the process of enumerating the windows, and we queried the location of a program window that was unresponsive by GetWindowRect, but the return result was inconsistent with what we saw on the screen, because we saw the ghosting window we had dragged, But the API return is indeed the location of the original window of hide. In this case we need a map of the original window and the ghosting window, but I have not found the corresponding method of their relationship, I do not know that the system does not provide the relevant API? One way is to find out if the process is dwm.exe by looking for a window with the class name "Ghost" and then match it by the title. But the method is inefficient and unreliable.
Http://www.cnblogs.com/weiym/p/3512680.html
Window ghosting (You can still drag the unresponsive windows, because our real window has already replaced the system with the ghosting window.) Using Ishungappwindow probing)
