06/25/10

Working on the transform for Office 2007 Compatibility Pack, I encountered an interesting problem when system search for an existing registry key under HKCR was failing, even though the key did exist in the registry and was accessilble by the user. The installation was using this system search to find location of winword.exe.

The reason for the mystery was in the fact that HKCR is not a real key but “synthetic”; it is assembled from the real HKLM/Software/Classes and HKCU/Software/Classes. In this case, the key that was looked up by the system search existed under HKCU but not under HKLM. Consequently, it was visible to the user, but not to the Windows Installer service - probably because the latter was running with NT AUTHORITY credentials.

Every installation has three phases - UI, Immediate Execution, and Deferred Execution. Only the first phase, UI, runs with user credentials; then Installer switches to the service, and the 2nd and 3rd phases run with machine credentials, thus unable to find anything related to the user. It looks like the custom actions called by installer are run by impersonated service (according to what we see in the installation log), but standard actions are not.

As the result, action AppSearch in the Immediate Execution phase won't find any HKCU-originated part of HKCR - which is usually anything from any installation installed per-user. One way to resolve this problem is by a custom action doing the same thing - custom action runs impersonated, and will find the value.

I have verified however that this happens only with HKCR, but "true" keys from HKCU are found correctly.