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.”
- MSDN – Application Compatibility
- Microsoft Application Compatibility Toolkit
- Ask the Performance Team Blog – Posts on Application Compatibility
Microsoft, Windows Vista, Windows Server 2008, Windows, Troubleshooting, Knowledgebase, Article