Question

We have a C++ unmanaged application that appears to cause a UAC prompt. It seems to happen on Win7 and NOT on Vista

Unfortunately the UAC dlg is system modal so I can’t attach a debugger to check in the code where it is, and running under msdev (we’re using 2008) runs in elevated mode.

We put a message box at the start of our program/winmain but it doesn’t even get that far, so apparently this is in the startup code.

What can cause a UAC notification so early and what other things can I do to track down the cause?

EDIT

Apparently the manifest is an important issue here, but it seems not to be helping me – or perhaps I am not configuring the manifest file correctly.

Can someone provide a sample manifest?

Also, does the linker/UAC magic figure out that the program “might” write to the registry and set its UAC requirements based on that? There are code paths that might trigger UAC, but we are not even at that point when the UAC dlg comes up.

An additional oddity is that this does not seem to happen on Vista with UAC turned on.

Here is a manifest (that I think is/was generated automatically):

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<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' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*' />
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*' />
    </dependentAssembly>
  </dependency>
</assembly>

And then this one was added to the manifest list to see if it would help

<?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="[removed for anonymity]" 
    type="win32" 
/> 
<description>
    [removed for anonymity]
</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity 
            type="win32" 
            name="Microsoft.Windows.Common-Controls" 
            version="6.0.0.0" 
            processorArchitecture="x86" 
            publicKeyToken="6595b64144ccf1df" 
            language="*" 
        />
    </dependentAssembly>
</dependency>
 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>        
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

The following is from the actual EXE using the ManifestViewer tool

- <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0" processorArchitecture="x86" name="[removed]" type="win32" /> 
  <description>[removed]</description> 
- <dependency>
- <dependentAssembly>
  <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*" /> 
  </dependentAssembly>
  </dependency>
- <dependency>
- <dependentAssembly>
  <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /> 
  </dependentAssembly>
  </dependency>
- <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
- <security>
- <requestedPrivileges>
  <requestedExecutionLevel level="asInvoker" uiAccess="false" /> 
  </requestedPrivileges>
  </security>
  </trustInfo>
  </assembly>

It appears that it might be due to the xp compatibility setting on our app. I’ll have to test that. (we set that in the installer I found out because some sound drivers don’t work correctly on win7)

Answer 1

Windows automatically elevates applications based on various criteria (listed in Understanding and Configuring User Account Control in Windows Vista):

Before a 32 bit process is created,
the following attributes are checked
to determine whether it is an
installer:

• Filename includes keywords like “install,” “setup,” “update,” etc.
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

The best solution to all of these is to create a manifest that prevents elevation, though renaming the file may be enough.