问题标签 [wow64]

我有一个在 win7 x64 上调试的小型 32 位进程，我看到它按预期加载了 "C:\windows\sysWow64\ntdll.dll" ，但也加载了 "C:\windows\system32\ntdll.dll" 。
我知道 x64 模块和 x86 模块不能混用，但他们在这里……混用……
怎么可能？

在一段时间之前，我编写了自己的小型数据库编辑器程序，我使用 Win API 从零开始对其进行编码，因此它不是非常小的项目。到目前为止，它在所有操作系统上都运行良好，我有 Win 7 x64 和所有最新更新，我的应用程序由于某些堆函数（HeapAlloc 或 HeapFree，我什么都不用）而崩溃，出现 0xC000005 异常，我尝试替换 HeapAlloc &带有 VirtualAlloc 和 VirtualFree 的 HeapFree 一切都很好，但我不想使用虚拟内存.... 别的，我试图附加调试器来跟踪问题，但是当我附加调试器时它没有崩溃，然后我尝试了显示 MessageBox 以跟踪它崩溃的位置，但是当我显示 MessageBox 时它也没有崩溃......

我的应用程序作为 32 位进程运行。用 C 编码。

有人有类似的问题吗？

我们在 2 个应用程序之间有一个自动化场景（主要是 MSUIA），目标是 32 位，我的应用程序（自动化应用程序）是 64 位，在 64 位 win7 上。一些需要共享的信息必须通过 direkt Win SDK 调用（如 SendMessage、GetFocus 等）来访问。

根据我现在的理解，Win64 和 32 子系统是完全独立的，因此任何此类交互都应该立即失败（例如尝试通过 64 位应用程序访问 32 位应用程序的某些部分）。奇怪的是，大多数东西似乎都可以正常工作。所以似乎有某种编组/内部的任何东西。

不过，我现在遇到了一些情况，我定义 p/invoke 函数的方式似乎存在问题。我已经宣布它们是“官方的 MS 方式”，只要有东西可能改变大小（也使用很棒的http://www.pinvoke.net/default.aspx/站点），所以我强制我的 .net 应用程序成为64 位（使用编译开关），它们应该使用 64 位版本的 dll 编译为 64 位。

现在奇怪的是，当使用这些调用访问 32 位应用程序时（例如 GetWindowText，它实际上从另一个进程的内存中读取）这些调用似乎工作正常。但。随后的 MSUIA 调用似乎随机失败。

如果我（错误地）为 p/invoke 调用声明了 32 位签名，即使编译为 64 位，一切都运行良好。

对我来说，这没有任何意义。

最干净的解决方案可能是将我的应用程序也编译为 32 位（或与目标应用程序相同），但仍然......我将不胜感激任何对此的见解。

简单的问题，但是是否有一个 win32 API 调用来检索进程句柄是否具有PROCESS_QUERY_INFORMATION访问标志以便成功调用IsWow64Process？AccessCheck 功能 - MSDN似乎可以工作，但我不确定这是否在检查相同类型的标志。

目前我正在玩被称为“天堂之门”的 windows/WOW64 技巧，正如你们中的一些人可能知道的那样，即使在 x86 程序中，它也允许我们进入 x64 模式（当我测试它时我很惊讶它有效！）但我知道它不受所有 Windows 版本的支持，所以我的代码（因为有代码）使用 seh，它看起来像这样：

我知道一个简单的“jmp .exit”可以解决问题，但我对此非常好奇

可能重复：
C# - 如何在 Windows Vista 64 位上获取程序文件 (x86)

我正在尝试从我自己的第三方程序中启动。我在Program Filesand中进行了快速搜索Program Files (x86)，我刚刚意识到返回的路径getenv("ProgramFiles")实际上取决于我是在 x64 还是 Win32 中运行。

如何使用环境变量而不是硬编码名称搜索（在 C++ 和 C# 或 VB.NET 中）两个 Program Files 文件夹 - 因为无论我在用户计算机上运行的程序版本如何，用户都可能拥有另一个一个安装在不同的版本？

我现在的代码：在 C++ 中：

在 VB.NET 中：

我看了这个来源：http: //msdn.microsoft.com/en-us/library/aa365743

但是如果我实现他们所说的，我会一直得到 x86 ......

我有自己的安装程序，我用它来安装我编写的几个应用程序。

我一直在更新这个程序以避免应用程序的数据文件更新进入用户的 VirtualStore，因为我读到这是一件“坏事”。我通过将程序和通用数据文件分别存储在正确的位置来做到这一点，而不是像 XP 时代那样将所有内容都粘贴在 Program Files 中。

我现在也在使用 SHGetFolderPath （是的，它已被弃用，但我仍然需要支持我的 XP 用户）来获取已知文件夹而不是拖网注册表，这是另一个“坏事”（我读过）。

我尝试做的下一件事是重写安装程序代码，以避免在向 HKLM 写入内容时将注册表重定向到 Wow6432Node，因为我认为这是另一个“坏事”。

然而，虽然我可以把应用程序特定的东西放在那里（比如安装文件夹，如果用户决定安装默认值以外的地方），杀手是需要把卸载信息放在 HKLM\Software\Microsoft\Windows \CurrentVersion\卸载。对于在 64 位系统上运行的 32 位内容，它被重定向到 Wow6432Node。我看不出有什么办法——这实际上可能吗？

我在这里没有想法了。我有一段改编自http://thetechnofreak.com/technofreak/keylogger-visual-c/的代码，用于将键码转换为 unicode 字符。它在所有情况下都可以正常工作，除非您尝试从 64 位 Windows 运行 32 位版本。出于某种原因，pKbd->pVkToWcharTable 一直返回 NULL。我已经尝试过 __ptr64 以及为 kbd dll 路径明确指定 SysWOW64 和 System32。我在互联网上找到了几个提到这个确切或非常相似的问题的项目，但我似乎无法让任何解决方案起作用（参见：KbdLayerDescriptor 在 64 位架构中返回 NULL) 以下是我在 Windows XP (gcc -std=c99 Wow64Test.c) 上使用 mingw-32 编译然后在 Windows 7 64 位上执行的测试代码。在 Windows XP 上，我得到了一个有效的指针，但是在 Windows 7 上，我得到了 NULL。

***更新：所以看起来我遇到的问题是由于 mingw 没有正确实现 __ptr64 因为 sizeof 操作给出了 4 个字节而不是 Visual Studio 给出的 8 个字节。所以真正的解决方案是想办法使 KBD_LONG_POINTER 的大小动态或至少为 64 位，但我不确定这是否可能。有任何想法吗？

我正在尝试在 c# 中使用 Microsoft.Win32.RegistryKey 插入一些简单的注册表项，但路径会自动更改为：

到

我尝试了谷歌，但我只得到一些模糊和令人困惑的结果。以前有人处理过这个问题吗？一些示例代码将非常受欢迎。

我的 32 位应用程序在 64 位 Windows 7 上运行。我正在尝试访问注册表HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall。我可以在 regedit 中看到Uninstall默认 64 位注册表视图中的键下方有几个子键（Dropbox 在该位置创建一个键，以及 Google Chrome）。Uninstall但是，在 32 位注册表视图中确实没有键。实际上，在 regedit 下面只有一个Active Setup键HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft。下面甚至没有Windows子键Microsoft。

但是，当我的 32 位应用程序尝试访问 32 位注册表视图时HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall，我会从 64 位视图中获取密钥。这是为什么？

即使是标志KEY_WOW64_32KEY在这里也无济于事。我们的代码需要知道结果是来自 32 位视图还是 64 位视图。

我们的代码还可以访问密钥的 32 位和 64 位视图，HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall我在那里看不到这个问题。不同之处在于 HKLM 的 32 位视图有Uninstall密钥，而 HKCU 的 32 位视图没有。

我知道 WoW64 的注册表重定向，但这似乎不同。我在 MSDN 上找不到任何有用的信息。有人可以对此有所了解吗？