Ugly Stool Rotating Header Image

wmic vs. dmidecode

I use a machine’s SM BIOS UUID to track it, and I get this information by using either wmic or dmidecode depending the OS currently running.  The problem is that these tools never agree on what the UUID is.  One always has to transform (swizzle) the value of one of the programs to make them agree.

For example, my VM reports the following UUID depending upon the tool that read it.

cmd> wmic PATH Win32_ComputerSystemProduct GET UUID
$ dmidecode --string system-uuid

Notice how the first 16 bytes (three fields) are transformed between the two.  Which one is the incorrect UUID, or rather which output do you always transform before using.  (Note: the definition of incorrect may not be correct.)  I never bothered to figure out why the difference existed.

I was reading the dmidecode source code, and came across the following comment which solved the mystery.

 * As of version 2.6 of the SMBIOS specification, the first 3
 * fields of the UUID are supposed to be encoded on little-endian.
 * The specification says that this is the defacto standard,
 * however I've seen systems following RFC 4122 instead and use
 * network byte order, so I am reluctant to apply the byte-swapping
 * for older versions.

I can now sleep better at night.

Comments are closed.

Page optimized by WP Minify WordPress Plugin