locked
UAC Sheild Program Icon Overlay RRS feed

  • Question

  • I have an application and the Setup.exe and *.exe program file has a manifest added with asInvoker and uiAccess="false"

    The application is installed for All Users, however the Start menu icon and desktop icon for the application has the UAC shield added.  However, clearly our application does not require Administrator permissions due to the manifests.  Is there any tools to confirm the manifest is correct or why the shield is being displayed?  The manifest is shown below for the program file:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
    <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
    </requestedPrivileges>
    </security>
    </trustInfo>
    </assembly>

     

    The Windows Vista Application Development Requirements for User Account Control Compatibility document states the following.

    Icon Overlays

    In Windows Vista, if an executable file requires elevation to launch, then the executable's icon should be “stamped” with a shield icon to indicate this fact. The executable's application manifest must designate a requestedExecutionLevel of requireAdministrator to designate the executable as requiring a full administrator access token. The shield icon overlay will also be automatically placed on executables that are deemed to require elevation, as per the installer detection heuristics. For example, a file named setup.exe will automatically receive a shield icon overlay, even if the executable does not have an embedded application manifest.

     

     

    Does anyone have any suggestions what would be causing this?  Also, does anyone have any information on what installer detection heuristics would deem the application to require elevation.  Testing was completed using Windows Vista RTM.

     

     

    Thursday, November 30, 2006 6:10 AM

Answers

  • When changing the Installer's shortcut target from "Program Name" to the absolute path "C:\Program Files\Company\Product\Product.exe" the issue is resolved with the UAC overlay.
    Friday, December 1, 2006 1:25 AM

All replies

  • Here is the manifest we use. You can see it differs in a couple of ways from yours. Perhaps this is significant.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity version="1.0.0.0"
         processorArchitecture="X86"
         name="whatever.exe"
         type="win32"/>

      <!-- Identify the application security requirements. -->
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="asInvoker"
              uiAccess="false"/>
            </requestedPrivileges>
           </security>
      </trustInfo>
    </assembly>

    Thursday, November 30, 2006 7:59 AM
  • I have tested the following manifest:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity version="1.0.0.0" processorArchitecture="msil" name="Filename.exe" type="win32"></assemblyIdentity>
      <description>Program Description</description>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
          </requestedPrivileges>
        </security>
      </trustInfo>
    </assembly>

     

    Still receiving the overlay icon on our program icon.  Also, we are logged in as a Standard Account.  As per MSDN documentation for the processorArchitecture attribute the processorArchitecture="msil" should be fine for managed code.

    Is anyone else experiencing this issue?

    I am adding the manifest using the mt.exe tool, the tool seems to modify our xml slightly and removes the <?xml line from our manifest.  Any ideas?  Well when viewing the manifest with ResHacker the <?xml line has been removed.

    Thursday, November 30, 2006 10:31 AM
  • The best description that I have seen of the installer heuristics used is at http://www.microsoft.com/technet/WindowsVista/library/00d04415-2b2f-422c-b70e-b18ff918c281.mspx - look for "Installer Detection Technology" section.

    According to this document, installer detection does not activate in cases where you have the manifest with requestedExecutionLevel in it, which you do already. Just to rule out the installer detection, you could temporarily disable it by using the Local Security Policy admin tool in the control panel. Look for "User Account Control: Detect application installations and prompt for elevation".

    Thursday, November 30, 2006 9:45 PM
  • I did some further investigating, it seems the actual .exe file does not have the UAC overlay only the shortcut does.  When we create a new shortcut rather than use the Windows Installer shortcut that was generated with the Windows Installer, the issue is resolved.

    Does anyone have any information regarding the UAC overlay and Windows Installer shortcuts?

    When opening the proprties of our shortcuts, the Windows Installer generated shortcut simply lists the application name within the shortcut, whereas our generated shortcut lists the absolute path to the .exe file.

    Friday, December 1, 2006 12:50 AM
  • When changing the Installer's shortcut target from "Program Name" to the absolute path "C:\Program Files\Company\Product\Product.exe" the issue is resolved with the UAC overlay.
    Friday, December 1, 2006 1:25 AM
  • I'm a little late to the party here, but I wanted to chime in with my $.02.  I appreciate your solution, as I haven't found any other, but hardcoding the path to the target is not workable for scenarios where the user can specify the target directory. In my case I was going crazy trying to figure out what was causing the UAC Shield, I couldn't find anything that made any sense until I discovered that if the name of the file contains the word 'update' anywhere in the title, it will trigger the shield. No doubt a part of the installer detection heuristics. So in my case I will just rename the program.
    Friday, June 8, 2007 7:41 PM
  • lol, thanks for this suggestion. I had pretty much the same problem. I renamed the assembly (incl. AssemblyTitle and AssemblyProduct attributes) and the icon was gone.

     

    Wednesday, August 1, 2007 3:14 PM