What causes UAC prompts - is there a list?

  • Thread starter Thread starter Harpo
  • Start date Start date
H

Harpo

Hi,

well I googled a lot and still can't find a list of things that will bring
an UAC prompt if a program attempts to do them.
I only found some recommendations , like "don't write to HKLM" , but indeed
these don't cover everything.

Is there a clear list of what does and what does not bring an UAC prompt?

For example, is it possible any sort of 'Read' operation to trigger it
(reading whatever registry settings, files that belong to another user
etc. )

Can a program only write to
C:\Documents and Settings\<username>\ and HKCU ?

Thanks
 
Hello,

Any program that needs to perform an action that requires administrator
privileges must throw a UAC prompt. So, with few exceptions, if a program
attempts to do anything that your user account DOES explicitly has
authorization to do, the program will be successful.

However, if the program attempts to do something that you are not explicitly
permitted to do, but "administrators" are, the program must prompt you via
UAC in order to be able to do that something.

Also note that the UAC prompt is not "automatic" - a program must explicitly
throw a UAC prompt. If a program is not designed to do that, it will either
fail with an "access denied" error or Windows will silently trick it into
thinking it is working.

The general rule, as you have ascertained, is that most everything can be
read by programs, but anything that affects the entire system requires admin
privileges (such as HKLM and most folders outside of the user profile). But,
as I explained, the specifics are based on permissions.

It may be easier to think of it this way: All programs run as a "standard
user" and are limited as such; Only through UAC does a program run as an
administrator.
 
Thanks,

I sort of know all this.
I would prefer to check my apps against a list instead of guessing and later
receiving support requests.
As you say "most everything can be read by programs" , I'm interested in the
exclusions , if any - an attempt to read what will trigger an UAC prompt?
There should be a list somewhere, if not officially posted by Microsoft then
at least compiled by users with experience.

I have tried with application verifier but it creates a huge and mostly
useless log
 
Harpo said:
Thanks,

I sort of know all this.
I would prefer to check my apps against a list instead of guessing
and later receiving support requests.
As you say "most everything can be read by programs" , I'm interested
in the exclusions , if any - an attempt to read what will trigger an
UAC prompt? There should be a list somewhere, if not officially
posted by Microsoft then at least compiled by users with experience.

I have tried with application verifier but it creates a huge and
mostly useless log
Click to expand...

http://search.microsoft.com/results...sta&l=en&s4=on&OtherSite=&mkt=en-US&FORM=QBMA

Your answer should be in there somewhere.
 
As you say "most everything can be read by programs" , I'm interested in
the exclusions , if any - an attempt to read what will trigger an UAC
prompt?
Click to expand...

NOTHING your application does will trigger a UAC prompt. As I stated
earlier, UAC is NOT automatic. Your application runs as if it were started
by a standard user, even if the user is logged in as an administrator. If
your application tries to access something that the user does not have
access to (ignoring the user's membership in the administrators group), one
of two things may happen:

1) (most likely) Your application will be denied access.

2) Virtualization may kick in. This will happen if your application is
32-bit and does not have a Vista-style manifest. In this scenario, if your
application tries to WRITE to HKLM or certain system folders, Windows will
make your program think it is writing to these locations, when in fact
Windows is silently making a copy of the saved data into the user's profile
directory and leaving the data in the original location unmodified.

You seem to be making UAC into something more than it is.

UAC is simply the means by which programs run with administrator
permissions. In Windows Vista, programs can either run with "standard user"
permissions (default, even if the user is an administrator) or run with
"administrator" permissions.

A program either runs with standard OR administrator permissions. Once a
program is started, its permission level does not change. When running with
standard permissions, the program cannot use "administrator" permission.

In order for a program to run with administrator permissions, the program
must include a Vista-style manifest that tells Windows that it requires
admin permissions. Windows will then throw a UAC prompt that asks the user
for permission.

UAC is the means by which programs receive admin permission; there is no way
for a program to run with admin permissions without the user being prompted
in this manner. UAC is NOT automatic; the program must tell Windows that it
needs admin permissions for the user to be prompted through a manifest.

Please read this document thoroughly:

http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
 
There are 3 ways to mark an application to run with admin rights. I posted
the mechanisms in response to
"UAC and scripts(.wsf)" post.
 
You are correct; however, from the perspective of an application developer,
the correct way is to use a manifest. :)
 
Back
Top