Success fail

A successful installation should return an exit code of 0, but that is not always the case. These cases need to be handled properly, or I'll get a very red pie-chart in System Center.

The most common exception is 3010, a successfull install that needs a reboot, but there are others. Some more or less retarded.

Just now I needed to deploy an msi that returned 1638 if it was already installed. 1638 is documented as ERROR_PRODUCT_VERSION, "Another version of this product is already installed". This is stupid on many levels. First, if the same version is installed an msi should just install again. If an older version is installed, a proper msi should perform a major upgrade. The exit code might be useful if a newer program exists on the computer, but barely. I would say that installations which return 1638 should be documented as ERROR_MSI_SUCKS. The solution is to always uninstall before installing. This leads to the next problem.

Uninstalling an msi might return 1605, ERROR_UNKNOWN_PRODUCT, "This action is only valid for products that are currently installed." Yes, thank you. Already not there then. Success.

Sometimes you might need to deploy a patch for Windows, usually named kb-something with an msu extension, with your application. Unfortunately a shitload of your computers in your enterprise will report failure 2359302, 0x240006 in hex. This means WU_S_ALREADY_INSTALLED, "The update to be installed is already installed on the system". This is even dumber than 1638. If it is already installed, it is a success!

Related is the msu exit value of 2149842967, 0x80240017 in hex, "The update is not applicable to your computer". You'll get this result if you try to deploy a patch for Windows 7, and you happen to have a few Windows 10 among them, as an example. Not unlikely for many reasons, one of which is the update is included in a larger install where the application needs it on older Windows, but you don't feel like making two different packages for each OS or some other workaround. While the error might be interesting for some reasons, as a deployer I don't care. I filter it to success and I'm just as happy.

Deploying drivers with DPInst is an entire chapter of itself. The return value you get consist of three hexadecimal parts merged with OR like this:

0xYY0000 contains the number of drivers that failed to install.
0x00YY00 contains the number of drivers copied to the driver store.
0x0000YY contains the number of drivers successfully installed.

A return code of 66051 thus means 1 driver failed, two drivers copied to the driver store and 3 drivers installed, because it's 0x010203 in hex.

The simplest way to get a useful value is to do an AND FF0000. If it's zero, it's a success, otherwise you'll get the number of fails times 65536.

But so far the exit codes have at least been valid and have their reasons. Some badly written installers give all kinds of weird return values. Adobe was notorious for a while, returning 255 for a success.

But of all the moronic exit codes to indicate success there is one particularly stupid from msiexec;

1707 - Installation operation completed successfully.