You should know the score by now – I install application FOO into “C:\Program Files\Foo Inc\Foo” and it has a built-in manifest stating that asInvoker is used for its requested privilege level, allowing standard users to run it.
Attempts by standard users to write to “C:\Program Files\Foo Inc\Foo” do not fail with “access denied” (as they would have on version of Windows prior to Vista), but instead the disk write is redirected to the user’s own profiles (under “%userprofile%\AppData\Local\VirtualStore\Program Files”).
So far, so good – the application is happy as it believes it is able to write to a system protected area of the volume even when running without admin rights.
But imagine that FOO has an “automatic updater” or a “launcher” stub process whose job it is to check the current version of the application and download an update package & apply it…
The write operation is virtualized into the user’s profile, so the new patch will download okay – but when it comes to apply it this is also virtualized and the file it is updating or replacing is not in VirtualStore… so it fails.
Re-run the launcher and it will either start over with the download of the update, or try again to apply it and fail once more.
There are now plenty of apps (and games) that will run okay without admin privileges, but they have problems patching because of UAC virtualization unless the launcher was started elevated (or by the Administrator, who is the only user exempt from UAC as per my previous blog entry).
So how to leave UAC enabled and be able to use and update this program as a standard user?Continue reading