Question about Application Info Detected

Hi there, I’m an app developer and in our Windows app, we update the version info in the executable resources as we make new builds. So for example, our current version is 1.0.0.612. This is what is stored in both “File Version” and “Product Version” in the resource.

Each day we update our build numbers (the 0612 part), and GlassWire notices that it has changed, but it keeps saying the application version changed from “1.0” to “1.0”. I’ve noticed other apps do this just fine using the same type of versioning, so wondering if we’re doing something wrong or if we need to update different values.

Note, this app is handled through Steam and is currently not yet signed (it’s unreleased).

Thanks for your help and love GlassWire. :slight_smile:

1 Like

@the-trooper I have never heard of this before. I guess GlassWire can’t see past the two zeros so that’s why it says that, there probably isn’t enough room in our UI. Try making a fake 1.0.2 update and see what happens.

@the-trooper, this issue arises for other applications too and does not appear to be an issue with the GlassWire User Interface.

It is hard to see where the version numbers are derived

If you look at the version numbers GlassWire uses it is difficult to see where they are being derived:

  • The executable image File Version? Not used for all applications - but appears to be for Waterfox
  • The executable image Product Version? Doesn’t appear to be used at all.
  • The registry Display Version for the installed application? Not used for all applications - but appears to be for
    CCleaner
  • Somewhere else or in some other way? GlassWire probably gets the data from somewhere else as 360 Total Security didn’t match any of the above options. However, GlassWire might use more than one method to determine the version, which could explain the “inconsistency”.

Waterfox is an example where the complete version is displayed by GlassWire e.g. 48.0.1.6070

The executable file properties show that the version GlassWire uses matches the File Version 48.0.1.6070 but not the Product Version 48.0.1:


The Product Version does match the Display Version for the installed application in the Windows registry, i.e. 48.0.1

CCleaner is an example where the complete version is not displayed by GlassWire

The executable file properties show that the version GlassWire uses does not match the File Version or the Product Version, i.e. 5.20.00.5668:


GlassWire does match the Display Version for the installed application in the Windows registry, i.e. 5.20:

360 Total Security is a more complicated example where the the complete version number is displayed by GlassWire but is different than the executable file properties
The difference in the revision numbers doesn’t matter much in practice because Microsoft say that:

Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable

The executable file properties show that the version GlassWire uses does not match the File Version or the Product Version i.e. 8.8 versus 8.8.0.1001:


Interestingly enough, the version that 360TS displays itself is 8.8.0.1020.

This is also the Display Version stored in the Windows registry for the installed application, i.e. 8.8.0.1020:

Process Explorer displays it as different again 8.8.0.1001:

FYI, Windows executable version numbering

Here’s how Microsoft expects version numbers to work:

Version numbers consist of two to four components: major, minor, build, and revision. The major and minor components are required; the build and revision components are optional, but the build component is required if the revision component is defined. All defined components must be integers greater than or equal to 0. The format of the version number is as follows (optional components are shown in square brackets ([ and ]):

major.minor[.build[.revision]]

The components are used by convention as follows:

Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.

Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.

Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

2 Likes