OnlineUnlockStatus::getLocalMachineIDs() changed after Windows Update

Hi,

after a WIndows update we recognized that sometimes the result of OnlineUnlockStatus::getLocalMachineIDs() changes. Hence, the plugin/product has to be unlocked again as the previously saved state was for the old machine ID.

Any idea how this could happen? On Windows the machine ID is based on the nFileIndexLow/nFileIndexHigh of the C:\Windows\System32 folder. The documentation from Microsoft states that a file index is valid from creation until deletion (https://msdn.microsoft.com/de-de/library/windows/desktop/aa363788(v=vs.85).aspx)

What can we do to get a unique but stable machine ID?

Sebastian

Yeah, was it the Creators Update? I think this broke a lot of similar authentication systems.

Not sure which update it was. It was installed on the computer between December 8th and December 11th and took quite a long time to finish. Is there a way to find out when and which version of a Creators Update was installed?

Was it only the latest 2017 Creators Update which caused the authentication system trouble or did this appear with every Creators Update?

No, I’ve seen problems with earlier ones. Not sure which version but it was around May

Then it probably was the Spring Creators Update. Quite annoying problem. Imagine a user tries to load a plugin the first time when he is offline a few days after the update…
Can JUCE use another kind of machine ID which hopefully survives these updates?

Well, the unlocking classes let you plug your own custom machine ID generation function into it, and I’m sure lots of people do that. The default one is our best guess of what a good function might be, but I think it’s difficult to choose a perfect system that will never change.

The question is what is a better ID… I think your choice to use the file ID of the Windows/System32 folder is already better than a MAC address (MAC addresses may change easily in virtual machines).

I also wonder how this ID could have changed during the update. The only possibility I can think of is that the System32 folder was deleted and recreated in the update process. Maybe the Windows\ folder itself is a better choice? This probably won’t get deleted or modified…

Anyone who can recommend another good choice to generate a machine ID? I don’t have any logn term experience with this…

We found that the default File::windowsSystemDirectory changed between 32 & 64 bit builds (presumably because it was pointing to System32 in 64-bit builds and SysWOW64 in 32-bit builds.

In our we now point to the user home directory as that’s what’s used on other platforms but have also hit the creators update changing that.

Any stable file ID suggestions would be most welcome!

Could you use registry keys to ensure that you always get a specific directory and can deal with all the logic around whether the app/plugin is 32/64 and whether the OS is 64-bit or not.

Any chance you found a better one since then?

I think we ended up just using the root of the volume the app is running on. That’s seemed to be the most stable in our tests during updates and doesn’t change between versions.

We couldn’t use that for the Mac though as it seemed to be the same for everyone.

1 Like

Hi Dave, I thought we tested this and even C:\ seemed to change under updates?

Yes, I remember now. It did change, but perhaps less often than the other folder IDs.
I think the main reason we moved to C:\ was to avoid the 32/64 bit folder changing, and also that enables us to authorise for the computer as a whole rather than just as user (as the home drive would be different between users).

If anyone has any more stable IDs that would be great!

1 Like

the path returned by File::getSpecialLocation (File::currentExecutableFile) is slightly different when I call that from an aax dll than it is from a vst: it starts with c: and not with C: (upper case).

So I added a toUpperCase(), and the full path is now always C:
but that still does not work : getFileIdentifier() does not return the same number in the vst/aax!

Why is that? any idea of a workaround?

    static StringArray getDeviceIdentifiers()
    {
        StringArray ids;

#if JUCE_WINDOWS
        File f (File::getSpecialLocation (File::currentExecutableFile));

        while (! f.isRoot())
            f = f.getParentDirectory();

        f = f.getFullPathName().toUpperCase();
#else
        File f ("~");
#endif

        if (auto num = f.getFileIdentifier())
        {
            ids.add (String::toHexString ((int64) num));
        }
        else
        {
            Array<MACAddress> addresses;
            MACAddress::findAllAddresses (addresses);
            for (auto& address : addresses)
                ids.add (address.toString());
        }

        jassert (ids.size() > 0); // Failed to create any IDs!
        return ids;
    }

Actually the drive letter capitalization is only wrong (lowercased) with the SpecialLocations invokedExecutableFile and currentExecutableFile (and most probably currentApplicationFile) but it’s always C: (uppercase) with the other locations I tested.

Nevertheless; even using the exact same file, getFileIdentifier() will lead to a different result if called from an aax.
Any idea why?

In the end using the disk serial number seems to be a better/more reliable option than getDeviceIdentifiers()

I thought that the disk serial number wasn’t safe to use in modern OSes as it can be hidden if you’re not running as admin?
I can’t find where I found that now but maybe someone else has come across such things?

What do you get if you look for the volume serial number?
> vol c:?
Is that equivalent to one of the JUCE methods?

I just run into the same problem… the 32 and 64 bit plugins generate different fileIDs on the same machine from the same folder (getFileIdentifier() on C:\Windows\System32) on the current Win10 update… So the folder doesn’t even need to be different, just the fact it’s 32 or 64bit gives different numbers. Did anybody found a good workaround?

Windows folder it’s not secure because it’s probably recreated by updates.
Maybe globalAppFolder can be more secure.
In this case x64 and x32 are separated and must be activate separately but the user who uses a 64-bit OS does not install the 32bit version too, usually.
This is particularly true when we talking about application instead of plugin.