MSI 1633: This Installation Package Is Not Supported on This Platform

Fix it now

1633 is ERROR_INSTALL_PLATFORM_UNSUPPORTED: this installation package is not supported on this platform. 1623 is the same refusal about language rather than platform. Neither is corruption, and neither is fixed by downloading the same file again – you need the variant of the package that matches the machine, and the machine will tell you which one that is in about ten seconds.

(Get-CimInstance Win32_OperatingSystem).OSArchitecture
$env:PROCESSOR_ARCHITECTURE
Get-FileHash C:\pkg\app.msi -Algorithm SHA256

1. Match the download to what those commands report: x86 for 32-bit, x64 for 64-bit Intel and AMD, ARM64 for Arm devices.
2. Remember which way compatibility runs. A 32-bit package installs on 64-bit Windows; a 64-bit package will not install on 32-bit Windows at all.
3. If the error is 1623 rather than 1633, get the localised package for your system language, or ask the vendor for the language transform that adds it.
4. Install from an elevated Command Prompt with logging so the refusal is recorded: msiexec /i "C:\pkg\app.msi" /l*v "C:\pkg\install.log".
5. If you get 0x8007000B or 0x800700C1 instead, the file is not the executable type it claims to be – check the hash and obtain it again.

For runtimes and drivers, match the architecture of the application rather than of Windows. A 32-bit application needs the 32-bit runtime even on 64-bit Windows, and installing the 64-bit one instead will not make it start.

If the correct variant installs and the application runs, you are done. If the package still refuses, the next section covers what it is actually declaring.

Why it happens

Every MSI carries a summary information stream, and one of its properties records the platform and the language the package was built for. Windows Installer reads that before doing anything else and refuses immediately when the platform does not match. That is why 1633 arrives instantly, with no progress bar and nothing in the log about files, and why the same package installs perfectly on a colleague’s machine.

Compatibility runs one way only. Sixty-four-bit Windows carries the subsystem that runs 32-bit code, so an x86 package installs there and the application runs. Thirty-two-bit Windows has no equivalent for 64-bit code, so an x64 package is rejected outright. On Arm devices the picture is different again: Microsoft’s position is that Windows on Arm runs native Arm apps as well as many unmodified x86 and x64 applications through emulation, with support for unmodified x64 applications being a Windows 11 capability. Native Arm64 remains the better choice where the vendor publishes one.

Language works the same way through a different property. A package built for a single language declares it, and if the system language is not in that list and no transform supplies it, the install stops with 1623 – Microsoft’s text is that this language of the installation package is not supported by your system. Vendors handle this either by shipping one package per language or by shipping a multilingual package with language transforms, which is why the fix is sometimes a different download and sometimes an extra argument on the command line.

Full reference

The six codes, as Microsoft states them

1654 is the one people misread, because the first sentence sounds like a Windows version problem and the second sentence is the actual rule. It is about signing on Arm hardware, not about which build of Windows you are on. Microsoft’s Windows Installer event list carries the matching event, recording that a file is not Microsoft signed and is being rejected under the Windows Lockdown Policy – which is the same statement written into the Application log.

Working out what the machine is

Bad format is not the same as wrong platform

0x8007000B and 0x800700C1 look like architecture errors and are not. ERROR_BAD_FORMAT is an attempt to load a program with an incorrect format, and ERROR_BAD_EXE_FORMAT says the file is not a valid Win32 application. Both are what you get from a truncated download, a file renamed from one type to another, or an executable extracted incorrectly from an archive. Check the hash and the signature before you go looking for a different architecture, because a different architecture of the same broken file will fail the same way.

Deploying across a mixed estate

• Detect the architecture at run time and select the package. Hard-coding one is the single most common cause of this error in managed environments.
• Where a shared runtime is needed by applications of both architectures, install both. They are separate products and coexist.
• Keep the Arm64 build in the catalogue where the vendor publishes one; falling back to an emulated build should be a decision, not an accident.
• Where a vendor ships one package per language, treat language as a deployment variable in the same way as architecture, and test at least one machine per language.
• Test the deployment on one machine of each architecture and each language you actually run before rolling it out.

When you genuinely cannot get a matching build

1. Ask the vendor directly whether a build for your architecture exists but is not published on the general download page. Many keep them.
2. Where the application is 32-bit only and the machine is 64-bit, that is not a problem – install it and move on.
3. Where the application is 64-bit only and the machine is 32-bit, the machine is the constraint. Plan a rebuild rather than looking for a workaround; there is no supported way to run 64-bit code on a 32-bit installation.
4. On Arm hardware with no Arm64 build, try the vendor’s 32-bit build, then confirm the application actually runs rather than merely installing.
5. If the refusal is 1654, stop looking for a different architecture. The package needs to be signed appropriately for that device, and that is the vendor’s job.

Every code this article covers

Confirm the fix worked

1. The install completes and the product appears in Settings, Apps, Installed apps.
2. The application launches, not merely that setup finished.
3. For runtimes, both architectures are present where the estate runs both 32-bit and 64-bit applications.
4. The file hash matches the vendor’s published value, so you know you are testing the right file.
5. The deployment succeeds on one machine of each architecture and language you run, before it goes any wider.

Questions people ask about this