In our previous post on PCA, we discussed several runtime issue detection scenarios. Today, we are going to examine some program startup scenarios (specifically application blocking) and discuss the management of the Program Compatibility Assistant.
Let’s get started with looking at Application blocking. When a user launches a program, if that program is on a list of programs that are known to have compatibility issues, then PCA informs the user of this. This list is maintained in the System Application Compatibility Database. Depending on the nature of the issue, the application may be Hard Blocked or Soft Blocked. So, what’s the difference between the two?
A Hard Block, as the name implies, means that this application either will not run or will not install on Windows Vista / Windows Server 2008. A Hard Block means that the program is known to be incompatible and running the program could result in severe system errors – such as causing a system crash or a no-boot scenario. When a program is hard blocked, the PCA will display a dialog box indicating that the program is blocked due to compatibility issues, and the program will not run. Soft Blocks indicate that the program in question has a compatibility issue, but the effect on the system is not severe. In these instances, the program will run, but the user will be presented with a dialog box indicating that there are known compatibility issues.
Note: The approval to create hard blocks or soft blocks for a non-Microsoft program must come from that program’s ISV
Now that we’ve identified the difference between the two types of blocking, let’s take a look at a sample scenario that illustrates where an ISV might request a hard block or soft block.
The Case of the Outdated Anti-Virus:
In this scenario, we have an ISV who supports several versions of their AV program for multiple Windows platforms, including Windows 9x, Windows ME, Windows NT4 and Windows 2000 / XP / 2003. During their testing of Windows Vista during the Beta, they discover that if they are running an older version (version 11.0) on Windows Vista, that the system randomly bugchecks. When they analyze at the bugcheck data, they discover that the fault is being caused by a Kernel-Mode driver component of their AV program. In addition, they discover that they are unable to manage their program due to a User-mode control panel applet that requires user access to Session 0.
After additional research and several internal discussions, they make the decision that the newest version of their software (version 13.0 which is not yet released) is the one that they will officially recommend for Windows Vista. Although version 12.0 of their software does not seem to cause any major issues on Windows Vista, the application performance is not at a level that they feel comfortable with and their recommendation is that users should upgrade their AV program to version 13.0. However, recognizing that not all customers can upgrade to version 13.0 in a short timeframe following the product launch, they create a hotfix package for version 12.0 that mitigates some of the performance issues.
Now that the ISV has come to a decision about how they will handle support for their products on Windows Vista, they contact Microsoft to request a hard block and a soft block for their application. The request is presented as follows:
“Please hard block all versions of our software that are less than version 12.0 on Windows Vista. For version 12.0, please add a program compatibility warning that indicates that there are known compatibility issues with this version. When the customer clicks on the option to “Check for Solutions Online”, please provide information that indicates that the customer should visit our support website for an update to this program.”
Let’s turn our attention to how to manage Program Compatibility Assistant and Application Compatibility settings. Compatibility modes for applications are set in the following registry key (depending on whether the options are set for all users or only the current user, the setting will either be in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER:
Software\Microsoft\Windows NT\Current Version\AppCompatFlags\Layers – there are two parts for each compatibility setting:
Key Name: Full path to the executable to which we are applying the compatibility flag
String Value: Name of the Compatibility Mode being applied
Here is a sample scenario using Windows Live Messenger (Beta). On my Vista x64 workstation with UAC disabled, I want to run Windows Live Messenger in Windows XP SP2 Compatibility Mode and I also decided that I want to disable Desktop Composition (Aero Glass) whenever I run the application. I open up the properties for the msnmsgr.exe executable file and open up the Compatibility Tab as shown below.
After selecting the options that I want, I click on Apply, and then go check the registry path that I listed above under HKEY_CURRENT_USER. As you can see from the image below, the Compatibility Flags for running in XP SP2 mode and Disabling Desktop Composition are set.
If I wanted to make this change apply to all users on the machine, rather than setting the options in the main compatibility tab, I would click on the “Show Settings for All Users” button and make the appropriate changes there (as shown in the image below) – note that the tab label indicates that the changes are being applied to all users on the machine. The registry location in this instance would be under HKEY_LOCAL_MACHINE:
Besides the registry key listed above, 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 (in other words, the user indicated that the program worked correctly):
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\Current Version\AppCompatFlags\Compatibility Assistant\Persisted
Remember that PCA is intended to detect issues with older programs and it is not intended to monitor programs that were developed for Windows Vista and Windows Server 2008. When developing applications, the best option to exclude a program from PCA is to include an application manifest with the run level (administrator or as limited user) marking for UAC. This means that the program is tested to work under UAC. PCA checks for this manifest and will exclude the program. Another option to exclude applications from PCA is to add the .exe including the full path under the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Compatibility Assistant
The string value name to use is ExecutablestoExclude. PCA automatically excludes programs running from network locations and any programs that have fixes applied to them in the application compatibility database. If you want to disable PCA for all programs, this can be done via Group Policy. Under the Administrative Templates\Windows Components\Application Compatibility section, there is a policy called “Turn of Program Compatibility Assistant”. You can also turn off specific scenarios using the policies under Administrative Templates\System\Troubleshooting and Diagnostics\Application Compatibility Diagnostics.
Last, but by no means least, let’s take a look at how PCA events are logged. After a user has acted on PCA, an event is logged under Application and Services Logs\Microsoft\Windows\Program-Compatibility-Assistant\Operational in the Event Viewer. The event includes information about the application such as the name and version, as well as the executable path, scenario ID, user action and what compatibility modes (if any) are applied. Looking at the sample event below, we can see that there was a problem with Outlook 2007 on my x64 Vista machine.
The details indicate that there is a problem with a deprecated component that Outlook is trying to use, in this case flash.ocx. This is not actually a problem with flash.ocx but more specifically the web page or application I was using in Outlook is coded to look for a file named flash.ocx. Adobe has released a later version of the Flash player that is compatible with Windows Vista & IE7 that is called flash9.ocx. The key piece of information here is the Scenario ID. In this event, the ID is 5. The table below indicates the possible value for the Scenario ID – as you can see, 5 maps to a deprecated component:
|1||Detecting failures in setup programs (installer)|
|10||Detecting failures in setup programs (uninstaller)|
|3||Detecting program failures while trying to launch an installer|
|8||Detecting installers that need to 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 x64 platform|
And that brings us to the end of this post. Hopefully as you deploy and manage Windows Vista , this information helps you diagnose and resolve any Application Compatibility issues. In enterprise settings, Administrators can use the Compatibility Administrator tool that ships as part of the Application Compatibility Toolkit to manage application compatibility settings. Until next time …
- MSDN – Application Compatibility
- Microsoft Application Compatibility Toolkit
- Ask the Performance Team Blog – Posts on Application Compatibility