Bug in UAC with trusted path RRS feed

  • General discussion

  • If you enable the "Computer Configuration\Administrative Templates\Windows Components\Credential User Interface\Require trusted path for credential entry" setting in Group Policy, then have a startup item such as XFire which requests privilege elevation AND launches at logon, roughly one time in four the initial UAC "I want to complete this action" box will not appear on screen, however the sound for it will play, and you will see in your process list that consent.exe is now running and consuming over 80% of your processor time.


    I have to admit, this bug is beginning to irk me, and it's rendering an otherwise useful security feature near unusable.


    Since I don't know of any way to report such an issue, I post it here, hoping that people know of some fix, or someone will pick this up and look into it.

    Thursday, April 17, 2008 6:42 PM

All replies

  • Hi, thanks for posting here.


    This is a good place to post this and I'll make sure someone on the UAC team hears about this. Could you please tell me, when you say it launches at logon, where exactly are you launching it from?

    I'll try re-creating your scenario and see what the output is on my machine.



    Friday, April 18, 2008 12:35 AM
  • C:\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup


    XFire generates a shortcut here (using an invalid Start In path as it specifies the file name in addition to the folder) when told to start "Automatically launch XFire when I startup my computer".


    Once XFire launches it detects the games on your system. If any of them match a list of "elevated" games it has in an ini file, then it launches a second, smaller copy of itself to monitor games which it believes run under elevated privileges, to allow for the tracking of time, stats, etc.


    By default it will produce a dialog which tells you XFire needs to run under elevated privileges owing to games X, Y and Z. When you hit continue the elevated "Yes/No" UAC box appears. This works every time. However, there is an option to tell XFire not to display this message again, in which case it skips straight to the "Yes/No" UAC box. It is when you have chosen to skip the XFire warning that you will sometimes encounter the issue of the "Yes/No" UAC dialog not appearing.


    The XFire game detection take some time to run, so it will normally be a good thirty or fourty seconds after logon before you would be prompted for elevation.


    I run UAC with a password required at all times.

    Friday, April 18, 2008 5:42 PM
  • Hi

    I'm going to repeat this to see if I get it right. Xfire is an application that, when it is launched, it will automatically ask for elevation and you get displayed the consent dialog everytime. However, when you select the "Do not display" checkbox within Xfire the program gets automatically elevated sometimes? Or it just doesn't get elevated at all?


    Saturday, April 19, 2008 2:20 PM
  • The program launches a second copy of itself, and it is this second copy which makes the request for elevation. When the box "Do not display" is checked, it still tries to elevate itself, it's just that now sometimes the initial UAC CTRL-ALT-DEL prompt will sometimes not appear, though the dialog sound will play, and consent.exe now appears in the Task Manager list chewing up CPU time.

    Saturday, April 19, 2008 9:14 PM
  • I see what you mean now. The problem lies in the fact that Xfire initiate another copy of itself, that also requests elevation. Somewhere in between requesting priviliges, it hangs. This is a 3rd party application and the developpers might not have given a lot of thought when designing the software about the "Do not display" option.


    You can report the bug to Xfire, and hope they'll fix it in future versions.  


    Monday, April 21, 2008 7:13 AM
  • Many thanks, I will pass a bug report on to them.

    Monday, April 21, 2008 7:23 PM

    Always a pleasure!

    Thanks for stopping by and posting this, it will sure help for future troubleshooting.

    Monday, April 21, 2008 7:56 PM