2

The installer I'm working on has a component that installs registry elements into the 64bit HKLM hive, and installs similar keys into the 32bit hive (under Wow6432Node). On install the log shows the 64bit: 

MSI (s) (40:30) [13:29:49:879]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\Company\Product,,BinaryType=1,)
MSI (s) (40:30) [13:29:49:879]: Executing op: RegAddValue(Name=MyValueName,Value=MyValue,)
WriteRegistryValues: Key: \SOFTWARE\Company\Product, Name: MyValueName, Value: MyValue

then later the 32bit..

MSI (s) (40:30) [13:29:49:910]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\Wow6432Node\Company\Product,,BinaryType=1,)
MSI (s) (40:30) [13:29:49:910]: Executing op: RegAddValue(Name=MyValueName,Value=MyValue,)
WriteRegistryValues: Key: \SOFTWARE\Wow6432Node\Company\Product, Name: MyValueName, Value: MyValue

However, when I go look in the registry at HKLM\Software\Wow6432Node\Company\Product, the value isn't there.

thekbb
  • 7,668
  • 1
  • 36
  • 61
NGaida
  • 688
  • 3
  • 10

2 Answers2

0

It's impossible to answer with the data provided. Perhaps the installer aborted and rollback. Perhaps another component duplicated the registry data and changed it later. Perhaps a custom action fired and reset the value. Or even another MSI that was part of a bootstrapper stepped on it.

I'd need to spend time on a VM testing your installer to know exactly what happened. There is no systemic problem in WriteRegistryValues that I'm aware of.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Sorry, I should have added: the installer completed successfully. No custom actions that touch this value, or other MSI files that run and edit that location. – NGaida Oct 23 '13 at 21:47
  • The only other information is that I changed the component from a 32bit component (with only the default SOFTWARE\Company\Product) to a 64bit component with both 64bit and 32bit paths inside of it. The issue shows up when upgrading from a previous build to the latest. – NGaida Oct 23 '13 at 21:49
  • Are you doing major upgrades or minor upgrades? If major, where is RemoveExistingProducts scheduled? – Christopher Painter Oct 24 '13 at 00:11
  • Major - we change the product code every build. RemoveExistingProducts is scheduled immediately after InstallValidate. – NGaida Oct 24 '13 at 15:20
0

"...the issue shows up when upgrading from a previous build to the latest"

Since this is the case I would:

  • Split the 32 and 64 bit sections to use two different components. It that is possible.
  • Set the key path of the new component to the location that was NOT set by the previous install. In other words: ensure both components have key paths and that they are different.
  • Enable "re-evaluate component condition" (transitive component) for both components. This re-evaluates installed component conditions during reinstall. In other words determines whether they are to be installed, reinstalled or removed on the system.

If the component key path for the previous install exists on reinstall, the new registry key that you have effectively added by enabling 64 bits will not be installed since a component is only installed as a whole or not at all.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164