Windows Installer on 64-bit Platforms

Windows Installer on 64-bit Platforms

  • Comments 25

Beginning with Windows Installer 2.0 installation developers can write installation packages that target 64-bit platforms. At first only IA64 was supported but support for AMD64 — now collectively referred to along with EM64T as x64 — was added in Windows Installer 3.0. Many questions are asked regarding how to author 64-bit packages and merge modules so I will attempt to enumerate and briefly explain the available resources here.

The point of authoring a package differently for 64-bit platforms is to deploy 64-bit binaries and write registry values for 64-bit access correctly. While you can install a 32-bit application on 64-bit Windows, files for 32-bit execution will be redirected to different folders and some registry values for 32-bit access will be redirected to a different parent registry key. Before you can control where files are installed on 64-bit platforms you must author your installer database as a 64-bit installation package. To do this you must set the Template summary property to either Intel64 or x64; Intel, Intel64, and x64 are all mutually exclusive. For these values to be effective the database schema must be set to at least 200.

To make sure that the file system and registry aren't redirected when installing 64-bit executables, their support files, and registry values for 64-bit access, components that contain those files and registry values must be marked appropriately with the msidbComponentAttributes64bit (256) attribute in the Component table and must target the appropriate 64-bit directories. Components and actions can also be conditioned to install or run only on 64-bit platforms.

If you're authoring a 64-bit package with both 32- and 64-bit binaries, make sure that they resolve to different source and target directories when considering how they lay out on installation media and how files will be extracted during an administrative install otherwise 32- and 64-bit files will overlap each other and cause problems. If a 32-bit component is contained in both a 32-bit installation package and a 64-bit installation package it may have the same component ID but 32- and 64-bit components should have different component IDs, just as 32- and 64-bit products should have different product codes.

For 64-bit installation packages you'll probably want to run 64-bit custom actions. 64-bit executables will run in either a 32- or 64-bit custom action server correctly but script custom actions must be marked as either running in a 32- or 64-bit script host by being marked appropriately with the msidbCustomActionType64BitScript (4096). Custom action scripts are not recommended, however.

If you want to author merge modules that contain 64-bit binaries and support files and want to merge them into a 64-bit installer package, you'll also need to set the Template summary property to either Intel64 or x64. Only Intel64 merge modules can be merged into Intel64 installer packages, and only x64 merge modules can be merged into x64 installer packages. 32-bit merge modules can be merged into any installer package.

To help validate that an installation package is authored correctly to install 64-bit binaries and support files and registry values, be sure to run validation — especially ICE80.

There are also error codes and Windows Installer error messages you might want to handle that relate to installing 64-bit packages.

  • 1633 — This installation package is not supported on this platform. Contact your application vendor.
  • 2401 — 64-bit registry operation attempted on 32-bit operating system for key [2].
  • 2943 — This version of Windows does not support deploying 64-bit packages. The script [2] is for a 64-bit package.
Leave a Comment
  • Please add 3 and 7 and type the answer here:
  • Post
  • I am looking at installing custom keyboard layouts, files whose WOW64 binaries are not identical to the x86 ones --- so it is not as simple as just having an x86 install and an x64 install.

    And the simple fact is that users don't want six different kinds of installers for a single file....
  • Michael, 64-bit properties for 32-bit packages are still defined on a 64-bit Windows platform. So, you could condition your components so that the true 32-bit component uses the condition "NOT VersionNT64". The WOW64- and 64-bit component would be conditioned on "VersionNT64" and both targeted to the SystemFolder, which Windows Installer will redirect as necessary. Of course, if you have separate components for IA64 and x64 you should also use in the condition either Intel64 or x64 (the AMD64 property is deprecated).
  • Ok, that is starting to make sense now....

    So how do I get to the true 64-bit system32 folder if I am a 32-bit package? Or do I really need two separatae installers?
  • Michael, bitwise OR 256 (msidbComponentAttributes64bit) in the 64-bit components' Attribute column in the Component table. Use the System64Folder for the true 64-bit components' target directory.
  • Aha, perfect! This seems to work perfectly for all flavors (and all binaries within each flavor). Thanks!
  • I am trying to run a power shell script as a custom action. this works great on 32 bit machines but on a 64 bit machine the wrong power shell binaries are called, 32 bit binaries are called instead of the 64 bit. I have marked the custom action for Win64. will appreciate any pointers or help on this.

  • jsingh, unless your MSI is marked for 64-bit installation (Intel64 or x64), the server context runs in a 32-bit process (in WOW64). So, paths are translated accordingly to use the 32-bit binaries.

  • I previously posted an example that allows you to build a WiX-based MSI that will install a Windows Vista

  • I previously posted an example that allows you to build a WiX-based MSI that will install a Windows Vista

  • None of the MSDN article links are working.

Page 2 of 2 (25 items) 12