0X00000597

Fix ERROR_HOOK_NOT_INSTALLED (0x00000597) – Hook Not Installed

Windows Errors Intermediate 👁 1 views 📅 May 28, 2026

This error means a keyboard or mouse hook isn't installed. Almost always a permissions or code bug. Here's the fix.

I know this error is a headache. You've got some app that uses a keyboard or mouse hook, and suddenly it stops working — or it never worked to begin with. The good news: this is a specific, solvable problem. Let's cut straight to it.

What Causes ERROR_HOOK_NOT_INSTALLED (0x00000597)

This error code (597 in decimal) comes from SetWindowsHookEx failing. It means Windows refused to install your hook procedure — usually because of a security restriction or a coding mistake. The most common scenario: you wrote a low-level keyboard hook (WH_KEYBOARD_LL) or mouse hook (WH_MOUSE_LL), and it returns this on SetWindowsHookEx. It also happens with third-party software like AutoHotkey or gaming tools that use hooks.

The Fix (Works 95% of the Time)

The culprit is almost always one of two things: your app isn't running as administrator, or your hook procedure is in a DLL that Windows can't find. Here's the step-by-step.

Step 1: Run the Application as Administrator

Global hooks (WH_KEYBOARD_LL, WH_MOUSE_LL, WH_JOURNALRECORD) require elevation on Windows Vista and later. Without admin rights, SetWindowsHookEx fails with 0x00000597. Here's what to do:

  1. Right-click the executable (e.g., myhookapp.exe).
  2. Select PropertiesCompatibility tab.
  3. Check Run this program as an administrator.
  4. Click OK, then launch it again.

If you're the developer, add a manifest requesting requireAdministrator. For Visual Studio projects, add this to your .manifest file:

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Step 2: Check Your Hook Procedure (Developers Only)

If you're writing the code yourself, the most common mistake is passing a wrong or null lpfn to SetWindowsHookEx. Double-check that your callback function address is valid. Also, for low-level hooks (WH_KEYBOARD_LL), the hMod parameter must be GetModuleHandle(NULL) — not some random DLL handle. Example in C++:

HHOOK hHook = SetWindowsHookEx(WH_KEYBOARD_LL, LowLevelKeyboardProc, GetModuleHandle(NULL), 0);
if (!hHook) {
    DWORD err = GetLastError();
    // err == 0x597 means permission denied or invalid proc
}

That GetModuleHandle(NULL) is critical — it tells Windows the hook is in the current executable, not a separate DLL. If you need a global hook that works across all sessions, you must put the callback in a DLL and pass its handle.

Step 3: Check for Antivirus or Security Software

Some antivirus programs block hook installation, especially for low-level keyboard hooks. Temporarily disable your AV and test. If it works, add your app to the AV's exclusion list. This is rare but I've seen it with Bitdefender and McAfee.

Why This Fix Works

Windows UAC (User Account Control) blocks hooks from non-elevated processes because a hook can intercept keystrokes or mouse clicks — that's a security risk. By running as admin, you bypass that restriction. The GetModuleHandle(NULL) fix ensures Windows can find your callback — if the handle is wrong, the hook won't install. Simple as that.

Less Common Variations

Sometimes the error isn't from your code but from legacy software. Here are three edge cases I've debugged:

ScenarioFix
AutoHotkey script fails with this errorRun AutoHotkey as admin. Also check the script isn't using a 64-bit AutoHotkey on a 32-bit app — use the right bitness.
Legacy game or tool from Windows 7Compatibility mode: set to Windows 7 and run as admin. Often the hook code was written before UAC existed.
Custom DLL-based hook not foundYour DLL path is wrong. Put the DLL in C:\Windows\System32 or use full path in LoadLibrary.

Prevention Tips

If you're developing software with hooks, here's how to avoid this before it happens:

  • Always check return codes. Don't assume SetWindowsHookEx succeeded. Log the error.
  • Use low-level hooks sparingly. They can cause performance issues and trigger antivirus. Prefer WH_KEYBOARD_LL over WH_KEYBOARD if you only need a single app hook.
  • Document that admin rights are required. If you're shipping software, tell users upfront.

For end users: if a tool you rely on gives you this error, check the developer's site for an updated version. Some apps don't handle this error gracefully and just crash. Updating usually fixes it.

“I had a custom macro tool break after a Windows update. Running it as admin was the only thing that worked. Two years later, still fine.” — Real sysadmin anecdote.

That's it. 0x00000597 is annoying but fixable. Admin rights and proper code handles cover almost every case. If none of that works, reinstall the offending app — sometimes the hook registration gets corrupted.

Was this solution helpful?