The Program Compatibility Assistant - Part One

The Program Compatibility Assistant - Part One

  • Comments 4
  • Likes

It's been a while since we posted something on Application Compatibility and Windows Vista.  A question I get from quite a few customers when discussing application compatibility is, "What is the Program Compatibility Assistant used for?"  Today we are going to cover some common installation and runtime scenarios.

First off, what does the Program Compatibility Assistant (aka PCA) actually do?  The PCA detects known compatibility issues and notifies the user if there is an issue and offers to remedy the issue the next time the program is run.  For example, the PCA may be able to resolve conflicts with User Account Control or run the program in a compatibility mode that simulates an earlier version of Windows.  However, in some instances the compatibility issue may be serious and the PCA may block the application from running.

So let's take a look at the two most common scenarios we mentioned above where the PCA can help to alleviate the issue:

OS Version Scenario

One possible reason that an application may fail to install on Windows Vista is due to the version checking logic built into the application's installer.  For example, if an application does a version check and fails with an error message indicating that "the current version of Windows is not supported", then the problem could be that the installer is checking for a specific OS Version using either the GetVersion or GetVersionEx API's.  For example, if an installer is hard-coded to look for the OS Major Version number to equal "5", then on a Windows Vista system, the installer would fail.  This is because the OS Major Version number of Windows Vista (and Windows Server 2008) is "6" as shown below:

image

In this instance, if we allow PCA to reinstall the program using the recommended settings, then PCA would apply the XPVersionLie fix which tells the installer that the OS Major Version is "5" when the GetVersion or GetVersionEx API's are called.

PCA and UAC

There are three different scenarios where PCA will detect failures due to UAC:

  1. Detecting a failure when trying to launch an installer:  The most common scenario of this type will be some sort of updater program.  For example, you launch an application that does not require administrative rights to run, however the vendor has their own auto-update program that tries to launch at the same time.  However, in order to succeed, this child program requires administrative rights.  In this instance, PCA applies the ELEVATECREATEPROCESS compatibility mode which enables the child executable to be launched as an administrator.  From the user perspective they will be presented with the familiar UAC prompt requesting either consent or credentials.
  2. Detecting an installer that needs to be run as administrator:  Custom installation programs that do not use standard installer technologies such as InstallShield or Windows Installer may experience issues because UAC does not detect them as installation programs.  UAC has a detection feature to detect setup programs and automatically prompt the user for consent or credentials.  PCA will detect that the program is an installation program and set the RunAsAdmin compatibility flag to run the program as an administrator - thus invoking the standard UAC consent / credentials prompt before installation can succeed.
  3. Detecting legacy control panel items that may need to be run as administrator:  Legacy control panel applets may fail because they require administrative privileges in order to run correctly.  Similar to the scenario above, PCA will automatically set the RunAsAdmin compatibility flag to ensure that the UAC consent / credentials prompts are presented. 

There are a couple of other common PCA scenarios to consider, Program failures due to deprecated or obsolete Windows components and Detecting unsigned drivers on a 64-bit platform.  In the first scenario, PCA mitigates the impact on programs due to deprecated components in Windows Vista and Windows Server 2008.  For example, if a program is trying to access a DLL or COM object that has been deprecated, PCA will provide a UI when the program terminates to advise the user and provide options to check online for a solution.

Windows Vista and Windows Server 2008 do not support unsigned drivers on a 64-bit platform.  If an unsigned driver is installed, the driver will not load.  Following a reboot, if the driver is a boot-time driver the system will not boot.  This is important to keep in mind.  The device or program trying to use the driver may experience failures which may also result in a system crash.  However, PCA mitigates against this by monitoring driver installation, and notifies the user if an unsigned driver is installed.  In the event that the driver is a boot-time driver, PCA will disable the driver, thus guarding against a no-boot situation.  PCA detects this scenario first by monitoring changes to the KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key for addition of new drivers into the system.  Then, based on the location of driver from the registry, each new driver installed will be checked for a valid digital signature.  If the driver does not have a valid signature, PCA dialog will be displayed.

And that brings us to the end of Part One of our overview of the Program Compatibility Assistant.  Part Two will cover Application Hard Blocks and Soft Blocks as well as Managing PCA Settings.

Additional Resources:

- Rahul Nagpal

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://www.kefrotate.com/?p=1080

  • I found myself here after discovering the PCA alert appearing after my control panel, which ran fine, closes. I would of course like this to stop. It seems there are a couple of different possibilities.

    My applet calls GetVersion in order to determine whether it is running on Vista. It would be ironic to say the least if carefully determining whether my applet were running on Vista caused Vista to suspect my applet is trying to determine whether it is running on XP.

    Vista may also have decided my control panel applet might have needed to run as administrator. However, as far as I can tell, this is not the case. How can I persuade Vista of this?

  • For my applet, it came down to adding this gobbledygook to my existing manifest resource:

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

    <security>

    <requestedPrivileges>

    <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

    </requestedPrivileges>

    </security>

    </trustInfo>

  • installed a game i brought,marinesharpshooter2 jungle warfare,i get this error could not intialize the renderer,iwas told someone said it was in the compatibility assisiant,but i dont know what they are talking about,can soneone help me.my email is bigscreen1947@charter.net