Application Compatibility: Program Compatibility Assistant (PCA)

Program Compatibility Assistant (PCA) in Windows Vista

Introduction to PCA

The Program Compatibility Wizard in Help and Support and the Compatibility tab in file properties are useful tools for users to fix program-compatibility issues in Windows XP®. The major limitations with these tools are the discoverability and the fact that the user needs to know when to use these tools. The Program Compatibility Assistant (PCA) is a new feature in Windows Vista® and Windows Server® 2008 that can make older programs that have compatibility problems work better in an automated manner. PCA monitors programs for known issues. If an issue is detected, PCA notifies the user of the problem and offers to apply solutions that will be effective before the user runs the program the next time.

The following sections describe the scenarios in which the user is expected to encounter PCA, details on the user experience, the solutions applied in each of those scenarios, and how to manage the settings made by PCA at a later time. The last section talks about how to exclude programs from PCA.

PCA Scenarios

Detecting Failures in Setup Programs

One of the main scenarios for PCA is detecting setup programs failing to install on Windows Vista and Windows Server 2008 and providing the solution of applying the Windows XP compatibility mode.

The most common setup failure is due to installers hard-coding the check for the Windows OS version. These installers will typically fail with an error message saying that the current version of Windows is not supported and installation will be terminated.

The following is an example of such error message, illustrated by a test program.

Programs commonly use the GetVersion function or the GetVersionEx APIs to get information on the Windows OS version they are running on. Under Windows Vista and Windows Server 2008, these APIs will return 6 as the major version. If the program is hard-coded to look for the XP version, which is major version 5, it will fail under Windows Vista and Windows Server 2008. The XPVersionLie fix included in the Windows XP compatibility mode will provide the XP version of the OS to the program, when it calls GetVersion or GetVersionEx APIs.

PCA targets to detect this scenario and will display a user interface similar to the one below after the installer is terminated. This scenario also covers uninstallers and a similar dialog will soon be shown.

When the user selects the Reinstall using recommended settings option, the WINXPS2 compatibility mode will be applied to the installer program, and the installer will be automatically restarted.

More details on what happens in this scenario are explained in the following questions and answers:

1. What is the detection logic, and how does PCA know that the setup failed due to version problems?

   PCA does not specifically look for the setup's failing due to version problems. The logic used by PCA is to detect if a setup did not complete successfully. It monitors a program detected as setup by Windows Vista and Windows Server 2008 and checks whether the program registers an entry in Add or Remove Programs (ARP). If no entries are created in ARP, PCA concludes that the installer did not complete successfully. It will then wait for the install program to terminate before displaying the UI. If it is an uninstaller, the detection looks for whether an entry was deleted from ARP.

2. How does PCA get information about the setup programs?

   PCA relies on the User Account Control (UAC) feature in Windows Vista and Windows Server 2008 to know whether a program is a setup program. UAC includes detection for setup programs and will make sure the detected setup programs will be run as Administrator, which includes getting administrative credentials or confirmation from the user before launching the program.

3. What does each option in the PCA dialog for setups do?

   Reinstall using recommended settings

   This option will apply the Windows XP compatibility mode and restart the program. Refer to in this document for more details on how the compatibility mode is applied.

   The program installed correctly

   It is possible that in some cases, PCA might appear for a setup program that completed correctly, but did not create an entry in ARP. In those cases, users can use this option to suppress the PCA dialog the next time.

   Cancel

   PCA will do nothing.

   All these options will result in the PCA dialog disappearing. PCA will not appear again for the same setup program except when the user selected the Cancel option on the previous PCA dialog.

Detecting Program Failures under UAC

The second main scenario category for PCA is detecting program failures while running under User Access Control (UAC). PCA detects three different types of program failures under UAC, which are described in the following sections.

Detecting Program Failures While Trying to Launch Installers

PCA detects this particular scenario of a program not running as Administrator that is experiencing a failure while launching a child program, because the child program is required to run as Administrator. This scenario will typically be the case for programs trying to launch an updater program because Windows Vista and Windows Server 2008 returns a new error code to programs trying to launch an executable that is detected to run as Administrator. If the same updater is run from Windows Explorer, it will run as administrator since Explorer knows how to handle this error code. Explorer launches the UAC consent UI asking for administrator credentials or approval and finally runs the program as Administrator. The following is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Here the test program has tried to launch an updater that is required to run as administrator and has failed. In this case, PCA will apply the ELEVATECREATEPROCESS compatibility mode, which will enable the program to successfully launch the child program as Administrator the next time. Now when the program is run the next time and while trying to launch the updater, it will not fail and will successfully run as Administrator. The user will see the UAC consent UI.

More details on what happens in this scenario are explained in the following questions and answers:

1. What is the detection logic, and how does PCA know that the program failed to launch a child program that needs to run as Administrator?

   The detection for this scenario is accomplished through instrumentation at the CreateProcess API to detect the cases when a child process launch fails due to the requirement to run as Administrator.

2. Why are there no options in this PCA dialog?

   Due to the high confidence on the issue detection in this scenario, the solution (ELEVATECREATEPROCESS compatibility mode) is automatically applied, and the user is not given any options.

Detecting Installers That Need to Be Run as Administrator

One of the tenets of Windows is that the installation of most software requires administrative privileges. This requirement is because installed applications are loaded into system directories and manipulate system resources. The installation-detection part of the overall UAC feature helps by identifying setup programs and automatically prompting the user for Administrator approval or credentials. In some cases it is possible that an installation program might not be detected by UAC. These programs are typically custom made installers that are not built using standard installer technologies such Install Shield and Microsoft Windows Installer.

PCA detects this scenario and will display a user interface similar to the following one after the installer is terminated.

When the user selects the Restart the program as administrator option, the program will be marked to run as administrator and will be automatically restarted.

More details on what happens in this scenario are explained in the following questions and answers:

1. What is the detection logic and how does PCA know that the program needs to run as administrator?

   The logic used by PCA is to detect whether the program tried to create a subfolder in the Program Files directory and subsequently tried to copy an .exe or .dll file into it. PCA assumes that these common actions are performed by an installer. PCA relies on events from the File Virtualization feature as part of the overall UAC feature for detecting this. When a program is not running as administrator, writing to the Program Files directory is not permitted as it is one of the system locations. File Virtualization tries to address this by redirecting the writes attempted on a system location to a Virtual store. For example, it supports redirecting a directory creation in the virtual location and writing document files, but does not support redirecting binary files such as DLL or executable files. In either case, File Virtualization sends events that can be consumed by PCA.

2. What does each option in the PCA dialog for this scenario do?

   Restart the program as an administrator

   This option will apply the RunAsAdmin compatibility mode and restart the program. Refer to in this document for more details on how the compatibility mode is applied.

   The program installed correctly

   It is possible that in some cases, PCA might come up for a setup program that completed correctly. In those cases, users can use this option to suppress the PCA dialog the next time.

   Cancel'

   PCA will do nothing.

   PCA will not show up again for the same program except when the user selected the Cancel option on this dialog.

Detecting Legacy Control Panels That Might Need to Run as Administrator

The last UAC-related scenario addressed by PCA is to detect Control Panel items that need to be run as Administrator. After a legacy Control Panel item is run once, a PCA dialog similar to the following one will show up.

More details on what happens in this scenario are explained in the following questions and answers:

1. What is the detection logic, and how does PCA know that the Control Panel item needs to run as administrator?

   There is no specific issue detection logic used in this scenario, and this dialog will show up after a legacy Control Panel item has completed running. The target is to provide the user with an option to run the control panel item as administrator, which is the most commonly needed solution for a Control Panel that might not work properly under UAC. This dialog will not show up for Control Panels tested to work under UAC and manifested with the proper RunLevel marking for UAC (marked to run either as administrator or As Invoker) set. For more information about UAC and how to create this UAC manifest, see Adding a UAC Manifest to Managed Code

2. What does each option in the PCA dialog for this scenario do?

   Open the control panel using recommended settings

   This option will apply the RunAsAdmin compatibility mode and restart the Control Panel item as Administrator. Refer to in this document for more details on how the compatibility mode is applied.

   The control panel works correctly

   In cases where the Control Panel item works correctly, users can use this option to suppress the PCA dialog the next time.

   Cancel

   PCA will do nothing.

   All these options will result in the PCA dialog to disappear. PCA will not show up again for the same control panel item except when the user selected the Cancel option on this dialog.

Detecting Program Failures Due to Deprecated Windows Components

This PCA scenario mitigates the impact on programs due to deprecated (removed) components in Windows Vista and Windows Server 2008. PCA detects programs that are trying to access a DLL or a COM object removed in Windows Vista and Windows Server 2008. If a program is detected trying to access a known DLL or COM object, PCA will provide a UI at the program termination to inform the user and provide options to check online for a solution.

The following is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Here the test program was trying to use the COM objects associated with the DHTML editing control, which is removed from Windows Vista and Windows Server 2008.

More details on what happens in this scenario are explained in the following questions and answers:

1. What is the detection logic, and how does PCA know that the program failed to launch a child program that needs to run as Administrator?

   The detection for this scenario is accomplished through instrumentation at the CoCreateInstance API and the Loader (NTDLL) to detect load failures on COM objects and DLLs respectively. When there is a failure due to an object or file not found, it will be checked against a known list of DLLs and COM objects. If a match is found, PCA will trigger after the program termination

2. What happens when the Check for solutions online option is selected?

   This option sends a Windows Error Report to get an online response from Microsoft. The responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically, the response will point the user to a Knowledge Base article that talks about alternatives to the deprecated component and in some cases provides a link to download the deprecated component from online.

Detecting Unsigned Drivers on 64-Bit Platforms

In this scenario, PCA is trying to protect the system stability due to programs or devices using unsigned drivers on 64-bit platforms. Windows Vista and Windows Server 2008 do not support unsigned drivers on the 64bit platform and enforce a policy that all drivers should be signed. If an unsigned driver is installed into the system with a 64-bit platform, it will not be loaded. After the user reboots the machine, the system will not start if it is a boot-time driver. The device or program trying to use the driver might experience failures that might also result in a system crash. In order to prevent this problem, PCA monitors installation of unsigned drivers, and whenever PCA detects installation of an unsigned driver, it will notify the user as shown in the following dialog.

If it is a boot-time driver, PCA will disable the driver so that the system will be able to boot.

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, the PCA dialog will be displayed. Unlike in the other PCA scenarios, this message is not related to specific applications and is related to the driver, regardless of how it was installed.

Informing Users about Compatibility Issues with Known Programs at Startup

Apart from the runtime issue detection scenarios listed above, PCA also informs users at program startup if the program belongs to a list of programs known to have compatibility issues. The list is stored in the System application compatibility database. This scenario also exists in Windows XP, and these messages are known as the Application Help (shortly Apphelp) messages. There are two types of Apphelp messages:

• Hard Block Messages—if the program is known to be incompatible and if allowing the program could result in severe impact to the system (for example, a stop error or unable to boot after the installation.), a blocking message as shown will be displayed.

Note

Microsoft gets approval from the ISVs for programs being blocked.

• Soft Block Messages— used in the case of programs that have known compatibility issues, but the impact is not severe to the system.

In both cases, the Check for solutions option sends a Windows Error Report to get an online response from Microsoft. The responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically the responses will be one of three types:

• Pointing the user to an update from the ISV for that program.

• Pointing the user to an ISV website for more information.

• Pointing the user to a Microsoft Knowledge base article for more information.

Managing Settings Made by PCA

The compatibility modes will be applied to programs by setting a registry key under

Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers with a key name of the full path of the program and a string value of the name of the compatibility mode being applied.

The registry key will be set under HKEY_LOCAL_MACHINE to apply the solutions to be effective for all users except for the scenario where the ELEVATECREATEPROCESS compatibility mode is applied automatically before the PCA dialog shows up. In that scenario, the registry key will be set under HKEY_CURRENT_USER, and the solution will be effective only for the current user.

Apart from this key, PCA stores the list of all programs for which it came up under the following key for each user, even if no compatibility modes were applied (e.g. in the case where the user reported that the program worked correctly):

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted

Excluding Programs from PCA

PCA is intended to detect issues with older programs and not intended to monitor programs developed for Windows Vista and Windows Server 2008. The best option to exclude a program from PCA is to include, with the program, an application manifest with run level (either Administrator or as limited users) marking for UAC. This marking means the program is tested to work under UAC (and Windows Vista and Windows Server 2008). PCA checks for this manifest and will exclude the program. This process applies for both installer and regular programs.

Another option to exclude applications from PCA is to add the list of executable files with full path under the following registry key: HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows NT\CurrentVersion\Compatibility Assistant. The value name is ExecutablesToExclude, which is type REG_MULTI_SZ.

PCA automatically excludes programs running from network locations and programs containing fixes applied to them in the application compatibility databases.

A group policy setting is provided to disable PCA for all programs if desired. The name of the policy is Turn Off Program Compatibility Assistant. It can be found under Administrative Templates\Windows Components\Application Compatibility in the group policy editor (gpedit.msc).

There are also individual policies to turn off specific scenarios. These policies are available under Administrative Templates\System\Troubleshooting and Diagnostics\Application Compatibility Diagnostics in the group policy editor.

Event Logging

After the user has acted on PCA, an event will be logged in the event log. The events can be found under Application and Services Logs\Microsoft\Windows\Program-Compatibility-Assistant\Operationalin the Event viewer. The event log includes the following information: application name, application version, executable path, scenario ID, user action, and the names of the compatibility modes applied if any. The values of the scenario ID are listed in the table below.

Scenario ID	Description
1	Detecting failures in setup programs (installer)
10	Detecting failures in setup programs (uninstaller)
3	Detecting program failures while trying to launch installers
8	Detecting installers that need to be run as administrator
9	Detecting legacy control panels that may need to run as administrator
5	Detecting program failures due to deprecated Windows components
11	Detecting unsigned drivers on 64-bit platform

Managing Apphelp Messages

In an Enterprise setting, an IT Professional can use the Compatibility Administrator tool to disable the Apphelp entries present in the System application compatibility database or add custom databases that contain Apphelp messages for programs used in the enterprise.

The Compatibility Administrator tool ships as part of the Application Compatibility Toolkit. For more information about the Toolkit, see Application Compatibility Tools.

See Also

Concepts

Application Compatibility