检测注册表虚拟化 [英] Detecting registry virtualization
问题描述
我有一组C＃（v2）应用程序，并且我在Win7（以及程度较小的Vista）中正在努力进行注册表虚拟化。
I have a set of C# (v2) apps and I am struggling with registry virtualization in Win7 (and to a lesser extent Vista).
我有一个共享的我的应用程序需要在HKLM\Software\Company中访问的注册表配置区域...在Vista之前，所有内容都根据需要写入和读取该位置。
I have a shared registry configuration area that my applications need to access in HKLM\Software\Company... Prior to Vista, everything was just written to and read from that location as needed.
该代码适当地检测到无法写入该注册表项，并且会适当地回退（改为写入HKCU并通知用户他们所应用的设置只会影响当前用户）。
The code appropriately detected failures to write to that registry key and would fall back appropriately (writing to HKCU instead and notifying the user that the settings they had applied would only affect the current user).
在Vista中，注册表虚拟化打破了所有这一切，因为我们用于HKLM写入的访问检查将默默地成功并虚拟化为HKCR\VirtualStore\Machine...。在这种情况下，用户会认为他们已经保存了计算机范围的配置，而只写了虚拟存储。
In Vista, registry virtualization broke all of this because the access check we were using for the HKLM write would "succeed" silently and virtualize to HKCR\VirtualStore\Machine... instead. In this case, the user would think that they had saved machine-wide configuration, but had instead only written to the virtual store.
可悲的是，甚至试图枚举权限
Sadly, even attempting to enumerate the permissions on the HKLM reg key explicitly returns results indicating that the user has access whether they do or not.
添加了Vista支持后，我们使用的解决方法是执行探测写入HKLM ...，然后在HKCR\VirtualStore\Machine ...中检查是否具有相同的值，并注意如果找到该值，则发生了虚拟化。
When we added Vista support, the workaround we used was to perform a probe write to HKLM... and then check in HKCR\VirtualStore\Machine... for the same value and note that virtualization had occurred if the value was found.
Win7似乎（再次）破坏了这一点，因为对显式虚拟位置（HKCR）的查询现在显示了HKLM位置的合并结果，即使未对写入进行虚拟化。
Win7 seems to have broken this (again) because queries against the explicit virtual location (HKCR) now show merged results from the HKLM location even if the write was not virtualized.
有人对此有任何建议吗？
Does anyone have any suggestions for working around this?
约束：
-我需要一个不需要提升的解决方案（当我没有管理员时）我将回退到的级别权限HKCU中的每个用户配置，但我需要能够可靠地检测到这种情况。）
Constraints: - I need a solution that works without requiring elevation (when I don't have administrator level permissions I will fallback to a per-user configuration in HKCU but I need to be able to detect this case reliably).
-
它需要与一个v2 C＃应用程序（对于C ++代码，我看到的一个选项是嵌入一个清单文件，该清单文件将禁用.exe的虚拟化功能，但是我无法在C＃V2中做到这一点，请参见在Windows中禁用文件夹虚拟化）。
它需要工作没有安装程序的情况（这使我们无法在需要REG FLAGS ...命令的注册表项上禁用虚拟化）。
It needs to work without an "installer" (this precludes the ability to disable virtualization on the registry key that we need ala the REG FLAGS... command).
推荐答案
这是一个非常好的问题，+1（为什么是社区Wiki，它应该得到积分！）
This is an excellently put question, +1 (Why is it community wiki, it deserves points!)
通常，有一组规则（[遇到时会随着时间而变化]）来控制UAC（并因此隐式地注册）虚拟化是否起作用。
In general, there are a set of rules (which [as you've run into] will vary over time) which control whether UAC [and thus implicitly Registry] virtualization are in play.
的某些显着部分 MSDN中的注册表虚拟化规则集文档是：
- [如jeffamaphone所说]如果清单中设置了requestPrivileges / requestedExecutionLevel，则将其关闭。您似乎还没有排除添加清单的问题，所以请您说明为什么这对您不起作用？ （您说我在C＃V2中无法做到这一点-有一个Add Item选项可添加应用程序清单文件，而VS2005中可用）。
- exe运行64位，默认情况下关闭
- 如果它不是交互式进程（例如服务或托管在IIS等），则关闭
如果您无法影响上述任何一项，这是理想的选择，因此您想检测UAC虚拟化是否适用于当前环境，请使用此答案一开始可能并不适合作为相关问题。 （显然，您仍然需要确定它是否适用于您正在操作的特定键，这是一个移动的目标，显然您根本不想实现需要跟踪更改（如果可以避免的话）的代码-但在大多数情况下应该比较清楚。）
If you're not in a position to influence any of the above, which is the ideal, and you thus want to detect whether UAC virtualisation applies in the current context, use this answer to a what might at first not appeat to be a related question. (Obviously you'd still need to decide whether it applies to the specific key you're operating on, which is a moving target which you obviously wouldnt want to implement code that needs to track changes if it can at all be avoided - but in most cases it should be relatively clear.)
这篇关于检测注册表虚拟化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
