System-wide CBT in .NET?
-
Hi, I've implemented global mouse and keyboard hooks in C#, however, once I set the hook type to WH_CBT and run the application, an ugly black command prompt screen prompts out saying there was an error in CLR at runtime :wtf: Has anybody been able to implement system-wide CBT hooks in any .NET language? If I keep getting stuck in this, can I make a c++ DLL that does all the hooking and use it in my C#/VB.NET app? Thanks
-
Hi, I've implemented global mouse and keyboard hooks in C#, however, once I set the hook type to WH_CBT and run the application, an ugly black command prompt screen prompts out saying there was an error in CLR at runtime :wtf: Has anybody been able to implement system-wide CBT hooks in any .NET language? If I keep getting stuck in this, can I make a c++ DLL that does all the hooking and use it in my C#/VB.NET app? Thanks
Without any more details than that, it's impossible to help you. What was the exact error? Debug your application (if you're using VS.NET, you should be prompted to attach a debugger) and find out what the offending code is, as well as the exception. That, too, could be greatly beneficial to us when trying to help you. A word of extreme caution: global system hooks are dangerous. Write clean, efficient, error-handling code that does what it needs quickly. Managed code isn't already the best idea for this (at the very least, there is a performance penalty for marshaling between native and managed code), but it is possible. As far as using a native DLL (which I recommend for the reason I gave above), yes you can use it. The question is how. .NET can interoperate with COM using RCWs (runtime-callable wrappers), otherwise known as "interop assemblies". .NET applications (actually, only those languages supporting it; CLS-compliant only (like JScript.NET) will not) can also P/Invoke native functions. The problem with that - unless you're using global memory in your native system hook DLL - is that you're not accessing that instance. You should use either global memory (which .NET could actually access itself instead of P/Invoking native functions, although that would make for a clean, self-contained design) or some sort of IPC to communicate with your native and managed code. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
Without any more details than that, it's impossible to help you. What was the exact error? Debug your application (if you're using VS.NET, you should be prompted to attach a debugger) and find out what the offending code is, as well as the exception. That, too, could be greatly beneficial to us when trying to help you. A word of extreme caution: global system hooks are dangerous. Write clean, efficient, error-handling code that does what it needs quickly. Managed code isn't already the best idea for this (at the very least, there is a performance penalty for marshaling between native and managed code), but it is possible. As far as using a native DLL (which I recommend for the reason I gave above), yes you can use it. The question is how. .NET can interoperate with COM using RCWs (runtime-callable wrappers), otherwise known as "interop assemblies". .NET applications (actually, only those languages supporting it; CLS-compliant only (like JScript.NET) will not) can also P/Invoke native functions. The problem with that - unless you're using global memory in your native system hook DLL - is that you're not accessing that instance. You should use either global memory (which .NET could actually access itself instead of P/Invoking native functions, although that would make for a clean, self-contained design) or some sort of IPC to communicate with your native and managed code. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
The hook worked fine globally with keyboard and mouse hooking. Once i set the hooking type to WH_CBT and run the code: at first the app runs normally...my cbt procedure seems to receive messages normally when I open new windows inside my app's thread. Once I give the focus to a window outside the app, the command prompt black (ugly btw) screen pops giving a message title: Microsoft Common Language Runtime Minidump Utility (with no error message whatsoever) and the system freezes for a while, before closing VS.NET and the app itself (i'm running it in debug mode of course). I was wondering what the problem could be...if it had run smoothly with keyboard/mouse hooks...why is it only with the WH_CBT that I get the hard things? I've tried to implement the same code in C++ and again, it ran smoothly with keyboard/mouse hooks, yet with CBT it gives the same trouble, although I had unset /clr and the code was supposed to be unmanaged...still the CLR Minidump Utility ruins the thing...why is that?
-
The hook worked fine globally with keyboard and mouse hooking. Once i set the hooking type to WH_CBT and run the code: at first the app runs normally...my cbt procedure seems to receive messages normally when I open new windows inside my app's thread. Once I give the focus to a window outside the app, the command prompt black (ugly btw) screen pops giving a message title: Microsoft Common Language Runtime Minidump Utility (with no error message whatsoever) and the system freezes for a while, before closing VS.NET and the app itself (i'm running it in debug mode of course). I was wondering what the problem could be...if it had run smoothly with keyboard/mouse hooks...why is it only with the WH_CBT that I get the hard things? I've tried to implement the same code in C++ and again, it ran smoothly with keyboard/mouse hooks, yet with CBT it gives the same trouble, although I had unset /clr and the code was supposed to be unmanaged...still the CLR Minidump Utility ruins the thing...why is that?
Hadi Fakhreddine wrote: Once i set the hooking type to WH_CBT and run the code... I hope - and assume - that you're not just registering the same hook proc with a different type. Perhaps a little code snippet of your
CBTProc(or however you defined your delegate and the handler) would be handy. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
Hadi Fakhreddine wrote: Once i set the hooking type to WH_CBT and run the code... I hope - and assume - that you're not just registering the same hook proc with a different type. Perhaps a little code snippet of your
CBTProc(or however you defined your delegate and the handler) would be handy. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]I'm using cutting edge's code from MSDN Mag found here http://msdn.microsoft.com/msdnmag/issues/02/10/CuttingEdge/ [^] He uses the code for a local hook, I used it for system-wide by just changing from
m_hhook = SetWindowsHookEx( m_hookType, m_filterFunc, IntPtr.Zero, (int) AppDomain.GetCurrentThreadId());tom_hhook = SetWindowsHookEx( m_hookType, m_filterFunc, Marshal.GetHINSTANCE(Assembly.GetExecutingAssembly().GetModules()[0]), 0);I kept the CBTProc the same as is...