Weird behavior of UuidCreateSequential

I have a software that runs over 2 000 computers on my company, without any issues.

This software, at some time, generate a GUID (or UUID) using UuidCreateSequential() (MSDN link).

The call usually returns RPC_S_OK on every computer. But on one of them, it always returns RPC_S_UUID_LOCAL_ONLY.

The documentation states that:

The UuidCreateSequential function returns RPC_S_UUID_LOCAL_ONLY when the originating computer does not have an ethernet/token ring (IEEE 802.x) address.

However, there seem to be no networking issues with this computer. It has a network card with both valid and unique MAC address and IP address, and it is working perfectly.

What else could cause UuidCreateSequential() to always return RPC_S_UUID_LOCAL_ONLY ? Have you ever experienced a similar situation ?

I this can 开发者_高级运维help, the computer which has the issues runs an updated Windows XP, with Service Pack 3.

I contacted Microsoft and it seems that bug occurs only on Windows XP, when the first byte of the MAC address is superior or equal to 0x80.

This has been fixed for Windows Vista and Windows Seven. It won't be fixed for Windows XP.

This was a bug in Windows XP and Windows Server 2003.

A MAC address is 48 bits, typically represented as:

00-01-02-0A-0B-0C
00:01:02:0a:0b:0c

The first three bytes represent an Organziation, the remaining three bytes are whatever numbering scheme that organization wants to use. Organization ID's are handed out by the IEEE.

For all public MAC addresses, the 2nd-lowest (2nd least significant bit) of the first byte will be zero. If you wanted to generate your own local MAC addresses, you could set the bit to 1:

02-01-02-0A-0B-0C

   02   -   01   -   02   -   0A   -   0B   -   0C
/¯¯¯¯¯¯\ /¯¯¯¯¯¯\ /¯¯¯¯¯¯\ /¯¯¯¯¯¯\ /¯¯¯¯¯¯\ /¯¯¯¯¯¯\
00000010-00000001-00000010-00001010-00001011-00001100
      ^
      |
      +- 0: Universal 
         1: Locally Administered

Or the image lifted from Wikipedia:

Windows checked the wrong bit

The bug in Windows XP and Windows Server 2003 is that they were were checking the wrong bit. They were mistakenly checking the high bit:

I hate to throw Raymond under the bus, but here's an example of the incorrect information