13

We have an x86 Win32 desktop application. When the installer is run by a Standard (non-Admin) user, we avoid elevating and/or showing a UAC prompt and install under C:\Users\username\AppData\Roaming\... instead of the common Program Files directory.

On Windows 10, when our uninstaller is launched from Control Panel -> Programs -> Programs and Features, no UAC prompt is shown and the uninstaller runs without elevating. This is the desired behaviour. When the same uninstaller is launched from Start -> Settings -> System -> Apps & features, a UAC prompt is shown.

(The same behaviour can be seen in the Opera browser installer/uninstaller. I tested v35.0.2066.37.)

Why does the same uninstaller behave differently when launched from Apps & features versus Programs and Features?

How can the UAC prompt be avoided when the uninstaller is launched from Apps & features?

The manifest of our uninstaller includes this:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
   <security>
      <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker" />
      </requestedPrivileges>
   </security>
</trustInfo>

I tried changing the requestedExecutionLevel, and also tried removing trustInfo completely, but there was no change in behaviour either way.

Tested on Windows 10 version 1511 build 10586.104.

Edit: Just to clarify, the case I'm trying to handle is where the user has a Standard account and does not know the password of an Admin account. If they see a UAC prompt when they try to uninstall, they have no choice but to cancel it, and our uninstaller does not get run.

d.l.
  • 141
  • 1
  • 6
  • I just spent the morning dealing with this "feature." The only approach that worked for us was to have the uninstaller re-launch itself as the current user. Here's a description of the approach, which uses Explorer to re-launch the executable: http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/ We use NSIS, so we were able to utilize the ShellExecAsUser plug-in, which is based on the first link: http://nsis.sourceforge.net/ShellExecAsUser_plug-in – Osbourne Ruddock Aug 08 '16 at 19:37
  • I suppose this doesn't address the primary problem, but for us, the concern is that the uninstall fails when run elevated, because it needs to access HKCU and LocalAppData. This does not address the problem of preventing elevation, but even a CurrentUser install of Chrome (and as you noted, Opera) suffers from the same elevation issue on Windows 10 when uninstalled from Apps and Features, so we figure it's sufficient for it not to fail and to execute as the current user whether it's launched elevated or not. – Osbourne Ruddock Aug 08 '16 at 22:07

1 Answers1

8

This is a bug in "Apps & features" as far as I know. The WiX people have closed this issue as a Windows bug and I assume they have notified the correct people @ Microsoft. The behavior is still the same in Insider build 15042 though so it is probably not going to get fixed in time for the Creators Update.

There is no workaround you can use if the standard user cannot elevate.

If they can elevate then you can use the re-spawn workaround posted in the comments or manually load the user profile and call RegOverridePredefKey but they are both ugly hacks (IMHO).

Anders
  • 97,548
  • 12
  • 110
  • 164