Possible Duplicate:
Prevent elevation (UAC) for an application that doesn't need it

I am using an application that was written before Windows Vista/Windows 7. Windows has decided that the application needs to run as an admin (i.e., it has the shield icon). I'm pretty sure the application has nothing in its manifest that indicates that it needs to run with elevated privileges (it was written way before Windows Vista).

Is there any way to tell Windows that a specific application does not need elevated privileges?


Windows automatically elevates applications based on various criteria (listed in Understanding and Configuring User Account Control in Windows Vista):

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

  • Filename includes keywords like "install," "setup," "update," etc.
  • Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
  • Keywords in the side-by-side manifest embedded in the executable.
  • Keywords in specific StringTable entries linked in the executable.
  • Key attributes in the RC data linked in the executable.
  • Targeted sequences of bytes within the executable.

If you can't prevent elevation by renaming the file, you should be able to create a manifest that prevents elevation.

| improve this answer | |
  • 4
    That auto elevations based on keywords is sick! – nawfal Sep 18 '13 at 8:25

Assuming the program was properly written, and will actually work when running as a standard user, you can manifest it to run as standard user.

Note: If the program didn't work on Windows XP, it will continue to fail on Windows Vista or Windows 7. You can test this application by logging into Windows XP and seeing if it works. (You do login to Windows XP as a standard user, right?)

If the program fails to run correctly on Windows XP as a standard user, it will fail to run on Windows 7 as a standard user. If you must run the program as an administrator on Windows XP, you must run the program as an administrator on Windows 7.

If you're satisfied that the program doesn't need to be run as an administrator, you can add a Manifest instruction Windows that it should be run as the standard user that you are.

Create the manifest file in the same folder as your application. e.g., Goldwave.exe you create:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version=""
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

Note: This is a so-called external manifest, because it's in a separate file. It's entirely possible that the application already has a manifest.

Manifests were introduced with Windows 2000 as a way to declare dependencies on certain versions of DLLs. One common use of that manifest came along with Windows XP, for programs to declare their dependancy on version 6 of comctl32.dll – so that the application was "themed".

If the application already has an embedded manifest, Windows will ignore any external manifest. In that case you'd need to use Resource Hacker to modify the embedded RT_MANIFEST (resource type 24) manifest.

The next thing you can do is check the registry to see if someone's already applied an elevate shim to your program. Load Regedit and check:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

In there you will likely find a large number of programs listed, with their space-separated shims:

  • C:\Program Files (x86)\ACDSee32\ACDSee32.exe HIGHDPIAWARE
  • C:\Program Files (x86)\Google\Picasa3\Picasa3.exe ELEVATECREATEPROCESS
  • C:\Program Files (x86)\skiStunt\skiStunt\bin\skiStunt.exe WINXPSP2
  • C:\Program Files (x86)\Steam\Steam.exe HIGHDPIAWARE ELEVATECREATEPROCESS
  • C:\Program Files (x86)\SysInternals\autoruns.exe ELEVATECREATEPROCESS RUNASADMIN
  • C:\Program Files (x86)\Windows Live\Messenger\msnmsgr.exe VISTASP2
  • D:\Games\Call of Duty\CoDSP.exe WINXPSP3
  • D:\Shared\Win32app\Spy\SPYXX.EXE DISABLEDWM

Check that your program isn't in there. You can also find a similar set of entries (the ones for "all users") in:

| improve this answer | |
  • How do the shims get there? – Michael Slade Nov 24 '12 at 16:02
  • @MichaelSlade When you check options on a program's property's Compatibility tab. Those settings are saved in the registry AppCompatFlags key – Ian Boyd Nov 24 '12 at 17:14
  • Is there any reason an executable is still requesting for Elevation running under a standard user account, even when the manifest was edited to specify <requestedExecutionLevel level="asInvoker" uiAccess="false"/> ? – Sajuuk May 6 at 9:38
  • @Sajuuk I've seen such a thing happen. Windows has decided that my app needs to elevate, and i don't want it to elevate. So i add an assembly manifest, and confirm the assembly manifest is being used, but running it still triggers a UAC elevation. The cause is that Windows has (somewhere) cached the fact that Project1.exe needs elevation, and it remembers that until the system is restarted. – Ian Boyd May 6 at 13:44

If the application was written well before Windows Vista / 7, then there's a good chance that it could require admin rights to run. A lot of programs assumed that the person installing would have admin rights, so they just wrote to the sections of the registry and file system the programmer thought best.

I know this from my own personal experience. About a decade ago I was working for a company that sold its software into a big automotive company. All their PCs were locked down. We had to modify our code so it could be installed by some one running with just "User" rights.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.