Why won't my EXE run under Vista with UAC Enabled?

[Joseph Geretz]

My application is comprised of a number of discrete deployment artifacts:

1. A bunch of ActiveX DLL's
2. The Main Application Executable (MainApp)
3. AutoUpdater - ActiveX EXE
4. A variety of utlity applications.

Everything runs fine with UAC disabled. With UAC enabled, I encounter the
following issues:

1. The main application launches, however it fails when it attempts to
create an instance of the AutoUpdater:

Automation error: The requested operation requires elevation.

2. When running the AutoUpdater directly from the Windows shell, I get the
User Account Control dialog: An unidentified program wants access to you
computer.

Unidentified??? Why is this specific executable any more unidentified than
the rest of my application? My application ships with a number of associated
utility application as well as the main application executable. All of these
launch just fine at the user's request. Why is this program specifically
singled out as suspicious when launched directly by the user, and to require
elevation when launched programatically as an ActiveX server?

BTW, we deploy another utility application which is also constructed as an
ActiveX EXE and this one runs just fine, raising no flags at all, whether it
is run directly from the Windows shell, or whether it is launched
programmatically from a client program. So what is it about the AutoUpdater
specifically which cause problems? Having unleashed UAC on us, does
Microsoft provide any guidelines, or any tool which can analyze a program or
its Source and make recommendations about what will require elevation?

Thanks for any advice which you can provide.

- Joseph Geretz -

 

[kpg]

My application is comprised of a number of discrete deployment
artifacts:

1. A bunch of ActiveX DLL's
2. The Main Application Executable (MainApp)
3. AutoUpdater - ActiveX EXE
4. A variety of utlity applications.

Everything runs fine with UAC disabled. With UAC enabled, I encounter
the following issues:

1. The main application launches, however it fails when it attempts to
create an instance of the AutoUpdater:

Automation error: The requested operation requires elevation.

2. When running the AutoUpdater directly from the Windows shell, I get
the User Account Control dialog: An unidentified program wants access
to you computer.

Unidentified??? Why is this specific executable any more unidentified
than the rest of my application? My application ships with a number of
associated utility application as well as the main application
executable. All of these launch just fine at the user's request. Why
is this program specifically singled out as suspicious when launched
directly by the user, and to require elevation when launched
programatically as an ActiveX server?

BTW, we deploy another utility application which is also constructed
as an ActiveX EXE and this one runs just fine, raising no flags at
all, whether it is run directly from the Windows shell, or whether it
is launched programmatically from a client program. So what is it
about the AutoUpdater specifically which cause problems? Having
unleashed UAC on us, does Microsoft provide any guidelines, or any
tool which can analyze a program or its Source and make
recommendations about what will require elevation?

Thanks for any advice which you can provide.

- Joseph Geretz -

Mostly to commiserate, but perhaps my apps behavior will shed light on
this issue for someone that understands such things:

I have an app that calls (shells) to other apps as follows:

Launcher.exe -> main.exe <-> updater.exe

(The shelled from app terminates in each case. so only one instance
is running most of the time)

That is, Launcher is run by the user, it launches main, then on
occasion the user will update, so main shells to update, then
terminates, when complete, update launches main (then terminates).

Now, launcher can shell to main, the only problem (when UAC
is on) is that Main cannot shell to updater, however, if updater is
called directly, it can shell to main, then main can shell to updater.

So on the surface, it looks like only one level of shelling is being
allowed - but that could just be a coincidence.

kpg

 

[Joseph Geretz]

Hi kpg,

Thanks for your response.

Your situation is somewhat similar to my own. In our case, MainApp.exe
creates a running instance of AutoUpdate.exe.

(AutoUpdate is an ActiveX EXE; in this case running as a server to MainApp,
but also capable of running directly from the Windows shell)

Here is the specific line of code which is failing:

Set Agent = CreateObject("AutoUpdate.Agent")

Since AutoUpdate is an ActiveX EXE, the creation of the class instance
triggers the creation of a new process, which for whatever reason requires
elevation.

OK, so SRSAutoUpdate requires elevation. I don't know why, but for now I'll
take that as a given. Here is some additional information.

If I run MainApp as Administrator, then I get the dialog, unidentified
program, blah blah blah. However, after I respond to the dialog, the
application runs properly. It's clear that once MainApp is trusted for
elevation, it is capable of launching a secondary process which requires
elevation.

OK, so we're getting places. I don't want users to have to deal with
explicitly requesting administrative priviledge to run the application. So I
created the following manifest file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="5.2.0.22"
processorArchitecture="X86"
name="MyApp.exe"
type="win32"/>
<description>elevate execution level</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

I named this MyApp.exe.manifest and dropped it into the application folder.
Supposedly, this should achieve the same result as manually requesting Run
as Administrator, but this doesn't have any effect. Any idea why not?

Thanks for any advice which you can provide!

- Joseph Geretz -

 

[Joseph Geretz]

AAAAAAaaaarrrrggggggghhhhh!!!!!!

It's the NAME of the executable, AutoUpdate, which makes Vista THINK
(assuming
that this brain-dead OS is capable of such a thing) that the process needs
to run elevated.

kpg, this explains your issue as well; In your case it's that third app in
the chain which has the magical term 'update' in it, for me it's the second.
Who the !#$%@$# slapped this so-called OS together, J.K. Rowling?

:-(

Joseph Geretz

 

[Jon]

That was a good find. Appears to apply only to the .exe extension (eg
update.dll is fine). I wonder if there are any other keywords like that to
avoid.

May help others that are having problems with software that includes an
updater.

 

[Ronnie Vernon MVP]

Joseph

These newsgroups are typically for end users of Windows. Have you tried
posting this question to the developer forums? This is where the application
developers congregate and there are many Microsoft employees and independent
developers that post to those forums. There is likely someone there who has
already worked their way through, and found a solution, for the problems
that you are having.

MSDN Forums:
http://forums.microsoft.com/MSDN/default.aspx?SiteID=1

 

[Joseph Geretz]

Thanks Ronnie,

Actually, I crossposted this (ooohhhh!) to vista.security.

Anyway, I've got the problem figured out. I used the literal string 'Update'
as part of the name of my executable without getting permission from my
Mommy. This caused Vista to panic. Very sophisticated security algorithms in
place I see. Based on the filename.

Sheesh!

- Joseph Geretz -

 

[Robert Firth]

Magic keywords "setup", "update"...

Old installers were not written properly to ask for proper permissions to
install an app (admin privileges). To get around the hassle of having to
manually right click on virtually every installer and select "Run as
Administrator" forced them to search for those keyworks in the .exe name and
auto-elevate (actually auto-ask to elevate).

--
/* * * * * * * * * * * * * * * * * *
* Robert Firth *
* Windows Vista x86 RTM *
* http://www.WinVistaInfo.org *
* * * * * * * * * * * * * * * * * */

 

[Robert Firth]

Based on filenames and wheter or not you asked for administrative
privileges. If it is an application setup, it will need administrative
privileges to write to c:\program files. Therefore, it makes since to
auto-elevate setup programs - assuming you trust the developer.

--
/* * * * * * * * * * * * * * * * * *
* Robert Firth *
* Windows Vista x86 RTM *
* http://www.WinVistaInfo.org *
* * * * * * * * * * * * * * * * * */

 

[Adam Albright]

Magic keywords "setup", "update"...

Old installers were not written properly to ask for proper permissions to
install an app (admin privileges).

The old it ain't Microsoft's fault excuse. Interesting, that seems to
be more a MVP excuse considering what high ranking Microsoft officials
admit to:

Item: Jesper Johansson, a senior security strategist in the Security
Technology Unit at Microsoft, admits that the current implementation
of UAC presents too many privilege escalation pop-up prompts, but he
insists there is a method to the apparent madness.

"Unless we get feedback on what works and what does not, we can't fix
it. If you disable critical technologies that we are trying to get to
work, we can't fix them," Johansson said in a blog entry. "That means
that, yes, some things will be annoying and not work quite right in
the final release, unless people work with us to fix them," he added.

Item: Microsoft has granted, in a roundabout way, that Vista has 'high
impact issues.' It has put out an email call for technical users to
participate in testing Service Pack 1, due out later this year, which
will address 'regressions from Windows Vista and Windows XP, security,
deployment blockers and other high impact issues.'

It's hard to know whether to be reassured that Service Pack 1 is
coming in the second half of 2007, and thus that there is a timeframe
for considering deployment of Vista within businesses, or to be
alarmed that Microsoft is unleashing an OS on the world with "high
impact issues' still remaining, according to Microsoft.

 

[Joseph Geretz]

Magic keywords "setup", "update"...

Old installers were not written properly to ask for proper permissions
to...

And so we sink to the lowest common denominator. Instead of actually
detecting operations which require elevation, Vista take the extremely
sophisticated approach of string detection on the filename!!!???

You're not seriously suggesting that this is a serious OS implementation,
are you?

- Joseph Geretz 0

 

[DevilsPGD]

In message <[email protected]> "Joseph Geretz"

And so we sink to the lowest common denominator. Instead of actually
detecting operations which require elevation, Vista take the extremely
sophisticated approach of string detection on the filename!!!???

Fair enough -- Do you have a better suggestion that maintains backwards
compatibility?

 

[Joseph Geretz]

Fair enough -- Do you have a better suggestion that maintains backwards

compatibility?

Yes, as I suggested:

But that's too tricky?

- Joseph Geretz -

 

[Ronnie Vernon MVP]

Adam

I don't see anything in that quote that conflicts with the statement that
you see as an excuse. The users are the people who need to put pressure on
the developers to follow the current Microsoft standards for writing
applications and programs for Vista. These program developers have had more
than ample time to respond to the many calls by Microsoft to learn and
follow the new programming guidelines.

We all knew that the changes in Vista would be "high impact issues" but the
overwhelming reason was the state of the security in previous versions. UAC
is not going to go away in SP1.

 

[Joseph Geretz]

the developers to follow the current Microsoft standards for writing

applications and programs for Vista.

All right, I'll call you on it, and if you can help me out or point me in
the right direction, I'll be grateful for your help.

What are the guidelines for deploying and registering an ActiveX EXE on
Microsoft Vista with UAC enabled?

Simple question. I'm one of the devleopers you speak of, and I very much
wish to follow the new programming guidelines. It's one thing to talk about
guidelines, and quite another to actually define and publish them. I've been
Googling and asking questions for days now, trying to find out what the
guidelines are for deploying ActiveX EXE with UAC enabled. So please, what
are the guidelines?

Thanks,

Joseph Geretz
Microsoft VPD
Very Pissed Developer!

 

[Ronnie Vernon MVP]

Joseph

Here are some links to get you started.

Developer Best Practices and Guidelines for Applications in a Least
Privileged Environment:
http://msdn2.microsoft.com/en-us/library/aa480150.aspx

Look near the bottom of this link for a downloadable help file on developing
ActiveX Controls for Vista.
Windows Vista Application Development Requirements for User Account Control:
http://msdn2.microsoft.com/en-us/library/aa905330.aspx

Security in Longhorn: Focus on Least Privilege:
http://msdn2.microsoft.com/en-us/library/aa480194.aspx

You can access the Vista Developer forums here and dialog with other
developers who doing the same work that you are.
http://msdn2.microsoft.com/en-us/windowsvista/aa905020.aspx

Google Search:MSDN2
http://tinyurl.com/2kq25h

 

[Joseph Geretz]

Hi Ronnie,

Unless I missed it, the questions of installing an ActiveX EXE is *not*
addressed in any of the links you reference. Your allusion to developers who
are not following 'Microsoft guidelines' is nothing more than apologetics
for Microsoft's abysmal practice in this regard. Microsoft has changed the
rules of the game radically, without fully considering all of the
implications and without providing developers with adequate documentation.

So again, I challenge you. Where is the documentation, the guideline if you
will, on how to install an ActiveX EXE using a custom action from within an
MSI setup file? Not from within an EXE setup file, that will work - but from
an MSI setup file. Although, why an MSI should operate under different rules
than the equivalent EXE is beyond me, but no doubt you can cite a
'guideline' which will explain this to us?

- Joseph Geretz -

 

[Guest]

My understanding is the manifest (this type of manifest) must be in the exe.
Everything I've read says to put in exe. There is no mention of other ways
(incl warnings). I suppose it stops people dropping manifest files about
allowing elevation of other's programs..

 

[Joseph Geretz]

My understanding is the manifest (this type of manifest) must be in the

exe.

How do I put the manifest 'in the exe'? Can you please elaborate on how to
do this?

Thanks!

- Joseph Geretz -

 

[Guest]

With a compiler. I guess the intent is the program vendor does it.

You could try, if you don't have a Resource Compiler (what language do you
write in - VB even has one), something like Resource Hacker (search on
google) which decompiles and recompiles resources in executables.

Also I didn't follow the links someone else gave you, but I thought the
following was mentioned on them - just in case not, MS has a tester for
programs that indicate if it may run into problems (and what problem). It's
a related download to App Compatability Kit. It runs your program and see's
what it does.