Any given .MSI package is processed as either 32-bit or 64-bit.  Depending on the bitness of the process that starts msiexec.exe, the 32 or 64-bit client process may process the user interface of the package, but in the end it is always handed over to the 64-bit Windows Installer Service.  Let's unravel some of the mysteries of how this all works and any implications for your packages and processes.

Windows Installer packages can be marked as 64-bit in the summary information stream.  Unfortunately this flag is not exposed in the package log.  Although there are a variety of log signatures that can be used to determine whether the package ran on a 64-bit machine and which of the software application items are 32-bit and 64-bit (Intel64, Msix64, component flags, custom action flags), there does not seem to be a way to determine if the MSI package itself is flagged 32 or 64-bit.  The 64-bit flag is indicated by the presence of "x64" or "Intel64" in the Template Summary Property of the Summary Information stream.  Summary Information stream properties are not automatically detailed in a log file.

In reality, it doesn't matter that much and here is why...

Whether an MSI package is marked as 32-bit or 64-bit - all elements of the package are assumed to be 32-bit unless marked otherwise.  Within MSI any legacy abstracted references (e.g. "System Folder Properties") are pointed to 32-bit locations even if the package is flagged as 64-bit.  In other words, unless you tell MSI that a specific element of the package is 64-bit, it will process it as 32-bit, even if the package is marked 64-bit.

Check out our Windows 7 Packaging Engineer (ENG-51) course where we ramp up your skills for deploying applications to Windows 7, Windows Installer 5 and 64-bit.

How can you prove this?  Take a current 32-bit package.  Use Orca to flag it as a 64-bit package.  Run it on 64-bit Windows - it will install exactly as before and the logs will be identical.

To do this, click "View" then "Summary Information" and under "Platform" choose "x64" like this:

Here are some examples of how Windows Installer always assumes 32-bit processing unless told otherwise:

• The SystemFolder, CommonFilesFolder and ProgramFilesFolder all default to the 32-bit locations and are used with all components not marked as 64-bit, even if the package is marked as 64-bit.
• For 64-bit the package developer must reference System64Folder, CommonFiles64Folder and ProgramFiles64Folder when installing 64-bit software.
• 64-bit components must be marked with the msidbComponentAttributes64 flag.
• 64-bit ODBC drivers have special requirements (component name must be "ODBCDriverManager64)
• Scripted custom actions must be marked with the msidbCustomActionType64BitScript flag.
• All other custom actions are executed in their native bitness - if an EXE or DLL is 32-bit it is executed as 32-bit.

When examining a package it is fairly straight forward to see how file locations are properly handled.  The ProgramFilesFolder property is mapped to "C:\Program Files (x86)" and SystemFolder is set to "C:\Windows\SysWOW64"

But how are registry properly directed to the 32-bit software registry when necessday (to either "HKLM\Software\Wow6432Node" for 32-bit and "HKLM\Software" for 64-bit)?  

Again, it does not depend on the marking of the package as x64, but on the marking of the component that the registry keys are a part of.  If a component is NOT marked with the msidbComponentAttributes64 flag, registry keys destined for "HKLM\Software" are redirected to "HKLM\Software\Wow6432Node".  If the component is marked with the msidbComponentAttributes64 flag, then keys destined for "HKLM\Software" go to that exact location.

Given that it is very common for "64-bit Editions" of software to contain either all 32-bit EXEs or a mix of 32-bit and 64-bit EXEs, Windows Installer must be able to install both even for packages marked as 64-bit.

Let's take a quick look at some inconsistencies that could come up in packages that you receive or build that are flagged for 64-bit MSI processing:

• 64-bit executable files (EXE, DLL, OCX) in a component not flagged as 64-bit end up in "C:\Program Files (x86)" (they still execute as 64-bit since this is determined by their internal bitness values).
• Registry keys for 64-bit EXEs in a component not flagged as 64-bit end up in HKLM\Software\Wow6432Node.

In summary,

• the bitness of the Windows Installer service itself (service side is always 64-bit on Windows 64-bit and client can be started as either 32-bit or 64-bit) does not affect the presumed bitness of the package contents.
• the bitness indicator of the MSI package also does NOT affect the presumed bitness of the package contents.
• the individual package elements (custom action, component, AppSearch table entries, etc) are always assumed to be 32-bit UNLESS marked otherwise - on an individual element basis.
• this approach allows a 64-bit MSI package to install both 32-bit and 64-bit elements (important because so many "64-bit editions" are partially or completely composed of 32-bit binaries).
• this approach provides excellent compatibility with all legacy packages.
• this approach prevents mistaken marking of a package for 64-bit MSI processing (simply because it is targeting the 64-bit OS) from creating problems for application software in the package that is truly 32-bit.