Discussion:
how to control whether a UAC shield is applied to a binary?
(too old to reply)
smilek
2010-07-10 18:56:21 UTC
Permalink
Why does UAC block certain binaries from execution? How can I get rid of the
UAC shield over the binary? I have two identical binaries, one installed by
the installer (avscc.exe) and the other placed into a directory manually
(avscc1.exe) The former has the admin shield over it as shown in the
screenshot at this url:

Loading Image...

(If I rename avscc.exe to avscc2.exe, the UAC shield goes away. If I rename
avscc1.exe to avscc.exe, the UAC shield occurs. So, it looks like the shield
is associated with the name of the binary, not the binary itself.)
--
Steve Milek
Phill W.
2010-07-19 11:57:54 UTC
Permalink
Post by smilek
Why does UAC block certain binaries from execution?
Because that's its job?
Post by smilek
How can I get rid of the UAC shield over the binary?
Why would you want to?

The shield is a visual indicator (to the user) that they require
elevated permissions to run this program. Without it, they'd get
"unexpected" UAC challenges popping up that would scare them silly.
Seeing the shield, they "know" they're going to get one. (In their
normal working lives, of course, they should /never/ see one of these,
but that's a different issue).
Post by smilek
I have two identical binaries, one installed by the installer
(avscc.exe) and the other placed into a directory manually
(avscc1.exe)
(If I rename avscc.exe to avscc2.exe, the UAC shield goes away. If I rename
avscc1.exe to avscc.exe, the UAC shield occurs. So, it looks like the shield
is associated with the name of the binary, not the binary itself.)
Each program has a "manifest" associated with it - sometimes this is a
separate (.manifest) file alongside the .exe, sometimes it's embedded
within the .exe. Either way, I suspect your program has one that
requires elevation, i.e. the user will get a UAC challenge when they run
it.

If you rename the .exe so that it no longer matches the the .manifest
(or vice versa), then Windows no longer realises that this program needs
elevation and so doesn't show you the shield. However, the program will
still demand elevation as soon as the program tries to do something
"powerful". This is /not/ a Good Thing. The first part of the program
will run at the "normal" level and the rest, after elevation, at the
"higher" level; the two levels do not see the machine equally, for
example files that are created at one level may not be where the other
level expects them to be, causing problems. It's far better to /start/
elevated, if that's where you need to go.

HTH,
Phill W.
smilek
2010-07-19 19:21:23 UTC
Permalink
1. We have an executable that has a manifest requiring admin privileges
embedded in it. We'd like to get rid of the requirement, since the executable
does not in fact need to run with elevated privileges.
2. We take the admin privileges requirement out of the manifest.
3. We rebuild the executable -- it no longer has a UAC shield over it.
4. We build an installer containing this same executable -- install it on a
Win 7 system where the product has never been installed before. The
executable does not have a UAC shield over it and runs without a UAC prompt.
5. We install the installer on a system where the product was installed
before - the executable still has a UAC shield over it after installation. If
renamed or moved though, it loses the UAC shield.

Also, when we use install the product on a system where it was installed
previously, but override the default directory for the installation, the
executable does not have a UAC shield.

Additionally, the behavior as described does not occur on all Windows 7
machines. We have tried several Windows 7 installations where the UAC shield
does not appear after installing on a system where the product was previously
installed. What is consistent is that for any given Windows 7 machine where
the problem occurs, it will continue to occur even if, before installing, we
first uninstall and delete the directories that the installer creates.

This seems like a Microsoft bug that has been fixed in a recent patch. But
we need to gain an understanding here so that we can take the appropriate
steps with our customers.
--
Steve Milek
Post by Phill W.
Post by smilek
Why does UAC block certain binaries from execution?
Because that's its job?
Post by smilek
How can I get rid of the UAC shield over the binary?
Why would you want to?
The shield is a visual indicator (to the user) that they require
elevated permissions to run this program. Without it, they'd get
"unexpected" UAC challenges popping up that would scare them silly.
Seeing the shield, they "know" they're going to get one. (In their
normal working lives, of course, they should /never/ see one of these,
but that's a different issue).
Post by smilek
I have two identical binaries, one installed by the installer
(avscc.exe) and the other placed into a directory manually
(avscc1.exe)
(If I rename avscc.exe to avscc2.exe, the UAC shield goes away. If I rename
avscc1.exe to avscc.exe, the UAC shield occurs. So, it looks like the shield
is associated with the name of the binary, not the binary itself.)
Each program has a "manifest" associated with it - sometimes this is a
separate (.manifest) file alongside the .exe, sometimes it's embedded
within the .exe. Either way, I suspect your program has one that
requires elevation, i.e. the user will get a UAC challenge when they run
it.
If you rename the .exe so that it no longer matches the the .manifest
(or vice versa), then Windows no longer realises that this program needs
elevation and so doesn't show you the shield. However, the program will
still demand elevation as soon as the program tries to do something
"powerful". This is /not/ a Good Thing. The first part of the program
will run at the "normal" level and the rest, after elevation, at the
"higher" level; the two levels do not see the machine equally, for
example files that are created at one level may not be where the other
level expects them to be, causing problems. It's far better to /start/
elevated, if that's where you need to go.
HTH,
Phill W.
.
Loading...