Reason: Initially wanted to find out because of the IPC initialization order problem caused tray to die, but happened to encounter the main process popup exit confirmation box is also stuck, and then began to find the reason.
The first is the tracking code, found that the message loop is alive, but the entire message loop can only be taken to the timer and paint messages, using the message tool to grab the window, you can see also canTakeTo GetItemText and other news. (In general, it is now possible to locate the reason for the attachthreadinput, but I do not know at this time);
To think about it, the most likely scenario is that all the windows of the current thread have been disable out, so check all the windows of the process and see no problems.
Recall that the window input message queue is such that the user clicked a window after the system set the window to the Forground window, and then the thread that owns the window becomes the foreground thread, the distribution message queue address saved in the original input thread of the system is switched to the virtual input queue address of the rerouting. Then the system then put all the input messages into this queue.
The window does not receive the mouse and keyboard messages, first determine whether the window is the foreground window, is detected by the tool detection, is indeed the foreground window:
However, the active window is null at this point, which is definitely unable to receive the keyboard message, so it is forced to set as the active window, the main process is still not alive. From another angle, even if this is the active window is 0, but theoretically should still be able to receive mouse messages, mouse messages special in, The system locates the window under the current mouse and distributes the message to the thread that changed the window. There is no relationship between the Forgound and the active window at this time.
Intuitive guessing, should be caused by improper use of an API, so the next step is to find all the Windows Message Queuing related API functions, the most influential is the AttachThreadInput function, the function will be two threads of input queue merge, and share all about the foreground window and other states, So this function is the most suspect.
The test found that if this function is not paired, then one of the threads waits will inevitably cause another thread to die using code to search for all of this function's call, found to be paired use, therefore ruled out the reason that attachthreadinput use improper.
Unofficial history records, Kthread has a User32thread data interface record a threadinfo to save the message queue, and then try to observe the kernel debugging, but this variable is void type, the public symbol did not find the definition of threadinfo, and eventually failed.
Another conjecture is that since it has something to do with threading, kill the thread and start killing all the non-main threads of the main process, but there is still no activation window. Depressed after the start of the killing process, found to kill the tray process is activated, after the test found that tray send after the IPC message immediately return will not causeMain ProcessStuck, the focus went back to the attachthreadinput use. Suspect is a bug where we don't have the source code for a module that uses no pairing. Then choose Debug to find
As the operation step requires tray to startMain ProcessIn the right-click Exit, and smooth operation to reproduce the bug, so the following methods to check the AttachThreadInput function in which module is not paired, so use the following method: WinDbg all the breakpoint events are disabled, at the same time: enable the process initial breakpoint and associated command: BP user32! Ntuserattachthreadinput "|.; printf \ "Src:%n,to:%n,isatt:%n\", poi (@esp +4), poi (@esp +8), poi (@esp +c);. ECHO;KC;GC "; GC; so that the new process will call Ntuserattachthreadinput when the terminal and print out parameters: After the bug is reproduced:
the attach and detach of two threads are not paired and the second will fail directly. The code is as follows:
Test found: After two threads attach, if one thread dies, the other thread will be stuck, and all mouse and keyboard messages will not be received in two threads, and the other thread would block in getmessage or similar wait functions. However, the thread can still accept messages such as a timer, for the following reasons: When two threads attach after the input queue is merged into one, it is necessary to take out the hardware input message, two thread colleagues are present, that is to say, two threads of getmessage synchronization to get out, Otherwise it can not be taken out, the equivalent of a two-key to open the lock, the two holding the key at the same time to open the door, and the timer and other messages in another message queue, it will be smooth out.
The reason is ok to reproduce the bug, from tray start the main process after the right click on the tray, so that the focus on the menu, at this timeMain ProcessStartup will attach itself with tray's main thread, then SENDIPC messages from tray toMain Process, and then tray will waitMain ProcessThe reply so tray terminates the message loop and waits on the sendipcmessage, causing the Baiduaan to be unable to accept the mouse message and thus get stuck. It also explains whyMain ProcessWhen debugging, often stuck in the vs,windbg or taskbar and other reasons.
Summary: 1, if the occurrence of receiving a mouse message, and the message loop or 1, whether all windows are diable,2, and another thread has a attach relationship 2, do not easily exclude a problem, need to have the exact reason and careful examination can be excluded. 3, Careful use of attachthreadinput.4, in fact, if the beginning of the death peg AttachThreadInput will soon find the reason, sloppy test and rough code check led to the later tangled reference http://blogs.msdn.com/b/ oldnewthing/archive/2013/06/19/10426841.aspxhttp://www.slideshare.net/wvdang/ five-things-every-win32-developer-should-knowhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms644927 ( v=vs.85). aspx
A master process is stuck with a dead trace
