问强制现有应用程序始终与UAC虚拟化一起运行。

EN

文件系统在某些情况下是虚拟化的，那么当应用程序不合格时，您的问题是如何仍然打开它呢？不太可能，MSDN

在以下场景中，虚拟化是不可选的：

• 虚拟化不适用于提升并使用完全管理访问令牌运行的应用程序。
• 虚拟化只支持32位应用程序。非提升的64位应用程序在试图获取Windows对象的句柄(唯一标识符)时，只需接收拒绝访问的消息。本机Windows 64位应用程序必须与UAC兼容，并将数据写入正确的位置。
• 如果应用程序包含具有请求执行级别属性的应用程序清单，则将禁用应用程序的虚拟化。

这可能来得太晚了，但我是作者的建议，您发现激活UAC虚拟化，并有一个错误在我的帖子。要修改的注册表项如下：

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\ 
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\

(注意附加的"Layers" )

因此，一个完整的例子是：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"

注意，必须用空格字符分隔多个参数。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"

--

我真的很抱歉你因为我的错误而损失了相当多的时间。

顺便说一句，让我表达我对伊恩·博伊德的观点的异议。有些地方不应该授予每个人写权限，比如这个，因为它违反了“系统范围内的写只能授权特权主体”的基本安全规则。程序文件是一个系统范围的地方，而不是每个用户的地方.

当然，所有规则都有例外，但在目前的情况下，可以想象一个恶意构建的配置文件使程序执行在用户运行时成为任意命令。从更轻的方面来说，人们可以想象另一个用户删除的“错误”，这会使应用程序失败。更重要的是，程序文件中的应用程序可执行文件通常是由管理员运行的，迟早的。即使您不想卸载程序，卸载程序也经常运行程序文件中的卸载可执行文件。也许卸载过程将使用该配置文件，这可能会产生后果，如果它是恶意构建的。

当然，你可能会说，这听起来有点偏执，同意。在Win XP的时候，我确实在程序文件中修改了一些NTFS ACL，并且在那之后就可以睡觉了，但是当工具可用时，为什么要冒一点点风险呢？

我发现了UAC不起作用的一个不太好的条件:当Program Files中的文件变成只读时。

也就是说，假设文件C:\Program Files\<whatever>\config.ini被标记为只读文件。当应用程序试图更改它时，UAC将返回一个拒绝访问的错误，而不是将其转换为%LOCALAPPDATA%\VirtualStore\<whatever>\config.ini。

虽然我没有发现这个文档，但是这种行为可能是通过设计来完成的，因为它是有意义的。

解决方案很简单:确保应用程序应该修改的所有文件都不是只读的(或者只是取消所有文件的标记，因为用户无论如何都无法更改它们)。