问题标签 [wow64]

正如这里提到的，这个组件成为了windows操作系统的一部分。但是，Windows 8 及更高版本可能不支持 VB6 运行时。所以我担心这个组件也可能会消失（即使它是 Windows 操作系统的一部分）。我们将很快尝试通过 C# 消费者使用 Interop.MSScriptControl.dll 来使用它。我什至看到有些人在Windows7上遇到了问题。有没有人在 Windows 7 和 Windows Server 2008 R2 上成功运行过它？有人认为它仍然可以在 Windows 8 上运行吗？目前正在为 x86 32 位 CPU 编译，并认为 64 位系统将使用 WoW64 来使用它。谢谢！

更新：微软尚未在 Windows 8.1 中修复它。

编辑：这原来是 WOW64 中的一个错误- 当线程在长模式 ring-3（用户模式）中挂起时，GetThreadContext() 可能会返回陈旧的内容。我建议微软使用 ring-2 来执行翻译。然后，SuspendThread 只会挂起 ring-3 中的线程（就像现在一样 - 无需更改），并且 ring-2 中的崩溃/故障/利用不会影响内核 - 它只会影响 ring-2 和 ring- 3.

此类更改将需要更改一些 WinAPI 函数，例如 Wow64Get/SetThreadContext 等。这会破坏依赖于未记录功能的应用程序，但这是可以预料的。当然，翻译会更慢，因为从 ring-3 过渡到 ring-2 需要几个 CPU 周期（取决于 CPU 系列），但我认为操作系统的作用首先是确保正确操作。翻译已经增加了在 WOW64 下运行的应用程序的开销，所以这也是意料之中的。

我确实希望微软能解决这个问题——否则调试器/Mono 应用程序/Boehm GC/在 WOW64 下依赖 GetThreadContext() 的应用程序将无法工作（对于初学者，我已经看到调试器显示过时的堆栈跟踪）。

EDIT2：坏消息。从我与来自 MSFT 的 Alexey 的对话（这里）看来，它可能根本无法修复，因为担心修复会破坏依赖于未记录功能的应用程序。

原始问题

• 有些人似乎对以下内容感到困惑。我最初认为这是由于 SuspendThread 在内核模式代码中挂起线程。不是。以下只是我最初的怀疑，结果与实际根本原因无关 - 这是由返回的陈旧内容GetThreadContext()。

来自 MSDN：

Suspending a thread causes the thread to stop executing user-mode (application) code.

然而，我发现我在 Windows 7 中的 32 位应用程序在 WOW64 下运行，线程 A 在线程 B 上调用 SuspendThread 可以在它运行 64 位代码时暂停它（我希望这不是用户模式代码）。EIP 显示挂起的线程停止在

其 ESP 已更改（我知道这是因为，虽然 ESP 指向与该线程堆栈相同的页面，但它的地址比当前堆栈指针高得多）。如果我在上面返回的指令处设置断点，然后让线程恢复，我发现 ESP 变回 X86SwitchTo64BitMode 调用之前的值（这是正确的堆栈指针）。我还发现，当单步进入同一个函数时，我永远无法在单步的任何时候获得更高的地址 ESP 值。事实上，单步执行时，ESP 值在 X86SwitchTo64BitMode 调用前后从未改变。

另外，我确实通过检查 (DWORD)-1 来确保 SuspendThread 成功。

所有这些让我相信线程在内核模式代码中被挂起。

什么可能导致操作系统在运行非用户模式代码时挂起线程？我该如何防止呢？这基本上阻止了我获取线程 B 的实际当前堆栈指针。请注意，当应用程序在 WOW64 之外（在本机 x86 操作系统上）运行时，不存在此类问题。

请进行健全性检查。我听到的解决方案听起来很糟糕，但可能是唯一的一个。

从我正在运行的 .hta over .vbs 应用程序中

它在 CLI 中运行良好，但在我的小应用程序中却失败了。这是因为我在一个 64 位机器上，并且我对 c:\Windows\System32 的调用被重定向到 c:\Windows\SysWow64，iisapp.vbs 脚本不驻留在那里。将脚本移到那里会导致 Microsoft.CmdLib 抱怨需要注册。这一切都是可以理解和理解的。

其他论坛推荐的解决方案是将regsvr32 IIsScHlp.wsc和cmdlib.wsc复制到SysWow64。

这行得通，但似乎有点笨拙。这种解决方案可能会产生无法预料的副作用吗？没有比将这些文件重新注册到 Wow64-land 更直接的解决方案吗？

谢谢。

我已经看到一些由我编写并使用 ml.exe 为 x86 组装的程序在我的 Win 7 x64 上运行良好。我相信这是因为哇技术。

但是，有些程序（不是我写的）无法运行。他们给出的错误是： 此文件的版本与您正在运行的 Windows 版本不兼容。检查您的计算机系统信息，看看您是否需要 x86（32 位）或 x64（64 位）版本的程序，然后联系软件发行商

有什么办法可以修改这些程序的 EXE 以使其在 Win 7 x64 上运行。这些程序的根本区别是什么，使其与其他透明运行的程序不同。

尝试在 WinPE 3.0 (Win7) 64 位环境中运行任何 32 位应用程序将导致以下错误消息：

The subsystem needed to support the image type is not present.

缺少的子系统是 Windows on Windows 64 (WOW64)：允许 32 位应用程序在 64 位操作系统中运行的兼容层。

问题是：是否可以在 WinPE 中安装 WOW64？如果是这样，要安装的文件集如何以及有多大？

谢谢你。

我使用 freetype2(2.3.9) 构建了一个 tff 到 D3D 纹理函数，以从字体生成灰度图。它在本机 win32 下运行良好，但是，在 WoW64 上它只是爆炸（好吧，FT_Done确实FT_Load_Glyph如此）。从一些调试来看，这似乎是由fromHeapFree调用的问题。freeFT_Free

我知道它应该可以工作，因为像 WCIII 这样的游戏，据我所知使用 freetype2，运行良好，这是我的代码，去掉了 D3D 代码（它本身不会导致问题）：

ARCHIVE_LoadFile返回用 分配的块new。

作为第二个问题，我想使用像素大小渲染字体FT_Set_Pixel_Sizes，但我不确定这是否会拉伸字体以适应大小，或者将其限制为大小。我想做的是将所有字形渲染为 24 像素（此处为 MS Word 大小），然后将其转换为 32 像素区域中的有符号距离场。

更新

经过一番折腾，我得到了一个测试应用程序，这让我认为问题是由线程引起的，因为我的代码在辅助线程中运行。我已经使用多线程 DLL 将 freetype 编译成静态库，我的应用程序使用多线程库。看看我是否可以设置一个多线程测试。

还更新到 2.4.4，以查看问题是否是已知但已修复的错误，但无济于事。

更新 2

经过一番摆弄，事实证明我没有为 2.4.4 使用正确的库 -.- 修复该问题后，测试应用程序 100% 工作，但主应用程序在FT_Done_Face被调用时仍然崩溃，似乎仍然是崩溃在windows的内存堆管理中。freetype2 中是否有可能导致它在用户线程下爆炸？

如果 Web 应用程序的页面编译为 PE 32/x86，我需要知道部署在 64 位服务器中的 Web 应用程序是作为 WOW64 进程运行还是作为 64 位进程运行？

我的意思是我已经阅读了很多关于在 64 位服务器上运行为 WOW64 的 PE 32/x86 的普通控制台应用程序或可执行文件。但是 Web 应用程序呢（我只能编译 dll 的页面）？我能想到的唯一进程是用于 Web 应用程序的 w3wp.exe。请解释。我很困惑。

提前致谢

藤蔓

我在这里阅读了有关 WOW 64 的信息 http://en.wikipedia.org/wiki/WOW64

并了解到它是 64 位 Windows 操作系统中运行 32 位程序的一层。

所以我可以假设 32 位程序在 64 位操作系统上运行相对较慢，而不是它们在 32 位操作系统中本机运行。

我可以看到在 64 位操作系统中超过 4 GB 的内存访问的优势。但是这种优势是否一定会抵消 WOW64 层增加的小开销？64位是否还有其他优势可以抵消这一点。

使用 delphi 创建 32 位应用程序我无法访问所有配置单元，具体取决于应用程序是在 win32 还是 win64 Windows 机器上运行。这是默认访问的链接：http: //msdn.microsoft.com/en-us/library/aa390789 (v=VS.85).aspx

我只想创建一个应用程序，而不是 32 和 64 的单独版本。我想使用 WMI 并从 32 位注册表配置单元、64 位注册表配置单元和 WOW6432Node 中检索信息。有要设置的标志，但我不知道如何通过我的 delphi 应用程序的常规 WMI 查询调用发送标志。以下是有关 FLAG 的信息：http: //msdn.microsoft.com/en-us/library/aa393067 (v=VS.85).aspx

GLibWmi 和 DelphiWmiCodeCreator 示例：

修订后的代码：

我正在尝试构建一个可以在 64 位 Windows 上正确运行的 32 位程序；也就是说，如果它需要为用户打开一个文本文件，该文件不需要被重定向C:\Program Files到C:\Program Files (x86). 但是，如果我只是调用Wow64DisableWow64FsRedirection，那么我的程序根本无法加载，因为在LoadLibrary加载部分 GUI 时会调用一些系统库，这会尝试将 64 位版本的系统 DLL 加载到我的程序中。

我该如何解决这个问题？

编辑：

请参阅下面的屏幕截图中的问题：

编辑2：

这是另一个可以解决问题的问题：有没有办法为您的进程中的任意线程或整个进程禁用 WOW64 重定向？