The Microsoft Application Compatibility Tools (Part 2)

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

The Standard User Analyzer (SUAnalyzer)

The Standard User Analyser is just plain brilliant. It uses the application verifier at the back end to generate additional application logging that looks at everything including privilege and token use. In fact, if you’ve only got the Version 3.X application verifier and don’t like the idea of trawling through a bunch of XML logs then using the SUAnalyzer makes things much simpler and easier to interpret.

Example:

Running the SUAnalyzer as administrator is straightforward:

1. Select the App Info tab.

2. Click the Browse button and navigate to the target application executable file, in this case d:\apps\infopak\infopak.exe.
3. If any command line parameters are required input them into the Parameters field (none in this example)
4. If you were a non-admin you’d need to tick the Launch Elevated checkbox (but its set by default for an administrator) and then click the Launch button.

Once SUAnalyzer has launched the application, it will monitor the application process and all child processes and wait for the application to close. It will then generate and parse a log for the application, which can take several minutes on a slower machine.

Note:
SUAnalyzer will wait for all child processes created by the application to exit before it starts to load the log file. So if it seems to be taking forever you can assume that all the child processes haven’t terminated and you may need to kill the processes manually. Either that or use the Refresh Log button to load the log file.

If you save the log file (it saves as a .CAB archive) you can also open the log file later to continue your analysis.

The following table outlines the report functions available in SUAnalyzer by tab:

If you double click an item (provided View > Detailed Information is enabled), SUAnalyzer will display all related records from the log file in the bottom pane. If you click on a record in the left bottom pane, the lower right pane will display the detailed information for that record, including a detailed message and the stack trace.

Actions that need administrator or enhanced privileges are automatically highlighted so you’re directed to the stuff you need to know.

Example:

I’ll run through an example that caused me a bit of grief before the SUAnalyzer came along, Info Pak version 5.6. This application can be used to fully document how to use an application by recording application use and playing “documenting” the process steps into a word document.

If you start Infopak as an administrator, it opens a nominated word document, sets everything up and then pauses the process recorder (see below)

However when a standard user (non-admin) tries to start things up, the recorder never starts (not even paused).

I threw everything at Infopak.exe trying to find out where things were failing, and aside from a .Net error that didn’t point us in the right direction, there was no indication that there was anything failing.

Then I tried SUAnalyzer.

One of the great things that SUAnalyzer does is it also monitors all child processes. That’s when the penny dropped because it was when winword.exe tried to use some admin privileges that things were being hosed.

When I ran SUAnalyzer against Infopak.exe I got the following “privileges used” result. Note this was done as administrator so the application could run and be fully monitored.

Notice that we’ve even got neat stuff like a stack trace of the function used:

vfluapriv2!NS_LuaPriv::AuditPrivilege+154 vfluapriv2!NS_LuaPriv::VfHookNtAdjustPrivilegesToken+88 ADVAPI32!AdjustTokenPrivileges+1e SETUPAPI!CM_Get_Device_Interface_List_Size_ExW+111b SETUPAPI!CM_Get_Device_Interface_List_Size_ExW+fd8 SETUPAPI!CM_Get_Device_Interface_List_Size_ExW+3b SHELL32!SHGetMalloc+5e2 SHELL32!SHGetMalloc+580 SHELL32!SHGetMalloc+459 SHELL32!SHGetMalloc+525 SHELL32!Ordinal57+ba SHELL32!SHGetFolderPathW+50b SHELL32!SHParseDisplayName+206 SHELL32!SHParseDisplayName+147 SHELL32!SHParseDisplayName+372 SHELL32!SHParseDisplayName+310 SHELL32!SHParseDisplayName+147 SHELL32!SHParseDisplayName+94 SHELL32!SHILCreateFromPath+5d SHELL32!DllCanUnloadNow+5e3 SHELL32!ILFindChild+39 SHELL32!SHGetFolderLocation+68 SHELL32!SHGetSpecialFolderLocation+17 mso!Ordinal7+500 mso!MsoCreateIOLDocFromWzPersistentName+2bf mso!MsoCreateIOLDocFromWzPersistentName+2b WINWORD!+3022dcac WINWORD!wdCommandDispatch+49586

The other privilege uses, (SeSystemtimePrivilege and SeUndockPrivilege) turned out not to be unimportant, but what was required in this case was giving Infopak users the “Load and unload device drivers” privilege so that Infopak would work properly. While this does raise some security issues, the users involved were all trusted and giving them the privilege was considered justifiable.

An additional issue was that winword.exe checked to see if the Infopak user was running as administrator, eg under the Token tab:

This required the ForceAdminAccess compatibility fix (described in the compatibility administrator section below) so we could mask the failure. Then there were a number of registry keys as well but an LUARedirectReg compatibility fix took care of that.

A Warning!!

One thing to watch is that if you are modifying a privilege using group policy is that group policy-applied privilege assignment REPLACES the local privilege assignment. This is a big deal because if you get it wrong and remove a critical local user from the local privilege (like SERVICE), things can break in very interesting ways. Believe me, it does, I know.

It’s actually far less dangerous to use the Windows Server 2003 resource kit NTRights utility because it lets you append additional privileged users to the existing local privileges without losing anything, eg in this case:

ntrights –u “domain\Citrix Infopak users” – m \\TSserver +r SeLoadDriverPrivilege

Extras

One fantastic feature can be seen if you scroll over the right hand most column seen under the Registry or File tabs. The column is titled “Work with Virtualization”. It tells you what file/registry keys can be handled within in a virtualized application, and what holes need to be made to allow the application to access external resources.

The Name Space and Other Objects logs complete a very comprehensive picture of what you application is doing.

SUAnalyzer gives you almost all the information you ever need to know to fix most applications so they run properly for standard users. If you had to choose only one tool to help you examine application problems, this would have to be it.

Application Compatibility Administrator

Once you’ve found out what’s broken, this is the tool that let’s you fix many of the issues by applying application compatibility fixes to the applications.

I’ve listed a table of the more interesting fixes out of the more than 200 fixes available. The brilliant LUA fixes aside, anyone who’s had a slow Interbase server based application would love SingleProcAffinity, and SearchPathInAppPaths is great for published applications that fail because the required DLLs are in multiple folders.

Compatibility Fix	Description of Fix
DisableScreenSaver	Disables the screen saver at application start-up and restores it on termination of the application. It’s useful for DirectX applications that don’t work well with an active screen saver.
ForceAdminAccess	Addresses issues that may be encountered when an application uses the CheckTokenInformation API call to verify if the current user is part of the Administrators group. The fix intercepts calls to CheckTokenInformation and returns a value of true.
HideTaskBar	In Windows XP, the WS_EX_CLIENTEDGE window style causes applications to run with the taskbar still visible. This may not be the expected behavior for some applications running in full screen mode. This compatibility fix simply removes the flag and enables the application to correctly use full screen mode.
LocalMappedObject	Force all Global named file mapping objects into the Local namespace
LUARedirectFS	Redirects files to %SystemDrive%\Documents and Settings\username\LocalAppData\Redirected\drive\filepath when the application needs to write to them but doesn’t have the appropriate access rights.
LUARedirectReg	Applications may incorrectly attempt to write to the HKEY_LOCAL_MACHINE portion of the registry. This compatibility fix redirects the registry keys to the HKEY_CURRENT_USER hive when the application doesn’t have the necessary permissions.
LUATrackFS	Determines the directories used by an application and records those directory names in a file. This information can be used to determine the changes required to make the application LUA compliant.
MoveIniToRegistry	Applications may still be storing data in INI files instead of using the registry. This is a generic compatibility fix to move INI data into the registry. The compatibility fix is command line driven.
SearchPathInAppPaths	Intercepts calls to the SearchPath API and modifies the command to also search the shell’s App Paths registry key.
SetEnvironmentVariable	Enables the application to set specific environment variables at application start-up. These variables are provided through a command line, and multiple environment variables in the list should be separated by a pipe (|) character.
SingleProcAffinity	Set single processor affinity for apps that have multi-proc bugs.

The user interface on the compatibility administrator is a bit complicated at first glance, but is actually quite easy to use.

Example:

A lot of older applications open registry keys for full access even when just read only access is required. This example fixes the registry access errors that Volo View Express gets when it tries to create/delete keys under HKCR (in the application verifier example above).

The same fix works for Photoshop, RFFlow and a whole bunch of other older applications:

1. Run the Compatibility administrator and select Custom Databases > New Database, right click and select Rename. Name the application fix, eg Voloview Fix. This is an optional cosmetic change but it helps you keep track of things if you’re doing multiple fixes at once.

2. Right click Voloview fix, and select Create New, then Application Fix.

3. Enter the application name, eg Voloview, Application vendor (optional) and browse to the application executable file. Then click on Next.

4. Select None for the operating system mode and click on Next

5. Select LUARedirectReg, make sure the box is ticked and click on Next

6. The next screen allows you to confirm to which version of the executable the application compatibility fix will be applied. Click on Finish to complete.

7. Select File > Save  to save the custom application compatibility database, in this case Voloview_fix.sdb. Save the database either in a dedicated fixes area, or in the same directory as the executable. Click on Save.

8. To install this application compatibility fix, select File > Install in the app compat admin GUI, eg

9. A bit of documentation needs to be done before you finish. Each application fix database is given a unique GUID which will be needed if you want to uninstall the fix. Right click on the custom database, Voloview_Fix and select Properties , eg

Record the GUID, in this case {315b1bd4-98a8-4e7e-815e-0506c5f47e43}.

If you want to install this application compatibility fix on all servers in a Citrix server farm:

1. Copy voloview_fix.sdb to all the farm servers:
   for /f “skip=3” %i in (‘qfarm /load’) do copy “d:\apps\volo view express\voloview_fix.sdb” \\%i\c$\temp
   

2. And then install the fix using psexec (sysinternals pstools):
   for /f “skip=3” %i in (‘qfarm /load’) do psexec c:\windows\system32\sdbinst.exe c:\temp\voloview_fix.sdb
   

It’s that simple.

What happens now is that as an LUA user runs Volo View Express, when the application attempts to modify (write/create/delete) any value or keys under HKCR, the LUARedirectReg application compatibility fix will redirect those modifications to HKCU\Software\Classes.

It’s worth noting that this approach works for Access 97 co-existing with Access 200X as well as a huge number of other older applications. And it’s dead simple to add the compatibility fix to a scripted application install. For example:

:: install RFFlow 5.02 cd /d “y:\RFFlow502_msi” msiexec /i “rfflow502.msi” /l*v c:\install\rfflow_msi.log /qb- :: apply appcompat fix for RFFlow to suppress registry access errors sdbinst -q c:\install\appfixes\rff_fixes.sdb

If you want to remove the application compatibility fix, all you need is the GUID of the fix (which is why I had you record it), and run sdbinst –g {guid} eg

Other Compatibility Fixes

As I mentioned earlier, there are a bunch of useful application compatibility fixes for terminal services (and locked down workstations). On the LUA side of things we’ve got LUARedirectFS which will take care of applications that have their configuration files in the executable directory and also ones that write temporary files to the application directory or a global location. Eg

LUARedirectFS can be used to redirect c:\program files\myapp\myapp.ini to %userprofile%\appdata\local\virtualstore\program files\myapp\myapp.ini.

Conclusion

Any more material and this would turn into a book, but I hope I’ve managed to give you an idea of some of the things you can do with the application compatibility tools.

They are easy to use and provide a very elegant and efficient solution for many application issues. As well, the SUAnalyzer provides extremely comprehensive information about the privileges an application needs to run and can be used to solve a whole bunch of application issues that were previously real stinkers.

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