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 8 and 3 and type the answer here:
  • Post
  • > To make sure that the file system and
    > registry aren't reflected when installing
    > 64-bit executables,

    Obvious Lee's spill chequer past "reflected" widow terror. But I think you meant "deflected"? We want the directories and registry to reflect the actual configuration instead of being deflected to 32-bit targets.

    (I've finally ordered parts for a 64-bit machine and will build it some weekend soon, but when will I finally have time to experiment with software on it, sigh. Dilbert was spot on today, talking about unpaid overtime.)
  • No, registry reflection is for a shared view of the registry as documented at http://msdn.microsoft.com/library/en-us/win64/win64/registry_reflection.asp. That should've read "redirected" which is documented for the registry at http://msdn.microsoft.com/library/en-us/win64/win64/registry_redirector.asp and for the file system at http://msdn.microsoft.com/library/en-us/win64/win64/file_system_redirector.asp.
  • Id just like to point out to anyone googling this, that 64-bit customs actions (in a 64-bit assembly) do not work in Visual Studio 2005 at the time of writing (V8.0.50727.42). The installation will fail to execute the action and you will receive a " System.BadImageFormatException: Attempted to load a 64-bit assembly on a 32-bit platform ... " Now the reason for this is no matter what flags you set in VS, the msiexec.exe will always run in 32-bit mode. I have verified this with microsoft. It seems as though VS does not setup the msi configuration properly and always references the 32-bit framework. I have come across two work arounds for the problem. #1 - Open the .msi in Orca. - Double-Click [Binary Data] in the Data column for InstallUtil row - In the 'Edit Binary Stream' dialog, choose Action 'Read binary from filename' and click the Browse button. In the Open dialog, go to the following folder - "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727" and select InstallUtilLib.dll. Choose OK and the following dialog boxes. - Save the .msi and test. OR #2 Use a VBscript as a custom action. In the VBSCript reference the C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\msiexec.exe and the DLL you want to execute as your custom action. References: http://support.microsoft.com/default.aspx?scid=kb;EN-US;816169 http://support.microsoft.com/default.aspx?scid=kb;EN-US;870712 Hope this helps someone else!
  • Jonathan, even replacing the binary with the 64-bit equivalent will not be enough. You'll also need to set the Template summary property to include X64 (AMD64 also works but is deprecated). Without doing that even running the MSI on a 64-bit platform will install only as 32-bit. For any 64-bit component or custom action attributes to work you must either have X64 or Intel64 (for Itanium) specified in the Template summary property. But yes, you are correct that Visual Studio's Windows Installer project doesn't support 64-bit installations. For this and many other reasons I don't recommend using it for serious projects. Wix (http://wix.sourceforge.net) is a good project to use.
  • See http://blogs.msdn.com/heaths/archive/2006/02/01/522378.aspx for more information about the problem and workaround that Jonathan describes.
  • >>To do this you must set the Template summary property to either Intel64 or x64; Intel, Intel64, and x64 are all mutually exclusive.


    How can I do this using WIX?

    Thanks,
    Pratheesh
  • Pratheesh, see the documentation for the Package element, specifically the Platforms attribute. Set that attribute to one of the tokens I mentioned, namely x64 (avoid using Intel64, as it is now deprecated but will likely be supported for quite some time at least), Intel, or Intel64.
  • Are you sure about Intel64 being deprecated?  I thought that Intel64 was for Itanium?  Isn't it:

    Intel = 32 bit (IA32)
    x64 = AMD64 and EMT64
    Intel64 = Itanium (IA64)
  • John, good catch. That was a mistype. I meant to type "AMD64" instead of "Intel64", which I even go so far as to list past my parenthetical quip. Sorry about that.

    So, "AMD64" is deprecated and you should use "x64" instead in the Template summary property.
  • Hi,
    Using x64 in the Template Summary property doesn't seem to work for me per ICE80 and errors about the type in the Component table, but AMD64 does.  Also, using Orca 3.0.3790.371, the View->Summary Information doesn't have x64 as a choice per Platform...
    Do I need new versions of Orca or ICE80?
    Thanks,
    Jay
  • Jay, yes you do need the 3.1 version of Orca or newer and its corresponding .cub files for ICE80 to detect "x64" properly.
  • Ok, I know you are saying it is impossible, but couldn't I creatively use Wow64DisableWow64FsRedirection in a custom action to create a 32-bit install that could handle both x64 and x86 for a simple install of a single file in the system32 dir and a single file in the syswow64 dir?
  • Michael, custom actions of various types (like base type 1 custom actions) run out-of-process. Calling process-scoped functions like that won't do the actual install any good.
  • Well, what if I did the installation inside the custom action as well, then?

    It would violate a principle or two, but only because of the limitations imposed by the tools.... :-)
  • Michael, that would void any reason of using MSI in the first place. Custom actions are used by the install, not vice-versa. Even messing directly with feature and component states in CAs is dangerous and should be avoided.

    What is the nature of this single file, though? 32- and 64-bit executables should be in different components, and should be installed into the proper location. 32-bit files shouldn't be in syswow64 and vice versa for 64-bit files. What exactly are you trying to accomplish?
Page 1 of 2 (25 items) 12