One way is to locate the receiving thread and determine when it woke up. In the "CPU Usage (Precise)" graph, "Stacks" graph preset, zoom in on the time the message was received. Open the trace in the Windows performance Analyzer. Trigger the sending of the message you are interested in. Make sure to include the "CPU usage" profile. Use the Windows Performance Recorder to start a trace. It's even possible to see what the call stack of the sending thread was at the time it sent the message, and even the kernel side ( win32k) part of the stack! Using this feature, it is often possible to determine which thread sent the message - it's the thread that readied the receiving thread. It turns out that Windows provides ways to precisely trace which threads are readying which other threads, using Event Tracing for Windows. 
When the message is delivered, the sending thread readies the receiving thread, pulling it out of its wait state. The basic idea is to exploit the fact that, when the message arrives, the recipient window thread is typically blocked waiting in its message loop (specifically, GetMessage()). It requires making a couple of assumptions so it's not 100% reliable, but so far I haven't found a case where it didn't work. I came up with a technique for determining who is sending a win32 window message across threads/processes during one-off debugging/troubleshooting sessions.
0 kommentar(er)
