SetWindowsHookEx failing in .NET 4.0 on 32-bit machine with "module not found"?
Yup, I think you understand what's going on. SetWindowsHookEx() requires a valid module handle, and verifies it, but it doesn't actually use it when you set a low-level hook. You just need a valid handle, it doesn't matter which specific one. Calling LoadLibrary("user32.dll") is a good way to get a handle, that DLL will always be loaded anyway since you P/Invoke its methods. And it is always loaded by the CLR bootstrapper (mscoree.dll). Don't bother calling FreeLibrary(), it makes no difference.
Later versions of Windows no longer perform this check. Not exactly sure when that started, somewhere around Windows 7 SP1 I think. Probably meant to be helpful but invokes the "works on my machine, not the customer's" failure scenario.
Here is my solution that works both in .net 2 and 4. hInstance is ProcessModule.BaseAddress.
public static class ModuleHelper
{
public static ProcessModule GetCurrentModule()
{
// need instance handle to module to create a system-wide hook
Module[] list = System.Reflection.Assembly.GetExecutingAssembly().GetModules();
System.Diagnostics.Debug.Assert(list != null && list.Length > 0);
var currentProcess = Process.GetCurrentProcess();
var modules = currentProcess.Modules;
ProcessModule mod = null;
foreach (ProcessModule m in modules)
//for .net 2 we will find module here
if (m.ModuleName == list[0].Name)
{
mod = m;
break;
}
//for .net 4 take current module
if (mod == null)
mod = Process.GetCurrentProcess().MainModule;
return mod;
}
}
In .Net 4.0 for this code to work I had to replace the call:
SetWindowsHookEx(WH_KEYBOARD_LL, _Hook, moduleHandle, 0);
with:
SetWindowsHookEx(WH_KEYBOARD_LL, _Hook, IntPtr.Zero, 0);
this fixed the problem ,This works when the call is made from the same module.
I got this from here