Case of the Windows Installer installation failure and AppCompat shim

Case of the Windows Installer installation failure and AppCompat shim

  • Comments 2
  • Likes

Good morning AskPerf! Anshuman Ghosh here to chat about an issue I recently worked where a specific Windows Installer package failed to install on a Windows 2008 R2 Server.  Basic Windows Installer troubleshooting took place, including the ability to install other .msi packages successfully.  I then enabled Verbose MSI logging per KB223300:

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]

Reg_SZ: Logging

Value: voicewarmupx

and the following was observed:

clip_image002

I used the Err utility to convert the error code:

C:\>err 0x8002801C

# for hex 0x8002801c / decimal -2147319780 :

TYPE_E_REGISTRYACCESS winerror.h

# Error accessing the OLE registry.

# 1 matches found for "0x8002801C"

This error translates to “Error accessing the OLE registry”.  From the msi verbose log, we know that the error came while executing the function call DoRegisterTypeLib in a custom action for msxml3.dll in the SYSWOW64 folder.  With this information, we captured Process Monitor logs from a working and non-working machine and observed the following:

clip_image004

The registry entry in question, [HKCR\TypeLib\{F5078F18-C551-11D3-89B9-0000F81FE221}\3.0\0\win32], is being accessed by the 32bit process on the non-working machine.  If you drill into the stack trace of the highlighted line, you can see the RegisterTypeLib function call:

clip_image005

The handle to the reg key is then closed and there is nothing else significant after the RegQueryKey operation above.  On a working machine, we see a significant difference as it continues to query the security and subkeys:

clip_image007

The thread stack for the highlighted line shows the following:

clip_image008

It would appear that the specific function call is being shimmed by appcompat.  So, why is the shimming not occurring on the non-working machine?  The answer is at the beginning of the log, when the apphelp.dll loads in the msiexec process.  The following registry key is checked:

[HKLM\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

DisableEngine=

And sure enough, it was set to a 1.  Application compatibility engine can be turned off by either setting the above registry entry to 1 manually, or by configuring the “Turn off Application Compatibility Engine” group policy setting under “Computer Configuration | Administrative Templates | Windows Components | Application Compatibility.”

Additional Resources:

-Anshuman Ghosh

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Good find but you might want to go into Microsoft compatibility toolkit to modify the shim instead to stop it from running that individual shim rather than disabling it all together.

  • The issue is not with any shim, but the fact shimming was altogether disabled. Ensuring that appcompat engine is enabled, gets us through the installation