If you missed the first part in this article series please read:
If you would like to be notified when Brien Posey releases the next article in this series please sign up to the WindowsNetworking.com Real time article update newsletter.
In the previous part of this article series, I explained that while group policies have traditionally been used as a way of enforcing security, they can also be used to assist with diagnostics when problems occur. Group policies are not diagnostic tools in and of themselves, but the Windows operating system contains a number of built in diagnostic tools and remediation mechanisms. In Windows Vista and Windows Server 2008 (formerly known as Longhorn Server) it is possible to use group policies to enable these various diagnostic tools and to control how they behave in various situations. In this article, I will discuss how group policy settings can be used to control Window’s various troubleshooting and diagnostic mechanisms.
Diagnostic Configuration Scenarios
The group policy settings that I am going to show you in this article are all related to Windows Vista’s Diagnostic Policy Service. In case you are not familiar with the diagnostic policy service, it is a component of the Windows Diagnostic Infrastructure (WDI). The Diagnostic Policy Service (DPS) is designed to coordinate the various components used in problem detection, diagnostics, and resolution.
The first two group policy settings that I want to show you can be found at Computer Configuration\Administrative Templates\System\Troubleshooting and Diagnostics. The first of these group policy settings is the Diagnostics: Configuration Scenario Retention setting. The basic idea behind this particular setting is that in order for the Diagnostic Policy Service to work, it must collect information about what is going on inside of Windows. This information is called scenario data.
By default, once Vista accumulates 128 MB of scenario data, that data is deleted to make room for fresh scenario data. You can use the Diagnostics: Configure Scenario Retention setting to specify a different amount of scenario data to be retained.
The other diagnostic configuration setting that is available in this location is the Diagnostic: Configure Scenario Execution Level setting. This setting allows you to control what happens when Windows detects a problem. If you enable this setting, you must choose between two different execution levels. The first available execution level is Problem Detection and Troubleshooting. If you select this particular execution level, then when problems occur Windows will detect the problem, and will attempt to determine the problem’s root cause. This information is then written to the computer’s event log.
Your other option is to select the Detection, Troubleshooting, and Resolution execution level. When this execution level is set, Windows will attempt to automatically take corrective action when problems occur. In some cases, Windows is unable to take corrective action automatically. In such cases, Windows may provide the end user with information about how to manually correct the problem.
Application Compatibility Diagnostics
Now that I have talked about some settings that are related to general Windows diagnostics, let’s take a look at how group policy settings can be of assistance when it comes to more specific diagnostic situations. The Group Policy Object Editor presents several sub folders beneath the \Computer Configuration\Administrative Templates\System\Troubleshooting and Diagnostics portion of the tree. Each of these folders contains group policy settings related to troubleshooting a specific type of issue. The first of these folders is the Application Compatibility Diagnostics folder.
Notify Blocked Drivers
The first group policy setting found within the Application Compatibility Diagnostic folder is the Notify Blocked Drivers setting. As you probably already know, there are some device drivers that work fine with Windows XP, but that are not compatible with Windows Vista. When Vista detects incompatible device drivers, it blocks them from being used in order to prevent Windows from producing a blue screen error.
This is where the Notify Blocked Drivers setting comes into play. If the Notify Blocked Drivers setting is enabled, then Windows will notify the end user when a driver has been blocked, and will give them an option to check the Microsoft Web site for a solution. If you disable this setting, Windows will silently block incompatible device drivers. The user will not be notified of the problem, nor will they be presented with the option to check the Microsoft Web site for a solution.
Detect Application Failures Caused By Depreciated Windows DLLs or COM Objects
The next Application Compatibility Diagnostic setting that is available is the Detect Application Failures Caused By Depreciated Windows DLLs or COM Objects. This setting controls whether or not Windows will diagnose application compatibility issues related to problems loading DLLs or problems creating COM objects.
If you enable this setting, then Windows’ Program Compatibility Assistant will monitor applications to ensure that they are not using DLLs or COM objects that existed in previous versions of Windows, but that were removed from Windows Vista. If the Program Compatibility Assistant does detect these types of files being used, then the application using the files is terminated, and the Program Compatibility Assistant notifies the user, and gives them an option to check the Microsoft Web site for a solution.
If you disable this group policy setting, then you are not just turning off the notification, but rather preventing the Program Compatibility Assistant from checking for the use of legacy DLL files and COM objects. The result of doing so is unpredictable. Some applications may run correctly, but most will likely crash.
Detect Application Install Failures
The next group policy setting on the list allows you to control whether or not you want Windows to detect application installation failures. As you probably know, most applications use a SETUP.EXE program that is based on a standard API. Microsoft has built various diagnostic capabilities into this API that allow Windows Vista to monitor the installation as it takes place.
If you choose to enable the option to detect application failures, then Vista will monitor application installations, and watch for signs of an installation failure. If such a failure does occur, then Vista will give the end user the option to restart the installation process, but to run it in Windows XP compatibility mode.
If you choose to disable the Detect Application Installation Failures setting, then Vista will completely ignore any application installation failures that may occur. Failures can still occur, and might be handled by the Setup program itself, but Vista is not going to step in and offer the end user the chance to re run the Setup program in Windows XP compatibility mode.
In case you are wondering, Windows Vista is designed to detect application installation failures by default. Therefore, even if you do not configure this group policy setting, Vista will offer users the chance to re run a failed installation in Windows XP compatibility mode. Typically, you would only enable this group policy setting if you wanted to guarantee that failed installations are always detected, and not blocked by lower level policy settings.
Some administrators prefer to block the detection of failed applications because they believe that running Setup in Windows XP compatibility mode undermines the system’s security. My personal thoughts are that Windows XP compatibility mode is weaker from a security standpoint, but usually does not cause any significant vulnerabilities.
Conclusion
In this article, I have discussed some group policy settings related to application compatibility diagnostics. In Part 7, I will continue the discussion by examining some more application compatibility settings.
If you missed the first part in this article series please read:
If you would like to be notified when Brien Posey releases the next article in this series please sign up to the WindowsNetworking.com Real time article update newsletter.
