Why didn’t Windows XP auto-elevate programs beyond those named setup.exe?

Commenter J-F has a friend who wonders why Windows XP didn't auto-elevate all installers but rather only the ones named setup.exe. (Perhaps that friend's name is Josh, who repeated the question twelve days later.)

Remember what the starting point was. In Windows 2000, nothing was auto-elevated.

Before adding a feature, you have to know what problem the feature is trying to solve. The problem is improving the experience for non-administrators who want to install software. When they try to install a program and forget to use the Run as feature, then instead of proceeding halfway through the installer and then getting an Access denied error, do the Run as for them automatically.

Knowing whether the user is running an installer that requires elevation requires a degree of semantic analysis beyond what you want to add to the Create­Process code path. Hey, here's a program called PRONT4.EXE. Is it an installer? Turns out that it is. And then there are the programs that might be installers, depending on what other command line switches you provide.

Given that you're reduced to a heuristic, you have to decide what the acceptable rates of false positives and false negatives will be. If you guess wrong and think a program requires administrator privileges when it doesn't, then you've screwed over all the non-administrators who want to use the program. "I used to be able to run this program, but now when I try, I'm asked for the administrator password, which I do not know. Windows broke my program." The effect of a false positive is My program stops working.

On the other hand, if you fail to detect a program that requires being run with administrator privileges, the behavior is the same as before: The user gets an Access denied error. The effect of a false negative is No change.

Given that the cost of a false positive is huge and the cost of a false negative is zero, you can see that the math says to use a conservative heuristic. The heuristic is that a program named setup.exe will be treated as an installation program, and nothing else.

Windows was under no obligation to auto-detect installation programs. Indeed, according to the strict interpretation of operating system design, it shouldn't do this. If the user says to run this program at the current privilege level, then you darned well better run the program with the current privilege level. The treatment of programs named setup.exe is really just a compatibility hack, a courtesy to make your life a little bit easier.

It's a case of giving somebody five dollars and being asked why you didn't give them ten.

Starting in Windows Vista, applications can specify via a manifest whether they want to run at the privilege level the user requested (requested­Execution­Level level="as­Invoker") or always to elevate to administrator (requestedExecution­Level level="require­Administrator"). Hopefully, all new applications will specify their elevation requirements explicitly, and the heuristic will be necessary only for old programs. ­e>

Comments (43)
  1. R. Bemrose says:

    Unfortunately, I know one application that misuses the Vista/7 elevation manifest.  Every time you start the program, it starts its auto-updater, and the auto-updater always triggers a UAC prompt, despite my user having write privileges to its directory and HKLM registry entries.

    I could say what program it is, but I suspect it would just be removed if I did.  Lets just say it's a popular gaming IM program.

  2. Vladimir says:

    One annoying problem with Vista's auto-elevation filename heuristic is that it overrides any manifests specified in the application. I once wrote a tool called "patch.exe" (or perhaps it just had "patch" in the filename, can't remember now), and couldn't figure out why would running it pop up an elevation prompt. Ultimately I found the setting that controlled this heuristic and turned it off system-wide.

    Of course, that bit me back a few times when old installers would throw cryptic error messages at me. Specifically, WISE installers would say that a "Wise un-install wizard was already running" or something on that note.

  3. Marquess says:

    Then there are installers that don't check for the necessary privileges until 99% into the install, installers that don't provide a per-user install even though there's no reason against it and my all time favorite, installers that do a per-user install but require admin privileges. A popular instant messenger had the added bonus of doing a system-wide install that only worked for the user that installed it.

  4. Dylan says:

    I didn't know XP did this until recently, but I was pleasantly surprised by the way it actually asked what account I wanted to use.  Vista forces elevation unless you rename the file.

  5. Sven says:

    Althoug this is getting a bit off-topic, I've also manifests misused. A popular weather add-on for Flight Simulator X needs to have write permissions to FSX's program directory, which is typically in Program Files, so the way they did this was by having a requireAdministrator manifest. Which means that it would always want to elevate, despite the fact that my FSX installation isn't in Program Files and my user account has write permissions where it's installed.

    Even more unfortunately, this add-on couldn't connect to FSX if it was running as a different user; not a problem for "protected administrators" that elevate using their own token, but I run as an actual limited user, so the only way this would work is if I elevated FSX as well. I ended up using a resource editor to change the add-on's manifest.

    More on topic, one thing that's annoying in Vista/7 is that there's no easy way to override the heuristic to detect installations in the absense of a manifest. Since as you say, the consequence of a false positive is "program doesn't work". And yes, this has happened to me with programs that had no manifest, weren't installers, but Vista/7 decided they were.

  6. David Walker says:

    @Sven: "in Vista/7 is that there's no easy way to override the heuristic to detect installations in the absense of a manifest".  But doesn't Vista (or 7) ask you, after what it thinks was an installation that might not have worked, if it really worked right, and if not, if you want to re-run it in XP mode (or with elevated privileges, or something)?

  7. unekdoud says:

    Windows developers use game theory five times a day, I guess.

  8. XP x64 says:

    Btw why does XP x64 edition and Server 2003 have a run as admin option in the Compatibility tab which XP 32-bit doesn't have?

  9. Administrator says:

    I never ran XP as non-admin so can anyone tell me does XP have the ability like Vista's UAC to elevate by prompting but without supplying any admin credentials?

  10. XP x64 says:

    I am referring to the "Allow non administrators to run this program" option in XP x64's compatibility tab. I mean even having that option in 32-bit XP's GUI and making non-admin default would have made users aware not to run as admin and developers not to require admin privileges for legacy apps.

  11. XP x64 says:

    Or is that only an admin shim sort of like asInvoker?

  12. Joshua says:

    Reading all this, I wonder if a useful compatability shim would be application manifest lies.

  13. Alexander Grigoriev says:

    @ XP X64:

    Because XP x64 (AKA Windows Server 2003 client SKU) is an OS different from XP.

  14. Joshua says:

    @Dichotomy: Debugger wants debug privilege.

    1) Only service debugging requires this privilege.

    2) You just gave away the farm.

    It turns out that most so-called fine-grained privileges either equate to the same thing or could be accomplished with clever permission setting.

  15. Cheong says:

    That said, I'd still be grateful if Windows will extend to auto-elevate those applications which filename contains "setup" and "installer"…

    There's plenty of installer applications exist in the wild that have default naming like "XXX-"…

  16. frymaster says:

    @administrator: XP does the same as if you ran Vista/Win7 as a non-admin: it prompts for a username/password of an admin

    in vista/win7, the difference is, you still get some sort of prompt even if you ARE an admin (but you don't need a username/password, just a elevate/cancel box)


    I'll admin most of the individual permissions are too fine-grained for mere mortals to dabble with, but the user/group system of windows/NTFS is demonstrably better than the ugo bits of linux, for multi-user systems at least (and the problem is unsolvable without breaking backwards compatability, which is why selinux doens't work with many programs)

  17. XP x64 says:

    @Alexander Grigoriev, everyone including you and me knows that. That doesn't answer why or tell any thing about that secretive option.

  18. nik says:

    Ok, now on Win7 I have a program that says "asInvoker" in its manifest, but "7" still wants to run it with elevated rights, and I have NO OPTION to run it *asInvoker*. Man, I simply want to run it with NORMAL RIGHTS.

  19. Anonymous Coward says:

    I actually use the NT access rights functionality a lot, mainly to make certain registry keys and files read-only for (otherwise legitimate) software.

    No, I don't want a quick starter. That just wastes memory when I don't use it.

    And if you want to have your program check for updates, plan a low-frequency job like Safari. Don't have a blighter constantly running in the background checking the date every five minutes.

  20. Nick says:

    @XP x64

    Yes, it does.  They are different operating systems with different feature sets.  I don't see what's so secret about that.

  21. Dichotomy says:

    It's rather amusing that Window people tout NT's fine-grained privilege model as being a huge advantage over Unix's omnipotent-root one, but nobody uses these permissions. In reality, we just speak in terms of "administrator" and "non-administrator".

    Really, programs should specify what *privileges* they require in their manifests, those requests should be shown to the user, and programs should have only those privileges.

  22. Worf says:

    I had some tax software do the same thing – it ran the auto-updater on startup, requiring admin. Well, the user isn't admin, but needs admin to run the program so the program could auto-update, and without, it won't run. Nevermind that there were no updates.

    Disabling that functionality worked.

    Most auto-updaters don't require elevation – you just check, download, then run the update you downloaded, which can ask for elevation. The updater should check and download. If updates aren't executable, have a helper do it, but checking shouldn't require elevation.

  23. Marquess says:

    “Most auto-updaters don't require elevation – you just check, download, then run the update you downloaded, which can ask for elevation.”

    This fails spectacularly with a certain popular VM runtime. It's installer would apparently download the update, then ask for elevation and, once elevated, be unable to find the downloaded update. Great design.

  24. Neil says:

    Sadly I've never needed to run regedit as a limited user, but even when I only want to look at my own HKCU it still wants to elevate. (Insert obligatory Dalek joke here.)

  25. Mike says:

    Just read this and am I understanding this correctly that installers named setup.exe on XP have their access rights elevated even when run as non-administrator uses?  If so, I understand wanting to make installers work better for non-technical end users, but isn't this a security hole?  If I send Joe or Jane Average User my spyware program, conveniently packaged as a setup.exe, they can install it even w/o admin privileges?

  26. AndyC says:

    @Mike, no it's not a security hole. If a non-admin runs setup.exe they get a RunAs prompt and have to enter Administrator credentials to run it (or they can select to just run it as themselves IIRC). If they don't know the credentials, it's not going to getthem any further.

    As to those saying they get a prompt on Vista/7 with an AsInvoker manifest, that implies there is something wrong with either the manifest itself or how it was embedded. An embedded manifest will always override AppCompat shims.

  27. XP x64 says:

    @Nick, they are not completely different operating systems but two codebases of the mostly same OS with same feature set.

  28. AndyC says:

    @XPx64, I believe that was an option primarily aimed at Terminal Server scenarios which slipped into XP x64 as a result of it basically being a slightly tweaked version of Server 2003 x64.

  29. Mark says:

    @AndyC: "An embedded manifest will always override AppCompat shims."

    I'm not sure if this will solve nik's problem, but in Windows 7 you may need a new section in your manifest to override the Program Compatibility Assistant.



  30. Alasdair King says:

    Windows Vista and later does auto-elevate more than just "setup.exe" – anything with "Install" or "Setup" in the filename will do it, I believe.

  31. Humus says:

    I once wrote an graphics sample called N-Patches.exe, which triggered the UAC prompt in Vista. Took me quite a while to figure out what the heck was going on since no other samples had this problem. I think I ended up renaming it Tessellation.exe or something like that.

  32. Dan says:

    @Anonymous Coward I tried that once with a specific web key that I didn't want installers writing to.  Turns out if a certain company's installers can't write to them they treat it as a fatal error and roll back the entire install.

  33. Dan says:

    Err that should be registry key… I was thinking of the fact that it controlled loading add-ons for a popular web browser.

  34. Miral says:


    That's not too surprising.  As a limited user the only "safe" place to write files is your temp folder.  And once you've elevated with different credentials, "the temp folder" now points somewhere else.  (In fact, depending on the user profile setup, the admin might not even be able to access the limited user's folders; I'm not sure whether that applies to their temp folder as well or not, but it's certainly possible, and would horribly break things.)

  35. Worf says:

    Heh, t5he elevation tripped me up when I was updating a music player program by a fruit company. I didn't realise that elevated apps ran as though they were logged in as the person you're elevating to. I expected a more Linux/Unix like behavior od "sudo" which can let you do things as root, but outside root. I guess elevation is more like "su" where you basically log in…

    Took me a bit to figure that out – thought I lost stuff.

  36. asmodeus_dhoine says:

    I have a question, unrelated to this post. I would really-really appreciate if you answered it.

    In Linux systems there is a centralized repository of software that you can install from *and update* from one location. Of course, user can also install applications from other sources, but they can register with package manager.

    Why is there no mechanism in Windows for software to register with Windows Update and update automatically? A program (or installer) could say "Hi, Windows Update! It's me, Adobe Photoshop v. 12! Here's the address where my updates will be, please check this every now and then". This would take a burden of going through all installed applications to update them and also will alleviate the need in 3rd party updaters running in background.

    I realize that this might be a security risk, since updates would be coming from unverified sources, but that could be addressed by, let's say, color-coded entries in Windows Update updates list or something like that. Risk should be explained to user and user must accept conditions before using this system.

    Why can't Windows users have nice things like this?

  37. peterchen says:

    @Miral "That's nto surprising" –

    for a user, it is.

  38. asmodeus_dhoine says:

    @ Marquess

    Yes, this would entail some work and I doubt that would be a lot of work, but at the same time that would help companies keep their userbase on the latest software and avoid "This crap doesn't work!" feedback from users, using Product 1.0 when there's 1.6 already out. It's just so much easier for everybody.

  39. Marquess says:


    Two simple solutions:

    1. Don't download if you can't install, but download *after* receiving elevation.

    2. Admins always have full rights in users' folders, as that makes their job much easier (they can just set rights at will anyway). So just run the installer with the path as a command line argument.

    @asmodeus: “Why can't Windows users have nice things like this?”

    IIRC, this is entirely possible, but the companies just aren't that much interested in this. This would entail work, after all.

  40. Anonymous says:

    Once we had a helper executable called <something>setup.exe which was called by the main program to do some per-user setup. Needless to say, Vista's auto-elevation of everything named <something>setup.exe broke it (it depended on the redirection of writes to Program Files). That was worked around by renaming that executable, and later fixed (the software does not depend on the redirection of writes to Program Files anymore, and also does not use a separate helper executable too).

  41. Gechurch says:


    Microsoft wrote BITS – the Background Intelligent Transfer Service – to solve exactly this problem. It is intended to be a service applications that like to check for updates can register with. The update checks can then happen automatically in the background, at low priority, and without the overhead of creating yet another process. The BITS service has existed since at least Windows XP, yet it is surprisingly under-utilised, much to my chagrin.

  42. 640k says:

    Alasdair King: Windows Vista and later does auto-elevate more than just "setup.exe" – anything with "Install" or "Setup" in the filename will do it, I believe.

    Why isn't this trivial fix back-ported to XP?

    Gechurch: Microsoft wrote BITS…it is surprisingly under-utilised, much to my chagrin.

    It's because it's api, docs, and other stuff about it SUCK. MS' goal with bits was not to give the user a better experience. It was developed as a back-door in windows to patch the os without the use knowing or could stop it. Bits and windows update is also tightly integrated with WGA and DRM, which does not help the users or other software developers in any way.

  43. Falcon says:


    "> Alasdair King: Windows Vista and later does auto-elevate more than just "setup.exe" – anything with "Install" or "Setup" in the filename will do it, I believe.

    Why isn't this trivial fix back-ported to XP?"

    It's been mentioned before that a "simple" fix can be far more complicated and risky than it seems to outsiders. In this particular case, some commenters here gave examples of the updated auto-elevation heuristic breaking compatibility. Now, imagine if an OS update introduced this problem – breaking compatibility by upgrading from Windows XP to Windows Vista is one thing; breaking it on an existing installation of Windows XP is quite another.

Comments are closed.