（在尝试了David Heffernan的建议后更新）
我有一个旧版Win32本机应用程序（Delphi 6），该应用程序在HKEY_LOCAL_MACHINE \ Software \\键下将值写入注册表。稍后，其他一些旧版Win32本机应用程序和一个新的.NET应用程序将读取这些值。.NET应用程序是基于AnyCPU构建的，因此将作为64位映像执行。因为它使用的是32位应用程序编写的配置，所以.NET软件会将其注册表读取重定向到Win32 API应用程序实际写入的Wow6432Node。
没有一个应用程序运行提升。所有应用程序都是交互式的。用于运行应用程序的帐户具有对HKEY_LOCAL_MACHINE \ Software \\注册表项及其子项的显式“完全控制”。
据我所知，这不是在使用注册表虚拟化，因为32位应用程序对其写入的HKLM密钥具有写访问权。
这种情况在64位Windows 7和64位Windows 8计算机上都可以正常运行，但是在新的Windows 8.1 64位计算机上，所有设备都无法正常工作。
虽然旧版Win32应用程序无误地写入注册表，但现在看来已在虚拟化。可以通过查看用户虚拟注册表项来确认。我在那里看到所有书面价值。
当我用REGEDIT查看HKEY_LOCAL_MACHINE \ Software \\密钥时，我写的大约一半的密钥只是从HKEY_LOCAL_MACHINE \ Software \\中丢失了，但都存在于虚拟文件夹中。
据我了解，具有写入权限的32位应用程序应该没有虚拟化，但是有。更糟糕的是，当我读取非虚拟化密钥时，我看到了写入虚拟化存储的一些但不是全部值。
为什么它突然使写操作虚拟化，为什么当我读取原始密钥时读操作不会显示所有虚拟化值（即，虚拟读操作无法按预期工作）？
我认为这一定是一个权限问题，就像我以“以管理员身份”运行该应用程序一样，所有的密钥都在那里。但是，不允许以升高的速度运行最终配置。
更新资料
我清除了这台计算机上的所有注册表设置。既在HKCU下的虚拟商店中，又在HKLM下的共享区域中。然后重新开始，不运行提升。这引起了类似的症状，但是这次我只看到HKLM密钥中的一个密钥。
我打算编写一个Win32应用程序来枚举HKEY_LOCAL_MACHINE \ Software \\键，以防万一我被regedit.exe欺骗，或者在64位OS上运行时对我不起作用，并且当我收到来自那。在旧版32位WinAPI应用程序和新版64位应用程序之间存在虚拟化不匹配的问题。有关详细信息，请参见我的答案。
注册表的虚拟化在Windows 8.1中的工作原理与在Vista，Win7和Win8中的工作原理相同。没有可以解释您报告内容的更改。
您是否知道虚拟化是7年前在Vista中引入的，以帮助无法修改的应用程序在UAC上工作。这个想法是，您修复应用程序以了解UAC，并停止运行虚拟化程序。
关于虚拟化的事情是，如果您以标准用户身份运行，您的应用程序将写入虚拟存储。但是，如果您执行提升权限的应用程序，则该应用程序将写入注册表的共享部分HKLM。从上面的描述中，您似乎已经提升了应用程序的运行速度，并且已向HKLM虚拟存储区而不是虚拟存储区写入了值。
我建议您清除此计算机上的所有注册表设置。既在虚拟商店下HKCU，又在共享区下HKLM。然后从您的应用程序重新开始，而不是提升运行。我相信它的工作方式与以前的版本相同。
但是，令我惊讶的是，您仍在尝试使用虚拟化作为功能。帮助无助的人是拐杖。不要无助。停止虚拟化运行。摆脱虚拟化。
更新资料
您的问题编辑完全改变了这一点。实际上，您并不是在问Windows 8.1与早期版本之间的差异。您正在Windows 8.1机器上运行另一个程序，该程序是64位。而且64位进程从未虚拟化。
我再次重申我的建议，即不要以您的方式使用虚拟化。以这种方式依赖它是愚蠢的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句