Windows下是否存在全局Hook CreateWindow/CreateProcess的优质方案？

完全不需要给每个进程单独挂载Hook，系统原生提供了多种低侵入、高稳定性的实现路径，开销和兼容性都远好于逐进程注入的方案，按适用场景排序如下：

• 首选用户态方案：WinEvent全局事件钩子
  直接在你的监控进程内调用SetWinEventHook接口，注册时传入EVENT_OBJECT_CREATE事件和WINEVENT_OUTOFCONTEXT标志即可，不需要向任何目标进程注入DLL，所有回调逻辑都在你自己的进程地址空间内执行。
  事件触发时回调参数会直接返回新创建对象的窗口句柄，你只需要过滤掉非顶层窗口、非可见窗口的无效事件，拿到有效HWND后调用GetWindowThreadProcessId获取对应进程PID，再通过QueryFullProcessImageName接口就能拿到对应的进程名、完整可执行文件路径。
  这个方案是系统原生支持的全局监听能力，响应延迟在毫秒级，不会触发杀软的注入类告警，也不会因为监控逻辑问题导致目标进程崩溃。
• 高对抗场景方案：内核态回调订阅
  如果你做的是安全类工具，需要对抗目标程序的反Hook手段，可以写内核驱动注册PsSetCreateProcessNotifyRoutineEx进程创建回调，第一时间拿到所有新启动进程的PID、进程名、路径信息，再在用户态通过窗口枚举关联对应进程的首个顶层窗口即可。
  这个方案的监控层级在系统内核，普通用户态程序无法绕过，缺点是需要解决驱动签名问题，开发复杂度更高。
• 极简兜底方案：窗口枚举差量对比
  如果不想处理任何钩子注册逻辑，可以在程序里维护一个已知顶层窗口的哈希表缓存，每隔200-500毫秒调用EnumWindows枚举当前所有可见的顶层窗口，把枚举结果和缓存做差集，差集中的窗口就是新打开的窗口，后续查询进程名的逻辑和前面的方案一致。
  这个方案代码量极小，完全不需要调用任何Hook相关接口，缺点是存在最高几百毫秒的响应延迟，不适合对实时性要求高的场景。

逐进程挂载Hook的方案天生存在几个硬伤：一是需要持续监控进程创建事件反复注入，逻辑冗余复杂；二是跨进程注入DLL的行为非常容易触发安全软件的主动防御拦截；三是注入的代码如果存在bug，会直接导致被注入的目标进程崩溃，兼容性极差。上述几个方案都完全规避了这些问题。

内容的提问来源于stack exchange，提问作者user19021341