iReboot on Vista Startup

S

_schandl

Member
I installed iReboot and it is a great little tool. But when I start Vista, I get the message that an autostart program was blocked. I can start IReboot manually, but I wonder what the reason might be. There is a manifest file in the iReboot directory so the permissions should be ok. But what else might be the reason for the error message?

Best regards,
Bernd
 
Hi Bernd, welcome to NeoSmart Technologies.

Windows Vista's "advanced" security doesn't let you run any program that requires admin permissions at startup. Because iReboot requires that you OK the elevation request for UAC-enabled machines, Vista will block it. No way around that, unfortunately.
 
This is because of the UAC. If you right click on the executable then choose properties, under the the Compatability tab. In there they have a option to Run as Administrator. Check that box and click ok. That should give it the elevated permissions to run at startup. That might the work around you are looking for.
 
Mak, does that work for everyone with or without UAC enabled?
If so, I think I can hack the installer to set that option by default!
 
Without UAC enabled it shouldnt be a problem. I have 2 accounts now on my Vista install. The default account with UAC on and the Admin with it off. So i will test it out real quick and post back with results.

Addendum:

Alright after further testing this on my 2 accounts i can up with this.

The Admin account which has UAC disabled. No problems. The REgular account with UAC on i get the error. Even if i try to give it admin privileges. I am now going to test if giving that account no UAC control if i still get this error. IF that happens then my guess was right that the UAC is causing the issue. Then the only question comes in can you figure out how apps like AnyDVD run at startup with out this limitation. If so then that would be the way i would say to get around this bugger of a issue.

Addendum:

Alright yet again here are my finding. Just as with the Admin account with the UAC off i dont get any prompts about needing the rights for iReboot to run. So it is totally the UAC that is causing this issue for you Guru. Find a way around it like AnyDVD, uTorrent or any of those other apps that dont get prompted for rights upon startup and you are golden.
 
Last edited:
No it doesnt. That is what i am trying to get at. It will run on startup without admin rights. If you can figure out how they did that then you can get iReboot to work that way and this wont be a issue anymore. :wink:
 
Ah, see that's the problem.

You can't run iReboot at all, at any time without admin rights, that's what I was trying to explain above.

iReboot requires admin rights to be able to do what it does. Windows Vista doesn't let an application that requires elevation to run at startup if UAC is enabled -- and there's the problem.

iReboot needs admin, and needs startup. Vista won't let an app that needs admin run at startup if UAC is enabled.
 
What about something like Avast. Doesnt that need Admin right? There has to be a way for Vista to run a application with elevated rights at all times if it is needed.

John Robbins' Blog : Elevate a Process at the Command Line in Vista

Something like this. Elevate is what he calls it. Isnt there a way to incorporate that into iReboot and make it run with elevated rights full time to bypass this nag from the UAC?

Windows Vista - ConsentPromptBehavior ConsentPromptBehaviorAdmin UAC

That has some very interesting info as well.

Making Self-Extracting Packages for Windows Vista compatible with UAC

This might be useful as well. Just some ideas on how to get past the UAC and get iReboot to work with UAC on but not get bugged by it on every startup.
 
I'm already doing what the last link recommends - it's what makes iReboot request elevation in the first place and not simply fail when you try to run it with UAC installed.

At the moment, this is what iReboot does.

Run. Put in a request for elevation. If not given, exit. If given, save it in a safe place.
When iReboot needs to modify bootloader settings (every time you change an option in it), it'll reuse the saved elevation.

The (very crappy) way MS designed UAC, my only other option is as follows:
Run iReboot without elevation (no problem running it at startup now). When a user attempts to change an iReboot option, ask for elevation. When a user changes another option, ask for elevation again.

I opted for the former, because the latter can quickly get very, very annoying for end users.

Unfortunately (unlike on Linux) Microsoft has not made it possible for users to mark an application as trusted and that though it requires admin rights it can be run by normal users.

This option exists in Windows Server 2003, but not in Vista or LH Server.

I am genuinely stumped, because Microsoft did this on purpose. The only way around it is to install kernel drivers, and I'm not about to do that!

Here's where the UAC program manager touts this as an amazing and ingenious bit of research and an awesome way to give users an all-around better experience:
Elevations Are Now Blocked in the User's Logon Path - KezNews.com

I want some of what he's smoking..... He recommends running programs "asInvoker" meaning the program itself checks what rights a user has and only lets them do stuff within those boundaries.... But WTF do you do when your program does just one thing, and it requires admin rights??

Obviously he never bothered to write a system-managment program on Vista!
 
I cannot help with the implementation stuff of UAC, but I pondered the possibilities you mentioned. Two questions:
  1. Isn't it possible to save the elevation with the second option as well?
  2. Why does the second option get annoying? There are at most two settings a user will change during a session: "Reboot on selection yes/no" (he will probably do this only once) and choosing the OS to boot next time.
So if (1) is not possible, I would prefer entering my password when choosing a OS to boot. The 99% of my time where I don't choose an OS to boot, I don't have to do anything.

Just my 2c
Bernd
 
Unfortunately, you can't save the elevation request if it's running asInvoker.

That's definitely possible - I'll look into it some more and keep everyone posted.

Thanks for the feedback :smile:
 
This topic hasn't been updated lately. Any new info?

I just installed iReboot and of course, I see the same problem - it gets blocked on boot up. But, are you sure this is an elevation issue? What I'm seeing isn't an issue with administrative access, it's because the program is unsigned.

When I run the program manually (from the Start menu), I get the "An unidentified program wants access to your computer" window asking me to allow or deny. This is a UAC window, but it's asking me if I trust the program. This is different than asking me to elevate it's status to administrator. So, as best I can tell, it's because the program isn't signed, that's why it isn't loading at boot. Either that, or it's a combo of administrator elevation and being unsigned.

Or, am I totally off here.
 
Hi Darkoz, welcome to NeoSmart Technologies!

What you see when you run EasyBCD is a UAC prompt for an admin-elevation request coming from a unsigned app. If it were signed, you'd still see a UAC prompt for admin-elevation - it just wouldn't be that garish shade of yellow.


As to the topic:
Antivirus programs get around this restriction by installing a driver or service and interacting with it. The service runs, as all services do, with the system account which needs no elevation. The client program runs in user mode and communicates with the service, thereby eliminating any need for elevation in the first place.

So, yeah, it's an elevation issue. And I still have no idea what's the best way of dealing with it :/


The good news is.... well not much. But MS has finally drafed up decent documentation for this which says "You stupid developers, you cannot ever run a program with elevation at startup!!":

In previous versions of Windows, independent software vendors (ISVs) may have elected to place programs in the user logon path to ensure that they run each time a user logs on. While this solution may be convenient, it often results in application compatibility problems when the user is not an administrator. In addition, research also shows that a growing number of enterprise customers want to deploy their desktops as standard user. This poses a growing problem for applications that require administrator privilege to run in the user logon path, not only on Windows Vista, but also on previous version of Windows. These applications will fail to run and make configuration and administration more difficult. When a user logs on, applications that require elevated privileges, and are in the user logon path, require a full administrator access token. As a result, the user is displayed a User Account Control dialog box either requesting approval or credentials. To compound the problem, the user has no way to tie the elevation request to a specific application. To avoid this poor user experience, Windows Vista blocks applications that require elevation in the user logon path. This functionality also helps thwart malicious software that may place itself in the user logon path.
Click to expand...

Sorry, but I thought it was up to the developer to decide what type of user experience their programs have??!?

From here: Developing Applications that Run at Logon on Windows Vista


Their solution is, as I had previously deduced, to write a service engine to do this behavior for me.


*breathes*

This is possible, and not the end of the world. I've written plenty of services before (ToolTipFixer is one) but it just takes time......

:x
 
Makes sense, except that I set iReboot to run as administrator, and it still gives me the unknown app request when I run it manually.

Regardless, I suppose then the easy answer is don't ask to be elevated until the user actaully changes a setting. Seems the main purpose of iReboot is to actually reboot the PC, so when ever I do this in Vista, I don't mind clicking on iReboot to select my new OS, and then accepting the elevation request at that point and having iReboot then reboot my PC for me (that's what iReboot is for). What is really anoying, though, is having to accept and run the program every time on boot up.

Thanks.
 
Yes, that's correct. If it were signed you wouldn't get that warning if it were set to run as administrator.

But it still wouldn't run at startup.

The service option is looking increasingly more enticing, I had a go at the code and it wasn't as difficult as I thought it might be.
 
For what it's worth, here's my experience.
I got so p****d off with the boot time nag in Vista (and I couldn't use iRB in XP because NET 2.0 wasn't there - (reason why in another thread)) that I took it out of startup and as a consequence I keep forgetting it's there and have basically stopped using it.
Ideally I'd love to have a "boot Vista" Icon in XP and a "boot XP" Icon in Vista just sitting there waiting to be used if needed, so my take is that the second design scenario would be preferable - Don't annoy UAC till you have to, at least that way the nag is restricted to the sole occasion that you're going directly from V to X , and not every single V boot.
I'll get NET 2.0 sorted in XP when I've overcome my 0x80200010 WUD problem, then everything would be Hunky Dory (given design 2 is implemented)
Perhaps the "include at startup" option could use design 2 and if not ticked - design 1 ?
 
Well, it's already been patched by msoft, so I doubt it'd be of much use :smile:

I already know what needs to be done (going the service route) - just when to get around to it is the question.. :S
 
Back
Top