Windows – the Microsoft downloaded app compat updates stored

Securityuacwindows

Where are the Microsoft application compatibility update settings stored on a Windows XP, Windows Vista, and Windows 7 computer?

Microsoft periodically release application compatibility updates (e.g. KB929427), where they list the shims that should be applied to a program in order to workaround known bugs in the software. Where are these app compat flags stored, and how can i see what shims are being applied?

i have a feeling that a recent app compat update included a flag to force a particular piece of software, that we use, to require administrator. Because the task is scheduled to run nightly, and the running user does not have administrative privelages, the task is failing to start.

The application is requiring to be elevated. It has the UAC shield overlay. The application has no RT_MANIFEST resource, and the compatibility option Run this program as administrator is disabled (per-user and all users). So all that's left is some secret global setting.

i know user-specified compat flags are stored in:

HKEY_LOCAL_MACHINE
   \SOFTWARE
     \Microsoft
       \Windows NT
         \CurrentVersion
           \AppCompatFlags
             \Layers

Best Answer

They are probably in a database file in c:\Windows\AppCompat. But your best bet is to download the latest Application Compatibility Toolkit as the "Compatibility Administrator" contains their complete database. You could use it to disable some or all shims from being applied to your backup application.

Related Solutions

Windows – Useful Command-line Commands on Windows

A little known one is

getmac

It shows the MAC address(es) of your network adapter(s).

Screenshot of running getmac from a Windows commandline window.

Windows 2008 never run a program “as administrator”

You may be tripping one of Windows several heuristics to determine if an application needs administrative privileges. If it determines an application needs administrative privileges, it will trigger a UAC prompt. It's not perfect and not always right, but it's all in an effort for backwards compatibility.

One of the most common ones is simply by file name. If the file contains install or setup (and possibly update) then it will prompt unless explicitly told not to by means of an embedded manifest file. That's nothing you'll be able to change, the developer will have to make this change.

It could be writing to a privileged location, such as somewhere off C:/Windows or C:/Program Files or even a privileged registry location (specifically somewhere off HKEY_LOCAL_MACHINE). A standard user cannot write (or even access in some cases) these locations, and as such Windows must trigger a UAC prompt for the application to function correctly.

You might check if there are any updates available from the publisher of this application. They may be able to provide you with an update that enables compatibility with Windows Server 2008. If not, maybe try contacting them and asking them if they're aware of any issues and see if they have a resolution.

This program could also be listed in the built in compatibility database as requiring elevation to function correctly. I'm not sure if you can influence this list or not, but you'd probably be best off with a more recent version from the software publisher that they have confirmed compatibility with Windows Server 2008.

It might just be that the app is old and does something weird that trips one of the heuristics. I had an application that I wrote that worked fine on Windows XP, but on Vista and later it triggered a UAC prompt. It did not read or write to any of the privileged locations I mentioned earlier. Changing no code whatsoever and simply recompiling it in Visual Studio 2010 (as opposed to Visual Studio 2005 that it was originally compiled in) fixed that problem.

Related Topic