The Microsoft Application Compatibility Tools (Part 1)

If you would like to read the next article in this series please go to The Microsoft Application Compatibility Tools (Part 2).

The application compatibility tools provide a a simple and elegant solution to resolving many of the application access issues encountered by Terminal Services administrators. This article provides an introduction to the tools, and will look specifically at the Application Verifier.


Wouldn’t it be great if we had some easy way to make all your application execution problems go away on terminal services? No more issues with registry or file system access errors or any file sharing or locking problems. And applications that just run like they do on a single user workstation.

There are a lot of different solutions available to “fix” application problems and they vary from workstation virtual machines at one end of the spectrum to simple API redirection at the other. The most fashionable way to solve application problems at the moment is application virtualization, using products like Citrix Application Streaming, Altiris SVS, Softgrid, Thinstall, AIE etc. Put the application in a bubble where it’s got its own redirected registry, file system etc and just run it. If only life were that simple.

Application virtualization isn’t a new concept and the products mentioned aren’t the only way we can avoid the registry hacks etc needed to get apps to behave. In fact, we’ve had the ability to fix 80-90% of the common application access issues on terminal services since early in 2003 simply by using the Microsoft application compatibility toolkit tools.

I’d like to give you a bit of background history that’s kind of loose, but should give you a feel for the why and where of the toolkit.

Application compatibility issues were high on Microsoft’s hit list with the release of Windows XP, particularly Home Edition. Because how do you get people to buy Windows XP if they can’t run their Windows 9X games and applications? The answer was the application compatibility fixes, a series of API redirection DLLs to let Windows 9X applications (mostly games) run without problems on XP.

Nearly fours year ago, the Windows Server 2003 RTM heralded some new compatibility fixes that addressed many of the application access issues that happen when a user isn’t a local administrator. These were the limited user account (LUA) fixes, where an LUA is a non-administrator user with read-only access to system files and registry.

With Windows Vista, the LUA is no longer an exception, but has become the standard user account and applications have to be User Account Control (UAC) compliant. Security is no longer an optional extra and even running as a local administrator (protected admin) gives you a restricted and controlled environment.

Vista also provided the last addition to the application compatibility tools, the Standard User Analyzer. This completes a suite of tools that, as promised above, can detect and fix almost all of the access and file sharing issues commonly found with applications running on Terminal Services. The fact that it also gives you a handle on more difficult problems is a real bonus.

The changes in the compatibility toolkit from the earlier versions to Version 4.1 and finally the Version 5 beta indicates Microsoft’s path for the Application Compatibility Toolkit. The latest version is an automated pre-deployment tool that uses a client agent to gather data on application issues, saves this information to a central SQL database and then after analysis deploys fixes for those issues. While it’s intended to ease the way for Vista upgrades in an organisation, it would obviously be quite useful for workstation to Terminal Services migrations as well.

Rather than burying you in a lot of dry information, I thought the best way to show you is by example. What I’ve attempted to do is give you a brief introduction to each tool, and then take you through an example of how to use it.

The Application Verifier

I’ve lost track of the number of times I’ve used filemon and regmon to figure out whether an application on TS/Citrix was having registry or file system access issues. Then there were the break/fix cycles trying to run an application as a standard (non-admin) user and de-protect registry keys as an administrator until the application finally ran without errors.

That scenario has changed pretty radically because the application verifier lets you run an application as an administrator and identify all registry and file access operations that would fail if the application was run by a standard user. So you don’t have to test an application in a locked down environment or even on a TS/Citrix system to find out what it’s going to break.

There are several different versions of the Application verifier and from an informational viewpoint the one I prefer is version 2.5 which came as part of version 3 of the Compatibility Toolkit. It gives you easy to interpret information and logs.

The latest version of the Application Verifier (v3.3) is intended as a stand-alone developer tool to verify LUA and UAC compliance for new applications. It does its job very well but the XML logs produced are a bit more difficult to analyse manually, though it’s not to bad with the freeware XMLMarker ( Nevertheless regardless of whether you use the version 2.5 application verifier or not, you’ll still have to install version 3.3 to support the SUAnalyzer.


Let’s have a look at using the Application Verifier in a session with my favourite example application, Volo View Express. If an LUA user runs Volo View Express it starts with a registry access error. The first port of call used to be the NT registry monitor (sysinternals) but in this case we’ll run up the application verifier.

  1. The first step is to Add the executable you want to test by browsing to the executable file:

  1. Next you need to tick the Test Settings options that you want to monitor for this application, eg in this case I’ve ticked:
    Locks – Check lock usage.
    File  Paths – Checks system path usage.
    RegistryChecks – Checks registry usage.
    SecurityChecks – Logs potential security issues, this logs most of the LUA issues.
  2. Click on the Run button and when the application starts up, run all the different functions available. With Volo View Express that means opening a drawing file, scrolling/panning and printing the file. Close the application.
  3. Click on View Logs to see the application log:

The log shows we’ve got 2 types of LUA access violations (note the Microsoft comments to developers in italics):

Wrote to a non-Current User Registry Key

The application wrote to a non-Current User Registry Key. Applications should store information to the Current User section of the registry, which allows each user to have their own saved preferences.

Opened an object for too much access

The application opened an object (file, registry key, etc.) for a suspicious set of access permissions– usually all possible access permissions.  It is very unlikely that the application actually intends to use all of these access bits. Opening an object for too much access makes it difficult to distinguish legitimate access (by auditing the Security Log) from attack activity.  Further, it makes it difficult to restrict the security of the object in future implementations of the given software without damaging application compatibility. To fix this, determine what access the application really needs on the object and change the given API call to request only those permissions.

In both cases there is a complete log of all registry access violations caused by the application:

If we save the log, we can open the log file and extract the registry access violations (this is a partial sample):

| RegistryChecks 17 | 2 voloview.exe 49C04’SetValue: Write to non-HKCU registry entry ‘HKEY_CLASSES_ROOT\VoloView.Application.1’.

| RegistryChecks 17 | 2 voloview.exe 49C04’SetValue: Write to non-HKCU registry entry ‘HKEY_CLASSES_ROOT\VoloView.Application.1\CLSID’.

| RegistryChecks 17 | 2 voloview.exe 49C04’SetValue: Write to non-HKCU registry entry ‘HKEY_CLASSES_ROOT\VoloView.Application’.

| RegistryChecks 17 | 2 voloview.exe 49C04’SetValue: Write to non-HKCU registry entry ‘HKEY_CLASSES_ROOT\VoloView.Application\CLSID’.

| RegistryChecks 17 | 2 voloview.exe 49C04’SetValue: Write to non-HKCU registry entry ‘HKEY_CLASSES_ROOT\VoloView.Application\CurVer’.

We can now rework this to get a list of registry keys that have to be writable by a standard user. If we extract the keys only we get:






Note that any subkeys of keys already in the list (eg CLSID and CurVer) can be discarded.

At this point we can use several different strategies to make these registry keys available for read/write by a standard user:

Change Access Control

The first approach is very straightforward, simply change the access control list (ACL) of the key to allow writes.

I need to emphasize that while there are a number of command line registry ACL modifying tools, the only way that you should ever change machine registry or directory/file ACLs is by using a group policy. This is the only way to ensure that a documented and consistent change can be applied to all existing and any new or rebuilt servers in the OU.

The process is:

  1. Edit the group policy and navigate to Computer Configuration > Windows Settings > Security Settings > Registry. Right click and select Add Key

  1. Browse to the key you want to de-protect and click okay, then tick Full Control for Users and click Apply:

  1. Tick Do not allow permissions on this key to be replaced and click Apply

  1. Repeat this process for the rest of the keys you need to de-protect.

  1. Record the GUID of the group policy by right clicking on the heading and selecting properties.

The Unique name or GUID of this group policy example is {60D0AFB2-3397-48A5-9994-E82C67E575E6}, yours will be different.

Windows 2000 Server and Windows Server 2003 inherited the NT 4 security policy mechanism. So when you apply file or registry permissions using group policy, all you’re doing is creating a group policy security template file (GptTmpl.inf) that will be applied to your servers.

In this example the security template is under

\\test\sysvol\\Policies\{60D0AFB2-3397-48A5-9994-E82C67E575E6}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

and when the group policy update happens this gets copied to the %systemroot%\security\templates\policies on the servers in the OU and the access control changes are applied.

If we have a look at this file we can see the registry ACL changes listed under the [Registry Keys] section:

[Registry Keys]

If you’re interested in what this all means, the interesting bit is (A;CI;KR;;;BU) which assigns all (A) rights to the built-in users (BU). These are Security Descriptor Definition Language (SDDL)  entries  and there’s a quick SDDL summary at

The problem with adding the registry change ACL entries manually is that it takes a long time, and if you’ve got 30-40 or more registry keys to de-protect the chances of making a mistake are excellent.

However there’s nothing at all stopping you from adding the key names and SDDL values straight into the GptTmpl.inf file, and then incrementing the version number in


After that your changes will be applied.

Virtual HKCR

A second way to accomplish a similar end result is to make use of the user’s virtual HKCR, HKCU\Software\Classes. If you run the NT registry monitor you’ll see that the operating system accesses HKCU\Software\Classes entries before it accesses HKCR. So if a key/value exists in HKCU\Software\Classes it will be used instead of the one in HKCR.

If we write a script to populate the required keys under HKCU\Software\Classes, or do the same thing to the default user profile for a new server installation, we don’t have to worry about de-protecting the keys under HKCR.

Use an Application Compatibility Fix

The other way to do it, if you aren’t still running Windows 2000 Server, is to use an application compatibility fix, LUARedirectReg (to be discussed later) which automatically creates all the keys and values under HKCU\Software\Classes whenever the “fixed” app tries to write to HKCR. On a Windows Server 2003 system (but not 2000 Server) with the LUARedirectReg applied to an application you don’t have to do anything else to allow write access to registry keys.

It’s also worth mentioning that if you’ve got Windows Server 2003 Enterprise (or DataCenter) the operating system acts as if LUARedirectReg is applied to all applications.

Just in case you’re asking why I showed you how to do it via group policy, it’s because it IS the only way you should change the ACL on any system registry key or file/folder and it provides a fast fix for some of the simpler access issues.

A Warning!!

The newer versions (v3+) of the application verifier set registry flags so that the monitoring shims are applied to every instance of the executable when its run and all violations etc get logged. This can add a huge overhead to a production TS/Citrix system. When you’ve finished monitoring an application, be sure to use the Remove option to terminate the application monitoring (see below).

In the second part of this series we’ll be looking at the Standard User Analyzer and the Application Compatibility Administrator.

If you would like to read the next article in this series please go to The Microsoft Application Compatibility Tools (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top