OnlineUnlockStatus::getLocalMachineIDs() changed after Windows Update


#1

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


#2

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


#3

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?


#4

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


#5

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?


#6

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.


#7

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…


#8

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!


#9

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.