[DUG] registry caching?

[Conor Boyd]

A process either runs elevated or it doesn't.

A process cannot change from an unelevated state to an elevated one.

A process can request to spawn an elevated sub-process in which case the
UAC prompt will be shown.  Or it can request an elevated instance of a
COM server in which case the UAC prompt will be shown.

In the second scenario, if the process holds on to that COM object for
the rest of the process's lifetime, then it won't cause the UAC prompt
to be shown again.

To give an example of the second scenario, I have a legacy app that
writes to HKLM (on which other parts of the program suite rely).  I
pulled the HKLM-writing code out into a COM server.

My legacy app (when running on Vista or Win 7) requests an instance of
the new COM server, at which point the UAC prompt is shown.  If the UAC
prompt completes successfully (either because the program was being run
by an admin who confirms the elevation, or an admin username/password
combo is correctly entered) then my legacy app holds on to that COM
server instance for the rest of the session to enable continued
successful HKLM writing without further UAC prompts.

One can google for the circumstances under which Vista will determine a
program to be requiring elevation up front (these include having the
word "setup" in the filename, which is how most installers automatically
request elevation on startup).

Or one can include a Vista manifest indicating the elevation status that
the application requires.  If you set it to "requireAdmin", then the app
will always present a UAC prompt on startup, and won't continue without
successful completion of that UAC dialog.

An installer isn't an "installer" from the POV of Vista/Win7.
Installers are simply examples of programs which Vista always runs
elevated.

I could well be wrong, but I don't believe Windows controls or monitors
the scope of elevation timespans as you suggest John.  I believe it's
simply a question of each application determining it's own elevation
status (through manifests, etc) and controlling the elevation status and
lifespan of any child-processes or COM objects that it instantiates.

Cheers,

Conor

-----Original Message-----
From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
On Behalf Of John Bird

I have noticed that it must store the process ID or something similar of
the original parent process  that needed and was granted the elevation.
If the same action requiring elevation is run again it does not ask as
long as the original program or one started by the original program is
still running and 
repeating the same action.   However if the program is terminated and 
restarted it does ask again.

It shows there was some thought by MS into giving the elevation some
scope over actions and processes related to the original process, and
probably for some time as well, all of which is sensible.

(In my case it was not registry stuff, but a starter program copying
.Exe files wich does trigger Vista into thinking its some kind of
installer I am guessing - which is similar to what you are doing)