   Monitoring window messages
  I am making an application similar to Winspector Spy or Microsoft's Spy++. I have created a DLL to hook into all processes using SetWindowsHookEx to monitor all messages sent to the windows. Then i send that data to my application by sending the WM_COPYDATA message. This works most of the time, but sometimes my app will crash (probably some silly little bug) and other times the DLL will crash and bring down the entire system :(.Firstly, i was hoping someone might be kind enought to have a quick look at my code and make sure i haven't done anything stupid that would/could corrupt memory or something bad like that. I have uploaded my code here, the main things to look at are the "hook" and "inspector" folders. The code is written in C++ using Visual Studio 2008. If you want to compile it, you will need the Qt framework.Secondly, i was wondering if i should take a different approach to monitoring messages. If another way would be better, i want to do it sooner rather than later. That way i don't have to change too much and i can move on to other parts of the code knowing that this part is done right.So, one other way to do it would be to have the DLL in each process to post data to a queue use a separate thread in my app which reads that queue to get the data. The data i am refering to is the window message id, params, etc.I beleive this is how Spy++ does it, and it will allow my app to spy on messages without holding up the app that it's monitoring. But it's a lot more difficult to do because it involves threads.   
  Anyone?I have heard of quite a few ways to do inter-process communication (IPC) so i am not sure which one is right for me. I think shared memory is ok, that is what i am using now for some things. But there may be better/easier ways.And there may be alternatives to using threads to access a queue (producer consumer pattern), that's why i'm asking.   ;  is this even possible for all windows version vista and on?   ;  I have used WM_COPYDATA successfully plenty in the past, in an application that I know is stable and runs fine on anything from Windows 98 to Windows 7.I'll see if I can take a look after I get home. I don't have time right now.   ;Quote:is this even possible for all windows version vista and on?Yep, it is though integrity levels introduced some caveats. A lower integrity process can't set a hook in a higher integrity process, SetWindowsHookEx will succeed but no injection will occur for those hooks that require it.Also, for the interest of the OP, with UIPI enabled a lower integrity process can't send messages (bar a select few WM_GET* messages) to a high integrity process so the WM_COPYDATA solution will require your exe to call ChangeWindowMessageFilter to let it through.For the IPC, I'd probably choose a message mode pipe because it intrinsically keeps track of packet size, but any would do a better job than window messages.I haven't looked though the code for the exe, nor have any experience of QT so how you'd optimally plumb it in I have no idea. There's a few ways to get data out of it and remain single threaded, polling with PeekNamedPipe at opportune intervals or ReadFileEx if you can convince QT to use the alertable flag with MsgWaitForMultipleObjectsEx in its message loop.   ;  Thanks for the replies guys, although most of the stuff you said went straight over my head [grin].Regarding WM_COPYDATA, i realise that it is a perfectly reasonable solution in some cases, but in my case i think it is not such a good idea. Since i am monitoring messages sent to other window, the idea of using a message to communicate with my app just seems a bit confusing. But more importantly, if my app hangs while processing WM_COPYDATA, the app that is being monitored will also hang. That is why i want a multi-threaded solution.Now speaking of multi-threaded, i am not sure how i am going to do this. Qt has threads and mutexes and all that, so it would probably be safer if i used them since i don't have much experience writing multi-threaded code and handling things like dead-locks, etc. But the thread is going to have to somehow communicate with my DLL, which is written in plain C (well, it's compiled in C++ but it doesn't use classes or anything). So i will need some way of doing mutexes and all that in the DLL too.As for the integrity levels / privileges, i am not too concerned about that just yet. I can monitor most processes on XP and i can seem to monitor a lot of processes on my Win7 machine too. A bigger problem is 64bit processes. I cannot hook into any 64bit processes on my Win7 machine because i need a 64bit DLL. But i'll get to that later.   