我正在使用代理DLL来拦截对CreateWindowExA/CreateWindowExW的调用。这很好用，除了一些应用程序（最值得注意的是一些Visual Basic 6应用程序）似乎能够在不通过这两个函数中的任何一个的情况下创建窗口。像Spy++这样的工具能够显示窗口，但我的钩子函数没有注意到它们。
我的第一个怀疑是，也许这些（旧）应用程序使用 CreateWindowA/CreateWindowW 来创建窗口，但至少使用我的编译器（MSVC6 到 MSVC10），CreateWindow只是一个 #define;文档的备注部分证实了这一点。
我的第二个想法是，我可以使用SetWindowsHookEx安装一个CBT hook来检测Windows的创建。但是，结果是相同的：这个钩子注意到与我的钩子 API 函数相同的窗口，但它没有注意到 Spy++ 中可见的所有窗口。
所以我的问题是：是否有一段时间CreateWindowA/CreateWindowW不是 #define，而是真正的功能？这个函数是否仍然由user32.dll导出，也许是出于兼容性原因？如何掌握此函数以挂接它？
或者是否有其他一些可能未记录的函数可用于创建函数，就像例如 NtCreateProcess可以代替CreateProcess？
三个简单的猜测：
1）VB应用程序是否有可能真的在后台调用"DialogBox"API（例如DialogBoxParam，CreateDialogIndirect等）？
2） 您正在运行 64 位操作系统并挂接 64 位用户32.dll。 因此，32 位应用程序不会上钩。 在 c：\windows\syswow64 中有一个 user32.dll 的 32 位副本
3）您没有吸引用户32.dll应用程序正在使用。 许多较旧的应用程序可能会获得一些 DLL 重定向。 在命令提示符下，从 c：\windows\winsxs 目录中执行"dir/s user32.dll"。您将在此处看到至少一个 user32 的其他副本.dll。 忘记这种情况何时发生，但您可以必应"winsxs"并获得一些页面讨论并排目录如何解决较新的Windows操作系统版本的兼容性问题。
我怀疑#3是您问题的原因。
您的问题可能是VB应用程序正在使用GetProcAddress（）来调用CreateWindow**（）函数。如果你挂上了GetProcAddress，你应该能够确认这一点。