.net 1.1 EXE in startup folder on VISTA

  • Thread starter Thread starter AC
  • Start date Start date
A

AC

Our application installs a .NET 1.1 EXE created with VB.NET into the startup
folder on the PC. This works perfectly on Win98SE and XP. If the User
Access Control is OFF on Vista, it also works perfectly there. However, if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>

It didn't help.

Any way to get this program to launch even if the UAC is turned on? Users
can launch it by right clicking and allowing it to run, but how can it run
normally, like it does on XP, Win98 or Vista when the UAC is off?
 
Hello,

Applications that will request from the user permission to run (when
UAC is enabled) are blocked from being started in this manner.

A few reasons this is so:

- The user may not be around to approve the application to start when
the computer starts up or the account is logged on

- The user would find it very annoying to have to approve your
application (and possibly multiple applications) to start every time
they log on

To "get around" this limitation, instead of putting your application
in the startup folder, you can put your application in a secure
location (such as Program Files, which is required for uiAccess=true
btw, are u sure u really need uiaccess?), and then create an entry in
the task scheduler for the administrative user(s) that want your
application to run whenever they log in, specifying your application
to run on user log-on condition as well as specifying that the
application should run with highest privilege.

This will allow your application to start "elevated" on the admin's
desktop when the specified administrator(s) log in, without prompting
them for permission.

You can use this task scheduler method for non-admin users, but you
are not able to specify that the application run with "highest
privilege" for non-admins.

If you do, the application will start with highest privilege when the
non-admin logs on, but it will start non-interactively in Session 0
(the services session).

With UAC enabled, non-admin users should be able to put your program
(with the manifest you described) in their startup folder or in the
user-specific "run" registry key without being blocked.

Our application installs a .NET 1.1 EXE created with VB.NET into the startup
folder on the PC. This works perfectly on Win98SE and XP. If the User
Access Control is OFF on Vista, it also works perfectly there. However, if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>

It didn't help.

Any way to get this program to launch even if the UAC is turned on? Users
can launch it by right clicking and allowing it to run, but how can it run
normally, like it does on XP, Win98 or Vista when the UAC is off?
Click to expand...




- JB
Microsoft MVP - Windows Shell/User
Windows Vista Support Faq http://www.jimmah.com/vista/
 
Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory (unfortunately,
I'd love it to be, but the clients AND support staff of our clients do not
want it there).

I need the program to launch when the user logs in. It's OUR task scheduler
which checks for updates, synchronizes with our server, etc etc. It has an
UI. It sits in the task tray, and allows the user to show it to see the UI.

I'm not 100% following what you say, but I need to have this happen from our
install program. I can't expect the users to do anything on their end.
 
Basically, what I am saying, is that if your program needs
administrator privileges AND needs to be interactive on the desktop
AND needs to be running on every administrative user's desktop that
uses the computer, you need to have the task scheduler start your
program instead of Windows Explorer (which starts programs in the
startup folder).

Windows Explorer cannot start elevated applications without prompting
the user (which is blocked for startup apps), Task Scheduler can.

If *only* administrators will use your program, or all users on the
computer are administrators, you can have your installer register your
program with Windows' task scheduler, as i mentioned in my last post,
and instruct the task scheduler to start your program when
administrators on your machine log in.

This will do what you want, but only for administrator accounts on the
computer.

The task scheduler is just an alternate way of having your program
start that will work on vista, as opposed to putting it in the startup
folder (which doesn't work for your needs).

You can use the task scheduler API's inside your setup program to do
this without requiring the end user to do anything special.

If your program UI needs to run inside both standard user and
administrative accounts, then your program should be rearchitected so
that the UI runs as a non-privileged application and the privileged
core runs as a Windows Service.

In fact, based on what you've said about your application, this might
be a better way to implement your application.


Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory (unfortunately,
I'd love it to be, but the clients AND support staff of our clients do not
want it there).

I need the program to launch when the user logs in. It's OUR task scheduler
which checks for updates, synchronizes with our server, etc etc. It has an
UI. It sits in the task tray, and allows the user to show it to see the UI.

I'm not 100% following what you say, but I need to have this happen from our
install program. I can't expect the users to do anything on their end.
Click to expand...


- JB
Microsoft MVP - Windows Shell/User
Windows Vista Support Faq http://www.jimmah.com/vista/
 
I should also add that it is *critical* that your program be installed
in a security-restricted folder. If you can't use a system folder, you
need to make sure that whatever folder your app is installed in is
security restricted so that non-admin users cannot write to it.

If non-admin users have write access to your program, they may be able
to replace your program with any other program of their choosing,
which will be ran with admin privileges the next time an admin logs on
to the computer, and easily gain control over your computer.

- JB
Microsoft MVP - Windows Shell/User
Windows Vista Support Faq http://www.jimmah.com/vista/
 
We can't rearchitect the application. We need to support Win98, and we need
it to run the way it is. Most (98%?) run our program as a startup
program, but some do not. Without getting too detailed, we can't change the
application that dramatically.

Our testers took the manifest file I gave them, and when they put it in
play, all of a sudden the Blocked Programs popup bubble did not come back
when they restarted. HOWEVER, the program did not seem to do as expected.

We need the application to run whether it's an admin or not an admin.
Obviously, an admin installs our app, but from that point, in most cases,
the same account will run the application, but in others, it will NOT be an
admin running the program.

Scheduling via a task scheduler sounds promising, but I need to be able to
do this automatically via our installer, and not rely on the users to do
that. Are there registry settings/etc I can set? Is there something in my
manifest that can be done to get this to work?

Our startup "program" does the following:

1) Checks a folder on the local PC to see if an update has been downloaded
by our updater (happens during our auto synchronization every evening, and
if an update is there)

2) Once the update files areput in their proper places, it launches another
EXE, but stays in memory. It monitors this EXE it launched, and if it is
shut down, with the right exit code, it knows it's time to apply the update
and relaunch. If it exits normally, then it just closes itself as well..
 
I need admin and non-admin users alike to be able to write to the
folder..... Our software update process requires it (whatever user is
logged in admin or not admin need to be able to do this). A lot of our
installs are single, stand alone machines.....
 
So your application doesn't need admin privileges at all?

OK ... I guess I glazed over 'asInvoker' in your manifest and thought
it said 'highestAvailable'.

If your app doesn't need admin privileges under any circumstances,
then you are doing everything correctly, you don't need to use task
scheduler, and it should be working...

Try removing 'uiaccess=true' from your manifest.
 
Yeah I missed the fact that your app never needs admin permissions.

But if it did, and you were in this same scenario, then you can just
set the stricter permissions on the app's exe and config files, while
allowing the folder that it resides in to accept new files.
 
Thanks Jimmy..

Got this feedback from our testers (no vista machine in front of me).

If they put the manifest file in play, they get this error even when
launching the EXE manually, not at startup:

A referral was returned from the server.

However, if they remove the manifest, they can launch the program manually
(they are asked to cancel or allow, but if they allow, all is OK)
 
Ok, the "referral returned from server" is because your manifest has
uiaccess=true but your exe is not signed with a digital certificate.

Based on what you have said, your application should not need
uiaccess=true, so I would suggest removing that line from the
manifest, and it should make things work as you expect.

I am confused about it asking for continue/cancel without a manifest
though... it should just run without asking anything.

- JB
 
Your testers will also need to log off/log or possibly reboot the
computer after updating the manifest, as it seems Windows caches the
contents of the manifest and stops looking at the manifest file once
it is loaded into memory, ignoring any changes.

- JB
 
Jimmy,

I tried this, and got this feedback:

"OK - I copy the X.exe.manifest file that you included into the C:\X folder
and rebooted. After I logged on, I received the Windows has Blocked Startup
Programs message. When I try run the blocked startup program, nothing
happens. If I try to run the Xt from the Startup folder, nothing happens. If
I delete the manifest file and try to run the same program, it runs after I
get prompted for cancel or allow"

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>

Any advice?
 
I tested that manifest and it works on my computer.

I renamed an application that does not contain a manifest to
update.exe (which triggers Windows to ask for elevation for that
application).

I then created a link to this app into the all user's startup folder.

I then logged into another admin account and the program was blocked
from running.

I logged out from that account, added the manifest file you described
from another account, logged back in, and the program was allowed to
run without prompting the user.

So ... I am stumped now as well.

- JB
 
Back
Top