How to tell Windows 7 that an application does not need to run with admin rights?

8

3

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?

user13141

Posted 2010-01-31T17:35:53.693

Reputation: 311

Question was closed 2012-03-05T09:16:21.010

Answers

14

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.

bk1e

Posted 2010-01-31T17:35:53.693

Reputation: 1 579

4That auto elevations based on keywords is sick! – nawfal – 2013-09-18T08:25:00.727

9

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:

Goldwave.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

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
    \Layers

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:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers

Ian Boyd

Posted 2010-01-31T17:35:53.693

Reputation: 18 244

How do the shims get there? – Michael Slade – 2012-11-24T16:02:25.130

@MichaelSlade When you check options on a program's property's Compatibility tab. Those settings are saved in the registry AppCompatFlags key – Ian Boyd – 2012-11-24T17:14:44.570

1

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.

ChrisF

Posted 2010-01-31T17:35:53.693

Reputation: 39 650