SetWindowsHookEx failing in .NET 4.0 on 32-bit machine with “module not found”?

Question

I have found similar questions on this page, but I can\'t seem to figure out how to interpret the answers or figure out if they are truly duplicates.

Here are the pos

Answer 1

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

Answer 2

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;
        }
    }

Answer 3

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.