Finding the reason for a UAC elevation in Windows 7 - windows

Question

I've inherited maintenance of an application that, when it runs, occasionally causes the UAC admin elevation (Do-you-wish-to-allow-this?) dialog to appear. To me, the obvious first thing to try is "switch on UAC logging", re-run the application to make the dialog appear, then find the entry in the log that says, for example, "2013-11-23-19:10:03 [MyApplication] attempted to write registry entry [MyRegistryKey]. Requires admin authorization", then take steps to resolve things so the dialog doesn't surface when the application is being used.
However, some people posted questions about UAC logging in 2008/09, in relation to Vista, and the answer was something like "UAC doesn't log, but that would be a great feature for a future release". Was UAC logging ever implemented, either in Windows 7 or as a patch release? If not, is there an alternative technique that is commonly used?

Answer 1

I resolved the problem eventually. Here is what happened.
1) I tried Ben's suggestion of using the sysinternals tools. The tools that seemed useful were
DependencyWalker
ProcessExplorer
ProcessMonitor
They each provide a lot of information about what is going on, and I can see that these will need to be the first port of call for many, if not most, Windows problems. However, in my case I double clicked the app and got the UAC userid/password dialog but then found that not much information had been written by the tools up to the point the dialog was surfaced.
It also looked like it would be useful to digest the contents of the Microsoft Press Windows Internals books when attempting to troubleshoot problems with UAC.
2) I tried using the Application Compatibility Toolkit, but it showed no issues with the program either on XP (where it worked) or Windows 7 (both with standard user, which surfaced the UAC dialog and admin user, which worked)
3) I then tried painstakingly recreating the app from scratch, starting with an empty project and then copying in files and settings bit by bit. At each stage, I checked whether the app would launch without surfacing the UAC dialog.
Eventually I applied a change and this caused the UAC dialog to surface. This was a VB6 app and I changed the "application title" and the "product name" in the dialog Project, Properties, Make. The previous (failing) value of each field was "ApplicationName Update". To make the app work without UAC elevation, what I had to do was remove the word "Update".
As Ian suggested above, it looks like the UAC heuristics were being applied, and to values within the exe. I see that the Windows Internals book does talk about scanning for byte sequences in the exe when deciding whether to elevate.
4) So in summary, the approach that worked for me was to reassemble the app bit by bit and see at what stage the UAC dialog is triggered. Once this happens, knowledge of the four reasons given by Ian in the previous answer become important.
5) I should point out that I have fixed the problem by removing the thing that was being flagged in the heuristics, but didn't consider the alternative suggested by Ian: "asInvoker". It could be that this is the best thing to try rather than spending time inside the (legacy) app fixing problems.

Answer 2

find the entry in the log that says, for example, "2013-11-23-19:10:03 [MyApplication] attempted to write registry entry [MyRegistryKey]. Requires admin authorization"
UAC does not work like that. Windows does not watch an application, and based on the activity decide that it should run elevated next time.
Windows 7 mostly behaves the same as Windows XP in this regard. If your app is running as a standard user, tries to write to:
HKLM\Software\Cotoso\Litware
your application will get an Access Denied error message.
Unless File and Registry Virtualization is enabled for buggy apps
Unfortunately, most applications are poorly written. Most applications, when run as a standard user on Windows 2000 or Windows XP, crash horribly. Since 1999, as part of the Windows Logo Requirements, Microsoft has required developers to test their applications while running as a standard user. Almost nobody ever does.
That is why, starting with Windows Vista, Microsoft added a feature that lets your buggy application think it successfully wrote to HKLM, or Program Files. If a write fails, which would have succeeded if the user was an administrator, Windows will reissue the write operation, except this time redirect it someplace that will succeed. For example:
writes to
HKLM\Software
are redirected to
HKCU\<User SID>_Classes\VirtualStore\Machine\Software
writes to
C:\Program Files
are redirected to
C:\Users\Westwell\AppData\Local\VirtualStore\Program Files
Neither of these redirection mechanisms will cause your application to be elevated on next launch. Both of these features are temporary compatibility hacks. You can inform Windows that you wrote your application correctly, opt-out of file and registry virtualzation, by adding a requestedExecutionLevel of asInvoker to your application's assembly manifest:
<?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="client" type="win32"/>
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Now only eliminates the side-discussion of why sometimes writes can succeed, even when the user is a standard user.
When does UAC Elevation happen
There are five reasons why an application might prompt to elevate on launch:
You manifested that your application needs to be run as an administrator.
If you app needs to be run as an administrator, and cannot perform any useful functionality without being an administrator, then you can manifest your application as requireAdministrator (rather than asInvoker):
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
If this were the case, then the application would always run as an administrator. So that's not it.
You manifested that your application be run as administrator only if the user actually is an administrator.
Applications like RegEdit can run fine as a standard user, they do not require elevation. But if the user is actually an Administrator RegEdit can prompt to elevate to the user's full admin privelages. This done by marking your application as highestAvailable (rather than asInvoker or requireAdministrator):
<description>Westwell Contoso</description>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
If this were the case, your app would prompt for elevation for admins, but not prompt for standard users. This cannot be the cause because your application has no manifest.
Compatibilty option marked the application as Run as administrator.
The user can choose to mark an application so that it should prompt for elevation:
The state of this checkbox (and the other checkboxes) is stored in the registry:
HKCU\Software\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers
and for "all users" under:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers
This option can be per-user, or per-machine. So it's possible some users will see an elevation prompt, and others will not. This could be a source of your problem.
Installer detection heuristics.
By default, Windows will attempt to recognize that an application is probably an installer (e.g. setup.exe, install.exe, update.exe) and prompt the user to elevate. This feature can be disabled through group policy, the policy name is User Account Control: Detect application installations and prompt for elevation.
The Easy Fix
The easy fix is to simply mark your application asInvoker. That will disable heuristics.
After that, it must be a compability setting on the machine (AppCompatFlags in HKCU or HKLM).
Bonus Reading
Registry Virtualization
User Account Control Data Redirection