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

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 -

"Joseph Geretz" <jgeretz@nospam.com> wrote in
news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl:

> 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

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 -

"kpg" <no@spam.com> wrote in message
news:Xns98E38136D7B73ipostthereforeiam@207.46.248.16...
> "Joseph Geretz" <jgeretz@nospam.com> wrote in
> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl:
>
>> 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
>
>

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

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:O04AV0dWHHA.1208@TK2MSFTNGP03.phx.gbl...
> 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 -
>
> "kpg" <no@spam.com> wrote in message
> news:Xns98E38136D7B73ipostthereforeiam@207.46.248.16...
>> "Joseph Geretz" <jgeretz@nospam.com> wrote in
>> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl:
>>
>>> 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
>>
>>
>
>

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.

--
Jon


"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:OTF78yeWHHA.5068@TK2MSFTNGP03.phx.gbl...
> 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
>
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:O04AV0dWHHA.1208@TK2MSFTNGP03.phx.gbl...
>> 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 -
>>
>> "kpg" <no@spam.com> wrote in message
>> news:Xns98E38136D7B73ipostthereforeiam@207.46.248.16...
>>> "Joseph Geretz" <jgeretz@nospam.com> wrote in
>>> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl:
>>>
>>>> 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

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



--

Ronnie Vernon
Microsoft MVP
Windows Shell/User


"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl...
> 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 -
>
>
>

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 -

"Ronnie Vernon MVP" <rv@invalid.org> wrote in message
news:371B78EE-DE04-4A42-824D-A54F35505EF4@microsoft.com...
> 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
>
>
>
> --
>
> Ronnie Vernon
> Microsoft MVP
> Windows Shell/User
>
>
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl...
>> 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 -
>>
>>
>>
>

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 *
* * * * * * * * * * * * * * * * * */

"Jon" <Email_Address@SomewhereOrOther.com> wrote in message
news:%23zSTJdfWHHA.3980@TK2MSFTNGP02.phx.gbl...
> 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.
>
> --
> Jon
>
>
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:OTF78yeWHHA.5068@TK2MSFTNGP03.phx.gbl...
>> 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
>>
>> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
>> news:O04AV0dWHHA.1208@TK2MSFTNGP03.phx.gbl...
>>> 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 -
>>>
>>> "kpg" <no@spam.com> wrote in message
>>> news:Xns98E38136D7B73ipostthereforeiam@207.46.248.16...
>>>> "Joseph Geretz" <jgeretz@nospam.com> wrote in
>>>> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl:
>>>>
>>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

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 *
* * * * * * * * * * * * * * * * * */

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:O3YYeFgWHHA.4028@TK2MSFTNGP04.phx.gbl...
> 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 -
>
> "Ronnie Vernon MVP" <rv@invalid.org> wrote in message
> news:371B78EE-DE04-4A42-824D-A54F35505EF4@microsoft.com...
>> 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
>>
>>
>>
>> --
>>
>> Ronnie Vernon
>> Microsoft MVP
>> Windows Shell/User
>>
>>
>> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
>> news:uG10cpcWHHA.4384@TK2MSFTNGP02.phx.gbl...
>>> 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 -
>>>
>>>
>>>
>>
>
>

On Mon, 26 Feb 2007 23:15:53 -0600, "Robert Firth"
<webmaster@winvistainfo.org> wrote:

>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.