日志文件可能是用提升的权限创建的

最佳实践是重写应用程序以使用每用户存储,除非您确实需要某个用户保存的内容来影响盒子上的其他用户。也就是说,拒绝回答“只有一个用户,所以每个用户和每个机器是相同的”。在这种情况下,整个应用程序始终以非提升方式运行,并带有防止虚拟化的清单。

下一个最佳实践是对应用程序进行分区。写入到hklm的代码位于单独的exe中,并且具有请求提升的清单。用户界面有一些警告(按钮或菜单项上的屏蔽),用户可以在其中运行此代码。单独的进程是通过shellexecute启动的,它尊重清单。用户的体验是,大多数情况下,应用程序运行时没有提升,有时部分应用程序会提升,然后下降。这就是它看起来的样子,但实际上这是不可能的——一个exe文件要么被提升,要么没有提升。你用两个前男友达到效果。

第三件最好的事情是将日志移动到相同的位置,无论您是否被提升,并训练您的用户在需要时手动提升。我认为这根本不是一个好的解决方案,但总比训练他们每次都在不同的地方手动提升和编写日志文件要好。我猜你是在“当前目录”下写的,它本身在程序文件下,而且你没有清单。然后,当没有提升时,你的应用程序将在虚拟存储下写入。如果用户需要查找日志文件,这确实不好。写到另一个文件夹-AppData下的一些东西会很好。该位置将不会被虚拟化。

检测是否提升的最简单方法是使用isinRole查看用户是否是管理员。作为一个小小的测试将证明,即使是管理员用户 false 当应用程序未提升时返回,即使是使用ots提示提升的非管理员也会得到 true 返回。

UAC是一个相当大的变化;在充满危险的情况下,试图改变你的应用程序以适应它。将注册表和日志文件位置从计算机区域更改为用户区域会更容易吗?例如,香港联合交易所和CSIDL的应用数据。如果这对您不起作用,那么用户只需运行提升的应用程序;您可以指定RequiredMinistor清单。