09 June 2012



Somewhere on the system board of virtually every Wintel computer in existence there is a programatically accessible identifier (a 128-bit number). In theory, this identifier is unique to each system board and may be used to differentiate this particular computer from every other computer. In practice, you cannot rely on this being the case and therefore this identifier is useless.


In the SMBIOS System Information table (Type 1) there is a field called UUID which is described as "Universal Unique ID number. If the value is all FFh, the ID is not currently present in the system, but is settable. If the value is all 00h, the ID is not present in the system."

So let's assume your program reads this value (either directly or via WMI Win32_ComputerSystemProduct, for example) and the value is not all FFh or all 00h; what two properties would you expect of this universally unique identifier? I suggest you'd want it to be (a) a unique value, and (b) an unchanging value.

Oh dear.

I've probably seen more SMBIOS UUIDs than you've had hot dinners, and I can tell you that the UUID is not always unique and not always constant.

Sometimes the UUID has some kind of "obviously" non-unique place-holder, such as a repeated pattern. For example, it might be 58585858585858585858585858585858 (58 hex = ASCII 'X') or it might be 00020003000400050006000700080009. (And don't forget that, although it looks like a pretty obvious pattern, when read in little-endian byte order, as the SMBIOS UUID field should be (another sorry tale of woe), the UUID you will get is {03000200-0400-0500-0006-000700080009}.) You might write some code that could detect some of the more obvious patterns and discard the UUID as probably non-unique when you find them. By the way, both of these examples are from real computers.

Sometimes there is no discernable pattern in the UUID - it looks random. That is good. Except when you find that somehow every computer at that customer site has exactly the same "random" UUID.

Again, sometimes the UUID looks truly random, and no two computers appear to have the same UUID. And then you restart the computer and now you have a new UUID, completely different to the one the computer had last time you looked! This is pretty rare, but I've seen it happen. A more common problem is that, for some reason, someone in the organisation changed the UUID, maybe deliberately, maybe unintentionally.

I think that for the majority of computers the UUID is a unique constant. But because some computers have bad UUIDs, and because you cannot always tell the good from the bad just by looking at the UUID, the only safe thing to do is assume that all computers have bad UUIDs. And that's a shame. I guess a few people spoiled it for everyone.

Perhaps I misunderstood the SMBIOS documentation. To be fair, it doesn't actually say "if present, this value will be unique to this system board and will never change." It's rather terse on the subject. But it does say, "Universal Unique ID number." So, you know, I assumed the ID would be unique. Perhaps they meant to say, "Potentially Universal Unique ID number. Look, we are just providing somewhere to put a 128-bit number, and if someone sets it to a unique value, and they don't change it, then it will be unique and constant."

It occurs to me that someone might attempt to defend the SMBIOS UUID by saying that it is the responsibility of computer manufacturers to ensure that this field is correctly set, and if the value isn't unique the issue should be taken up with them. I don't mean to be rude, but get real! Imagine you are a little independent software company and you are fortunate to sell your product to a multinational company. They roll it out across the 14 countries in which they operate, onto their 50,000 computers of 57 different brands. There are problems with your product because you were foolish enough to rely on the SMBIOS UUID being a unique constant. But don't worry, just tell MegaCorp to take it up with their computer suppliers. "Right oh, will do" will not be the cheery response from MegaCorp. (This is a purely hypothetical example.)

My advice is, by all means obtain the SMBIOS UUID and show it to the user, but don't write code that relies on the value being unique and constant, because it may not be either.

index of blog posts


  1. Thank you so much for your post. You saved me a lot of time testing!

  2. Hi Anthony

    You are spot on with your advice. We made a similar mistake by using the Machine SID to uniquely identify computers running our software within a network. The problem being that a lot of companies don't follow strict ghosting guidelines which meant that there were a lot of Duplicate SIDs. Even convincing a medium sized company to run NewSID on these offending computers and to make sure they did their job properly by running SysPrep didn't go down well sometimes.

    What would you suggest then is the best value to use for uniquely identifying a computer?



    1. Hi Chris,

      That's a good question. The short answer is I don't know.

      - We used the NIC MAC address, if it wasn't a laptop (so we didn't accidentally use the docking station MAC address).
      - We used the first disk serial number we could find - but then had problems with the code that got the disk serial number sometimes getting garbage from RAID disks.
      - We generated a random number, seeded by NIC MAC address and high-frequency counter, and wrote that to disk to be used on subsequent restarts. But then had the sort of ghosting problems you mention - either every machine had the same random number from the ghost image or every machine got a new random number every time the machine was imaged, so we lost continuity. Some environments, such as some schools, re-image every day, so it was a big problem.

      As I say, I don't know the answer. Perhaps some kind of probabilistic combination of system parameters? If you have any good ideas I'd love to hear about them.


    2. I used to use MAC address of NIC with lowest metric, but now I'm using a hashed combination of motherboard serial number (you can use UUID as well) and %windir% folder creation date. That gives high uniqueness of my ID, but I have to manually handle it after OS reinstallation.

    3. @Mike - But the motherboard serial number could be empty or exactly the same as other motherboards or even change, the MAC address may change if you dock your laptop in a different docking station and the disk contents and/or the disk itself may be replaced. If you combine these values you may end up with a unique id for a given machine (a), but it will not necessarily be constant (b).

      It reminds me of one of my father-in-law's favourite 'jokes': "I've had this spade for 50 years - it's had three new handles and two new blades - a damn good spade."