How Windows Installer Processes Packages on 64-bit Windows |
![]() |
![]() |
General |
Written by Darwin Sanoy |
Tuesday, March 22, 2011 1:00am |
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:
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:
In summary,
|