7

We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).

The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.

I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).

So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.

This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".

Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.

Roger Rowland
  • 25,885
  • 11
  • 72
  • 113
  • If none of your registered messages use both `wParam` and `lParam`, you could store your tags there. – Frédéric Hamidi Mar 29 '13 at 09:52
  • Thanks - but `wParam` and `lParam` are well used :-( In fact, the API actually passes lots of data in the messages via `struct`'s in MMFs, too much detail to explain here. I don't want to mess with those `struct`'s, which is the problem. – Roger Rowland Mar 29 '13 at 10:03
  • This just isn't an option, stop looking there. – Hans Passant Mar 29 '13 at 12:50
  • How do you "track" the messages? Can you already tell if a message A in the server is the message B sent by one of the clients? If so.. what about "tagging" and remembering the messages in your "sniffer"? – Lorenzo Dematté Mar 29 '13 at 13:15
  • I assume you're hooking `PostMessage`. If you can determine who called `PostMessage`, you could save the message parameters and the caller in a list so that when it's removed from the message queue you can locate it and get the caller. You'd have to be careful here to make sure that every message you save gets cleared. Or you could save a timestamp and periodically groom the cache of older messages. – Jim Mischel Mar 29 '13 at 13:48
  • @dema80 - yes that was my initial thought too - but how to "tag" and "remember" is the problem - many messages are otherwise identical so I would need to add some unique tag to each message somehow. – Roger Rowland Mar 29 '13 at 20:01
  • Ok, thanks for the comments - it looks like this is a no-go and I'll have to consider building this tracing mechanism into a future incarnation of the system. – Roger Rowland Mar 29 '13 at 20:03
  • It would make more sense to use named pipes, you could just plug the pipes into the PostMessage/GetMessage – paulm Apr 17 '13 at 11:41
  • A Windows MSG is fixed in size, there is nothing more. Since you own these messages and the w/lParams, the simplest way still is to add some tracking info in the structs/classes behinds those params. One other solution could be to code your message in 16 bits + your tracking info in 16 bits (which makes a message value of 32-bit), and hope no one uses the same values. I don't think you'll find anyone that has the same kind of problem as there are many ways to do IPC mechanism without writing your own stuff :-) – Simon Mourier May 03 '13 at 09:07

1 Answers1

1

FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted

Jack
  • 741
  • 1
  • 8
  • 25
  • Well, I know both the HWNDs, but there is nothing in the MSG structure that I can compare to tie the source to the target. The GUI will be sending multiple messages for different reasons (e.g. user command, timer etc.) and the MSG content is identical. I need to track separately for each origin message. – Roger Rowland May 03 '13 at 07:14
  • unless we add extra info to the message, it is impossible to figure out the origin. – Jack May 03 '13 at 14:44
  • That's right - hence my question ;-) I would rather not change our API to include tracking info because it's used by third-parties. I was looking possibly for an undocumented way of "tagging" a message - I think such a thing doesn't exist, but I'm grateful that you spent some time trying to help, so +1 anyway. – Roger Rowland May 03 '13 at 14:46
  • thanks Roger and yes. you have already mentioned it in the problem statement. However, my reply was out of frustration after some failed attempts. and also I realized Windows OS philosophy is always like- thread processing the message doesn't bother from where it has come, it just processes it. – Jack May 03 '13 at 15:00
  • 1
    found this link http://stackoverflow.com/questions/910991/how-can-my-app-find-the-sender-of-a-windows-message – Jack May 03 '13 at 15:00
  • Good find! So that really confirms I have no option but to change our API :-( I guess this is something to remember for future developments.... – Roger Rowland May 03 '13 at 15:02