views:

313

answers:

4

I have an app which uses a keyboard hook procedure in a library. The wParam in the hook for one message is 255 which we think is "(reserved / OEMClear)". I'd like to work out the source of this message as it causes my application to crash in the library, and given it shouldn't be happening it would be good to identify it. The message comes in repeatedly on only one PC we have - other computers don't see the message at all.

So, is there a way to trace the source of a message sent to a window please, or all those on the system?

A: 

Im not sure if this does what you want it to but have a look at Process Monitor by sysinternals.

http:// technet.microsoft.com/en-us/sysinternals/bb896645.aspx

It shows everything that happens to a process so i assume it catches messages as well. The site was down at time of writing so i couldnt check.

Ozzy
Thanks - it doesn't appear to trace messages, but it lead me to http://msdn.microsoft.com/en-us/library/cc267862.aspx which details the debug options in the debug build. But nothing there for message tracing either!
mj2008
I don't see windows messages as an 'operation' in Process Monitor.
Aardvark
A: 

(I originally suggested using Spy++ or winspector, but they do not hook into the sending of messages. That doesn't even make sense! A window receives messages but they don't send them, a thread does that. I'll leave my suggestion about using a debugger.)

Sometimes debugging can help. Try downloading the windows PDB files and setting a breakpoint that hits only when one of these messages occur. Looking at the call stack at that point can often shed some light on why things are happening. Posted messages and messages send from other processes will foil this approach.

Aardvark
I looked at Winspector first (used it for years) but it doesn't show the source. The debugger may be the only choice...
mj2008
+3  A: 

There is no built-in way to find out who sent the window message, not even win32k keeps track of this; you might be able to find it out with a kernel debugger and a conditional breakpoint.

However, I would argue that you don't really need this information; you need to make your app properly handle any message sent to it.

Paul Betts
I'd half agree - our purpose here is to find the cause, then we can judge the seriousness and handle it appropriately. I don't want to just stick a plaster over it in case it bites later, particularly as this is a commercial library that the fault fails in.
mj2008
@mj2008: If you're deploying this to machines you don't fully control, you're going to get bitten; lots of badly-written apps send strange messages to all windows in attempts to do stuff and you *have* to deal with it elegantly. Just capture the messages you're interested in, and pass the rest along to the next hook in the chain.
Paul Betts
+1  A: 

There is no built-in way to find out who sent the window message

Of course there is. But it's advanced Win32 programming (by hooking CSRSS)

CSRSS doesn't handle window messages, win32k does in kernel mode.
Paul Betts