Thoughts from the EPS Windows Server Performance Team
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:
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:
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.
- Rahul Nagpal
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:
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
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 firstname.lastname@example.org