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
PROGRA~1and 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%\AppSenseCacheWhich 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)"
dir /xcommand 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.