Help with understanding why UAC dialog pops up on Win7 for our application
Posted
by Tim
on Stack Overflow
See other posts from Stack Overflow
or by Tim
Published on 2010-02-03T14:56:36Z
Indexed on
2010/05/09
19:18 UTC
Read the original article
Hit count: 201
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)
© Stack Overflow or respective owner