Better Machine ID

Does anyone else struggle with the JUCE Machine ID changing for users on a regular basis or not being “unique enough” for windows.

Is there any chance we could have a better cross platform unique machine identifier implementation? There are multiple better proposals floating around online – and it seems unlikely these machine IDs are actually used in practical applications developed in the field by the JUCE team? it appears these IDs get used in the unlocking tutorials – but I’ve had a ton of trouble using them in the field.

I rolled my own machine-id solution:

  • linux: contents of /etc/machineid
  • macos: first MAC address found using the i/o registry
  • windows: value of registry key SOFTWARE\Microsoft\Cryptography\MachineGuid

YMMV, it seems to work for the users that have relied on it. It doesn’t handle cases where you have multiple users/licenses on the same machine, but imho you can solve that on the backend.


Yes, we are facing the same problem.

The machine ID changes on major Windows updates. Which is not good for us.
We would like a machine ID, which never changes.

1 Like

Don’t be shy to click that vote button !

1 Like

yeah, agreed. windows users are upgrading from 10 to 11 and requiring reactivations - whilst not the worst thing in the world, would be nice to not have to deal with such things.


Seems it also happens on major upgrades within Windows 11. We have some users in the Windows “preview” program reporting that. I am crossing fingers, it has to do with the preview versions only.

it has to do with the preview versions only.

Nope, this is happening with minor updates within Windows 10 already. We’re experiencing a flood of new machine ID requests every 8-9 months which can be backtracked to users getting their Windows updated (most of them automatically which makes it much more annoying).

I have a couple quite popular free plugins - windows 11 upgrade is going to kill us :smiling_face_with_tear:

1 Like

I programmed my back end so that users simply login to their account, delete the old activation, then reactivate the plugin. The server handles evrything. So, no support calls or emails at all. Its been working great for several years.

If you have access to how your backend is programmed, this may be an option.


Hmm… I’ve actually got the same thing on mine – doesn’t stop people from emailing. Perhaps I need better instructions there

Exactly. I made sure to explain everything so it is clear what steps to take. Before I did that, some people were emailing. After that, nothing! It really has been quite dramatic. And, it has worked well for a long time now.

Especially for initial activation, the website gives very clear instructions. For example, I state clearly that the user must use and confirm a real email address (via that email) in order to ceate the account. Otherwise, they will not be able to activate their plugin!

In fact, I’ve gone so far as to make most tasks completely under the server’s control. I cannot even do most of the user account management manually. The server must do it. I am a very small operation, so that was necessary for self defense. This may or may not work for everyone.

1 Like

Bumping, in case someone can share a piece of code that helps with that!

I’ve got a new one implemented which is currently in test – i’ll let you know when i’m 100% sure it solves it.


I’m seeing something strange with one Linux user - their machine ID was a duplicate of another user’s. I had assumed this was not possible. I checked to make sure they were not using the same machine.

I have seen this before too on Linux. It happened because several enterprise users had VMs spun up by their sysadmins in a way that duplicated /etc/machine-id. In our case we could adjust our backend not to assume machine ids were unique per user (which is useful anyway, since multiple users could use the same machine).

Unfortunately, we’ve found that MAC address is not really a reliable machine ID on macOS.

I think you need to use kIOPlatformSerialNumberKey or maybe kIOPlatformUUIDKey on macOS.

1 Like

It gets better if you discard the Locally Administered MAC addresses, i.e. those MAC addresses that are “generated” by macOS. They can (and do) change: for example I noticed that some of them assigned to virtual network interfaces have a different value every time macOS reboots.

I’ve been hit by this as well: you want to stick to Universally Administered addresses, they are (hopefully) globally unique and burned in hardware.

A bit of the MAC address is used to discern between the two. See:

  juce::File uuidFile = juce::File::getSpecialLocation(
    .getChildFile(juce::File::createLegalFileName(JucePlugin_Manufacturer)) //dont create a uuid for each product!
  if (!uuidFile.exists())
      const auto uuidStr = juce::Uuid().toString();
      return uuidStr;
  juce::StringArray fileText;
  jassert(fileText.size() == 1);
  return fileText[0];

That is not a machine ID. That is a UUID. It will not identify the same machine with independent runs.

1 Like