Application Manager URM and ANAC features are not working

Version 1

    Verified Product Versions

    AppSense Application Manager 8.7AppSense Application Manager 8.6AppSense Application Manager 8.5AppSense Application Manager 8.4AppSense Application Manager 8.3AppSense Application Manager 8.2AppSense Application Manager 8.1AppSense Application Manager 8.0


    URM and ANAC rules do not apply when Performance Manager is running on a 64 bit end-point.


    If the Performance Manager Optimizer feature has optimized the AMAppHook.dll or AMLdrAppinit.dll files, it is possible that the 8.3 short names that have been created for the "Program Files" and "Program Files (x86)" folders in PM's appsensecache folder, which can be viewed with the "

    dir /x
    " command, are the opposite way around to the short names for "C:\Program Files" and "C:\Program Files (x86".

    When this short name path is used to load the dll into a process, such as needs to be the case for anything specified in the appinit_dlls registry value, the PMOptimizer driver performs a simple path substitution to create the path to the .reloc optimized dll, if it exists, in the appsensecache folder. This simple path may then point to a 32 bit Optimized dll which cannot be loaded into a 64 bit process or vice versa.

    To see if this is the reason for the incorrect AM behaviour, firstly see what the short names of the original folders are by running the following command (which assumes that %ProgramFiles% and %ProgramFiles(x86)% are the defaults:


    dir /x /ad %SystemDrive%\Program*

    Which will give output similar to the following:


    Directory of C:\

    20/12/2013  14:45    <DIR>          PROGRA~1     Program Files

    26/12/2013  07:12    <DIR>          PROGRA~2     Program Files (x86)

    26/12/2013  07:12    <DIR>          PROGRA~3     ProgramData

    Where we can see that the short name for "

    Program Files
    " is
    and for "
    Program Files (x86)
    " is

    Note that if there are no short names shown then this will also explain why AM is not functioning correctly - please refer to TN-150721 instead.

    Now see what the shortnames are for the folders in the PM Optimizer cache folder by running (assuming that the PM configuration uses the default cache location):


    dir /x /ad %SystemDrive%\AppSenseCache
    Which will give output similar to the following:



    Directory of C:\AppSenseCache

    20/12/2013  18:00    <DIR>                       .

    20/12/2013  18:00    <DIR>                       ..

    20/12/2013  18:00    <DIR>          PROGRA~2     Program Files

    24/12/2013  10:03    <DIR>          PROGRA~1     Program Files (x86)

    20/12/2013  18:00    <DIR>                       Users

    20/12/2013  18:00    <DIR>                       Windows

    We can see that the short names for "

    Program Files
    " and "
    Program Files (x86)
    " in the appsensecache folder are the opposite way around to those in c:\ which will cause the wrong bitness of dll to be attempted to be loaded which will fail.

    If the short names are present and the same way around then short names are not causing the issue.

    If short name creation is enabled on the drive where the Optimizer cache folder is located (which is \appsensecache by default on each local drive on the end-point unless the single drive caching mode introduced in PM 8.2 is in use), then the following commands can be run as an administrator to fix this issue:


    cd /d %systemdrive%\appsensecache


    fsutil file setshortname "Program Files" temp


    fsutil file setshortname "Program Files (x86)" PROGRA~2


    fsutil file setshortname "Program Files" PROGRA~1

    If Optmization has not yet happened at all, or no"Program*" folders exist in the appsensecache folder, then another option is to pre-create the folders manually, in the correct order, such that the short names are then in place ready for any optimized component that does need to be stored in these folders, i.e. run the following in order:


    md "%SystemDrive%\appsensecache\Program Files"


    md "%SystemDrive%\appsensecache\Program Files (x86)"

    Running the

    dir /x
    command should now show the short names are the same as for the "
    Program Files
    " and "
    Program Files (x86)
    " in

    It should also be noted that this problem may affect folders other than those already mentioned, for instance, Microsoft Office stores a large number of dll paths in short name form in the registry so folders like "

    %SystemDrive%\Program Files\Microsoft Office
    " may also cause problems if these dlls are Optimized and other "Microsoft*" folders exist already in the Optimizer cache folder hierarchy.