ATI Radeon Causes a UAC Prompt at User Logon
Recently, I encountered a strange issue after adding ATI Catalyst 10.4 Display Drivers to an offline Windows 7 image using the DISM.EXE /Add-Driver command. On systems that had an ATI Radeon video card, a UAC prompt would pop up the first time a user logged on and got to the desktop:
Since our users don’t have administrative rights they couldn’t complete this this operation, and the UAC prompt would continue to occur at every logon. If I entered administrator credentials or logged in as an administrator, the UAC prompt went away for all users. But if I uninstalled the display adapter via Device Manager and scanned for hardware changes, the prompt came back. I proceeded to troubleshoot, but without much success:
- Everything in Setupapi.offline.log indicated that the driver was successfully added to the offline image.
- The issue affected any system that had an ATI Radeon HD display adapter, regardless of the model.
- I had used previous versions of ATI Catalyst display drivers, including 9.12, without any problems. As it turns out, the UAC prompt began to appear beginning with Catalyst 10.1 and continued through the current version (10.6).
- According to Device Manager, the display adapter was already installed and working properly. If I entered administrator credentials at the UAC prompt, no additional or new devices appeared in Device Manager.
Maybe the UAC prompt doesn’t seem like a big deal, but when you have 5000+ computers that displaying this annoying prompt at every logon, going around to each one and entering administrator credentials isn’t an option. I opened a support case with our system vendor, but after a month without much progress, I started digging deeper on my own.
One thing that I had overlooked originally was setupapi.dev.log, which tracks hardware device installs. I opened this log on a system that exhibited the UAC prompt behavior and began sifting through the entries. I found the install section for the ATI Radeon device. At first, it looked liked everything was fine. The driver installed successfully and the section closed with [Exit status: SUCCESS]. I then began to read through every line to see if there were any other clues. Finally, I found something:
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 13:58:19.543
dvi: CoInstaller 1: Enter 13:58:19.543
dvi: CoInstaller 1: Exit
dvi: Class installer: Enter 13:58:19.543
dvi: Class installer: Exit
dvi: Default installer: Enter 13:58:19.606
dvi: Default installer: Exit
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 13:58:19.606
ndv: Device has a Finish Install Action that needs to be run.
The last line is what caught my attention. I searched through the rest of the log for the entry Device has a Finish Install Action that needs to be run. Sure enough, the ATI display adapter was the only device that had this status. I began looking for more information about DIF_NEWDEVICEWIZARD_FINISHINSTALL. This eventually led me to the Windows DDK documentation, where I learned about Finish-Install Actions:
After core device installation is complete for a device, Windows checks whether the CONFIGFLAG_FINISHINSTALL_ACTION flag or the CONFIGFLAG_FINISHINSTALL_UI flag is set for the device. If either of these flags is set for a device, Windows queues a finish-install process that performs the finish-install actions specific to the device. The process executes in the user’s context.
The finish-install process runs only in the context of a user with administrator credentials at one of the following times:
- The next time that a user who has administrator credentials logs on while the device is attached.
- When the device is reattached.
- When the user selects Scan for hardware changes in Device Manager.
If a user is logged on without administrative privileges, Windows prompts the user for consent and credentials to run the finish-install actions in an administrator context.
Arrrrrgh! It seems that this behavior is by design!? I’m not sure why I haven’t come across another driver that exhibits this behavior, or why ATI decided to implement this behavior beginning in Catalyst 10.1.
The Finish-Install Action
Next, I decided to use Process Monitor to figure out what the Finish-Install action was doing. With Process Monitor running, I entered administrative credentials into the UAC prompt and let the install complete. I then began filtering out irrelevant Process Monitor entries to find out what what was happening during the Finish-Install action. As far as I could tell, it was setting the registry value INFName under HKLM\SOFTWARE\ATI Technologies\Co-installer to the name of the INF that was used to install the driver. That’s it.
Goodbye, Finish-Install Action
Since this seems to have little, if any, impact on the functionality of the display driver, I began searching for a way to skip or disable the Finish-Install actions. I searched through the Windows DDK documentation and came up with nothing. I also had Google searches coming out the wazoo.
Finally, I used Process Monitor again to see if I had missed anything during the first try. It turns out I did: The registry value ConfigFlags under HKLM\System\CurrentControlSet\Enum\PCI\VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 was being set to 0×0. I went back and looked found that, after the display adapter is installed and before the UAC prompt, ConfigFlags is set to 0×00020000. As it turns out, this is the enumerated value for CONFIGFLAG_FINISHINSTALL_ACTION. I tried to modify the ConfigFlags value, but it turned out that only the SYSTEM account had permissions to do that. So I grabbed PSExec and ran this command:
PSEXEC -s REG ADD HKLM\System\CurrentControlSet\Enum\PCI\VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 /v "ConfigFlags" /t REG_DWORD /d 0 /f
Finally, the UAC prompt went away.
Note: If decide to try the command above, be aware that the registry path referenced will probably differ from yours. The names of the registry keys vary depending on what ATI video card you are using. VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 refers to the Radeon HD 4550 video card on the machine that I was using to troubleshoot. One way to solve this is by writing a VBScript that searches for ATI display adapters under HKLM\System\CurrentControlSet\Enum\PCI and verifies that ConfigFlags is set to 0×0.
![[del.icio.us]](http://iboyd.net/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://iboyd.net/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://iboyd.net/wp-content/plugins/bookmarkify/facebook.png)
![[StumbleUpon]](http://iboyd.net/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Twitter]](http://iboyd.net/wp-content/plugins/bookmarkify/twitter.png)
Themocracy
Thanks Boyd,
As you know I have been looking into this for a while. Thanks for your persistence and professional approach to getting to the bottom of this bugger of a problem.
Cheers,
Nathan
Thanks VERY MUCH. You have solved a major issue for me, I have had this with three drivers so far. Microsoft’s LifeCam, an Audio driver for the Lenovo T420s laptop, and another keyboard filter driver. The webcam went through Microsoft PSS and they couldn’t solve it – so many thanks. Great detective work.
Glad I could help. I contacted ATI support this issue. They denied that this was a problem, but told me they would pass it along to developers. I never heard back.
THANKS SO MUCH!! Was pulling my hair out at this, I even went down th epath of assuming the drivers were not digitally signed as we were trying to deploy to win7 x64! Amazes me how this is the only article on the net explaining this issue, Im sure others will no doubt hit this issue as and when more companies make the move to Win7…
Glad I could help. I hope that driver developers, especially those for vendors such as ATI, will realize that Finish-Install actions don’t work in non-administrator user environment.
Thanks alot for this post but how can i do it inside the image ? ia alreadt gave everyone full permision to that registry but still it is prompting
Some folks pointed me to this link:
http://msdn.microsoft.com/en-us/library/ff545004(VS.85).aspx
” if the co-installer incorrectly sets the DI_FLAGSEX_FINISHINSTALL_ACTION flag, the user gets an undesired User Account Control (UAC) prompt for permission to proceed even though the finish-install action has no action to perform.”
How did you implement this into your image setup. We have this issue but cannot figure out how you changed this value on a 7 machine in Audit mode. We tried doing your PSEXEC cmd with our PCI vendor values but PSExec fails doing the Red ADD and gives errors on the “&” symbols. Did you add this into a Task Sequence as a script when did your deployment?
Hey Eric,
Actually, we use systems management software (BigFix AKA Tivoli Endpoint Manager) to detect machines with this issue and apply the registry fix. The “action script” is specific to BigFix, but you could make a VBScript that would do the same thing, and put in a task sequence as well.
Regarding the ampersand (&), the most likely reason you received an error is that it needs to be escaped with a caret (^).
Here’s a simple example you can try at the dos prompt:
Ah Thanks for the info – I will give this a shot.
Sorry typo, REG ADD*
Just for info in case anyone else is trying to script this – Ive tried to run through the registry with a powershell script, however this fails when it gets to the Properties folder within every subkey under ENUM\PCI\VENXXX, since permissions are setup in such a way as to disable reads. I even tried psexecing out to the SYSTEM account – no joy.
Best way Ive found, although Ive yet to code this, is to use the C:\windows\setupact.log – in here under the rows beginning with dispci.dll is the actual key name used for the driver – read this into Powershell, do some jiggery-pokery with strings and bingo – you have your registry location with which you can set the configflags to 0.
HTH
Quick update on my previous post – Ive created this Powershell script to accomplish setting this key automatically, just need to ensure this script runs as SYSTEM at first boot:
Get-Content C:\windows\setupact.log | Select-String “PCI” -casesensitive | foreach {
$PCILoc = $_.tostring().indexof(“\”)
$PCILen = $_.tostring().length
$PCILoc = $PCILen – $PCILoc
$DispReg = $_.tostring().substring($_.tostring().length – $PCILoc, $PCILoc)
$FullKey = “HKLM:\SYSTEM\CurrentControlSet\Enum\PCI” + $DispReg
if ((Test-Path $FullKey) -eq “True”)
{Set-ItemProperty $FullKey -name ConfigFlags -value 0}
}
It will read the contents of setupact.log, which will contain the key path to your display driver. It will filter the lines into lines with “PCI” in them (you can try substituting this with “dispci.dll: DisplayClassInstaller” in case you are worried about other PCI devices getting config flags set to 0), then form the full key based on this and if it exists, set the configflags value to 0.
Hope that helps
Brilliant post. Also works for the Bluetooth 3.0 drivers on a Lenovo T420! This is my version using VBS. I’m about to test it from a SCCM task sequence…
The Description of the ATI device appears to be unique under “HKLM\System\CurrentControlSet\Enum\”, so I’ve made the assumption that I can search on it. I have added the strcomp(left section as the Description field adds a couple of spaces to the end of the name! It also assumes that psexec.exe is in the same directory – will add some logic to make sure later on…
The code;
On Error Resume Next
StringToLookFor=”ATI Mobility Radeon HD 3400 Series”
strComputer = “.”
Set objWMIService = GetObject(“winmgmts:” _
& “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)
Set objShell = CreateObject(“Wscript.Shell”)
Set colItems = objWMIService.ExecQuery(“Select Description,DeviceID from Win32_PnPSignedDriver”)
For Each objItem in colItems
If StrComp(Left(objItem.Description,Len(StringToLookFor)),StringToLookFor,1)=0 Then
Wscript.Echo “Description: ” & objItem.Description
Wscript.Echo “Device ID: ” & objItem.DeviceID
DeviceID=objItem.DeviceID
End If
Next
MainKey=”HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\”
FullString=MainKey & DeviceID
CommandLine=”PSEXEC.exe -s REG ADD ” & FullString & ” /v “”ConfigFlags”" /t REG_DWORD /d 0 /f”
returnCode=ObjShell.Run(CommandLine)
WScript.Echo “RC:” & returnCode
I just went through the same thing with 2 other ATI or AMD Radeon video drivers (both bootcamp):
http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/3c90cad7-3729-49b6-8d16-a89fc7830702
Thanks Boyd,
This is very useful information and it helped me a lot. But I have another problem when I try update the following registry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1002&DEV_9712&SUBSYS_1455103C&REV_00\4&c60e52a&0&2808]
“ConfigFlags”=dword:00000000.
I am getting Following error “Cannot edit ConfigFlags: Error writing the value’s new contents”. Even tried updating using Powershell then I am getting Access denied error.
Any help would be much appreciated.
Hey Asgar, it’s a permissions issue. By default, that registry value can only be edited by NT Authority\SYSTEM. You could change the permissions, but it’s probably easier to just use PSEXEC.EXE -S to execute the command as SYSTEM, which is what I actually did in the post above.
Thanks,
Matt
Hi Boyd,
let me echo the thanks of the others above, esp. for such a concise breakdown of the cause and the solution. I just started looking at this and you have saved me a lot of time and effort thanks again,
Barry
Your explanation is fantastic and exactly what I needed to prompt Dell to hopefully resolve this issue on their Optiplex 780 drivers.
Alex, I’d be interested in hearing what the outcome is with your Dell case. As far as I can tell, this is an issue because of ATI’s drivers, but perhaps Dell can persuade them to resolve it.