SetWindowsHookEx不能直接注入任意进程，仅对运行消息循环的GUI线程生效，且钩子函数必须位于DLL中由系统自动加载；WH_GETMESSAGE/WH_CALLWNDPROC因触发频繁被常用，但受权限、位数匹配及DllMain限制约束。
SetWindowsHookEx 进程注入的核心限制
不能直接用 SetWindowsHookEx 注入任意进程的地址空间——它只对**消息循环线程**生效，且要求钩子过程必须位于 DLL 中，由系统在目标线程上下文里加载并调用。这意味着：你无法靠它把代码塞进一个没开消息循环的后台进程（比如纯计算型服务进程），也不能绕过 DLL 载入机制直接写入内存执行。
为什么 WH_GETMESSAGE/WH_CALLWNDPROC 钩子常被选中
这两类钩子触发频率高、适用范围广，且只要目标线程调用 GetMessage 或 PeekMessage（绝大多数 GUI 线程都这么干），就会强制加载你的 DLL。但注意：WH_KEYBOARD 和 WH_MOUSE 在 Windows Vista+ 默认只作用于本进程，除非以管理员权限调用 SetWindowsHookEx 并设置 dwThreadId = 0，否则跨进程无效。
-
WH_GETMESSAGE：钩在GetMessage/PeekMessage返回前，适合拦截/修改消息 -
WH_CALLWNDPROC：钩在窗口过程被调用前，能拿到完整MSG和WNDPROC参数，但不支持低权限进程向高权限进程设钩 - 64 位系统下，32 位进程不能给 64 位进程设钩，反之亦然——
SetWindowsHookEx会静默失败，返回NULL
DLL 入口点（DllMain）里不能干的事
钩子 DLL 的 DllMain 是注入后第一个执行点，但它运行在 loader lock 下，很多 API 会死锁或崩溃：
- 禁止调用
CreateThread、WaitForSingleObject等同步等待函数 - 禁止调用
LoadLibrary（可能引发递归加载）、FreeLibrary - 禁止使用 C++ 全局对象构造器（如
std::string、std::vector静态实例），它们依赖未就绪的 CRT - 推荐做法：在
DllMain里只做最简初始化（比如保存hInstance），用PostThreadMessage或创建挂起线程 +ResumeThread启动真正逻辑
常见失败原因和调试线索
如果 SetWindowsHookEx 返回 NULL，别急着改代码，先查这几项：
立即学习“C++免费学习笔记（深入）”；
- 确认 DLL 路径不含 Unicode 路径名（尤其是中文），
SetWindowsHookEx的lpLibModuleName必须是 ANSI 字符串，且路径需存在、可读 - 检查目标线程是否真的在跑消息循环——用
GetGUIThreadInfo查dwFlags & GUI_INMOVESIZE只是辅助，更可靠的是用 Process Explorer 看线程堆栈里有没有USER32!GetMessage* - 错误码是
ERROR_ACCESS_DENIED？多半是权限不匹配（比如当前进程没管理员权限却想钩系统级窗口）或 32/64 位不一致 - 钩子“突然失效”？可能是目标进程调用了
UnhookWindowsHookEx，或你的 DLL 被提前卸载（比如FreeLibrary被误调，或引用计数归零）
真正难处理的是钩子 DLL 生命周期和线程亲和性——它不是一次性的，而是随目标线程存续；一旦线程退出，系统自动卸载 DLL，但若线程长期存活，DLL 就一直占着内存，且无法安全卸载。
