Hello guys,

Lately, I've been encountering a strange scenario where the error from the title is encountered during an upgrade scenario, although the second product's version is higher than the previously installed.

I have done quite the investigation regarding this and believe I was able to get to the bottom of it, finding what the culprit is. However, during my investigation, I did not find this documented anywhere, so I decided to make an article showcasing the scenario.

In order to showcase this, let's consider the following example: two version of the same product, as it follows:

- the first version: 15.21055.9

- the second version: 16.21236.1

Just by looking at this, it is pretty obvious that the second version should be able to upgrade the first version, right? Well, not quite. When trying to deploy the second version, you will encounter the error message from the title.


Let's dive a little bit deeper and see why this is actually happening.

First of all, according to the following article:

ProductVersion property

we can see that:

The format of the string is as follows:

major.minor.build

and:

The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.

As we can see above, the minor version has a maximum value of 255. In the example I have given above, the minor version has a value of 21055, respectively 21236, which is > than 255.

This is where a strange behavior of Windows Installer occurs.

As you may already know, each time you install a product, Windows Installer (or most likely, the OS itself) will store some information about the product, including the product version, in the registry. The registry key where this information is stored is the following:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}

if the product is 32-bit and the machine is 64-bit or:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}

if the product is 64-bit and the machine is 64-bit.

In the above key, we can find the version of our product is hexadecimal format.

For instance, if we install the 15.21055.9 version, we will find the following value: 0x5f3f0009

If we take it a step further and actually convert the above to decimal, we will obtain the following:

0x5f = 95

0x3f = 63

0x0009 = 9

Basically, from the above we obtain the following version: 95.63.9

If we install the next version, 16.21236.1, we will find the following value: 0x52f40001

If we do the same as above, we can notice that:

0x52 = 82

0xf4 = 244

0x0001 = 1

resulting in the following version: 82.244.1

Based on this, 82 < 95 and the error message would indeed make sense. However, the question still remains and that is: why is such a version written in the registry?

Unfortunately, I was not quite able to find out the reason for this.

I have tested this many times and if the rules presented above:

- major < 255

- minor < 255

- build < 65535

are respected, I was never able to replicate this behavior.

For example, the following version: 204.203.3000 will be written in the registry as: 0xcccb0bb8.

If we convert the above, we will obtain the following:

0xcc = 204

0xcb = 203

0x0bb4 = 3000

Basically, we obtain the exact version, as it would be expected.

Hope you will find this information helpful!

Best regards,
Catalin

Hello,

As a followup to this, a solution would be to use the "Allow downgrade (a lower version will be able to downgrade a higher version" option from the "Upgrades" page which was added in version 20.2 of Advanced Installer.

Best regards,
Catalin