Can CoCreateGuid ever return GUID_NULL?


A customer asked whether the Co­Create­Guid function can ever return GUID_NULL. Their code uses GUID_NULL for special purposes, and it would be bad if that was ever returned as the GUID for an object. "Can we assume that Co­Create­Guid never returns GUID_NULL? Or should we test the return value against GUID_NULL, and if it is equal, then call Co­Create­Guid and try again?"

Some people started running Co­Create­Guid a bunch of times and observing that it was spitting out type 4 GUIDs, which will always have a 4 in the version field. Then other people started wondering whether the use of Algorithm 4 was contractual (it isn't). Then still other people went back to read the RFCs which cover UUIDs to see whether those documents provided any guidance.

And then I had to step in and stop the madness.

It is very easy to show that any UUID generator which generates GUID_NULL has failed to meet the requirement that the generated UUID be unique in space and time: If it's equal to GUID_NULL, then it isn't unique!

The uniqueness requirement is that the generated GUID be different from any other valid GUID. And if it generated GUID_NULL, then it wouldn't be different from GUID_NULL! (And GUID_NULL is a valid GUID, specifically identified in RFC4122 section 4.1.7.)

If you're so worried about Co­Create­Guid generating a duplicate GUID_NULL, why aren't you worried about Co­Create­Guid generating a duplicate IID_IUnknown or GUID_DEV­CLASS_1394 or any of the other GUIDs that have already been generated in the past?

In other words, no valid implementation of Co­Create­Guid can generate GUID_NULL because the specification for the function says that it is not allowed to generate any GUID that has been seen before.

One of my colleagues cheekily remarked, "And even if it did generate GUID_NULL for some reason, uniqueness would require that it do so only once! (So you should try to force this bug to occur in test, and then you can be confident that it will never occur in production.)"

Comments (26)
  1. Paul says:

    Amusement and cheekiness seems like a reasonable reaction, but I do appreciate that the customer is questionning their assumptions. Too often, there is the opposite problem. The customer makes assumptions that land them in trouble without even realising it.

  2. alegr1 says:

    Bruce Schneier can generate GUID_NULL.

  3. Eddie says:

    "And then I had to step in and stop the madness."

    Best single line paragraph ever!

  4. DWalker says:

    Of course, CoCreateGuid can never return 878eaf34-d1c1-4cdd-851b-70a24d678f74 either.  Since I just caused it to be generated.   But I can see their confusion….

  5. > why aren't you worried about Co­Create­Guid generating a duplicate IID_IUnknown or GUID_DEV­CLASS_1394

    Because their application doesn't use IID_IUnknown or GUID_DEV­CLASS_1394 as a sentinel.

  6. John says:

    He's going to have the last laugh when everyone has to deal with the Y34K problem.

  7. Partner says:

    GUID identifiers are non-renewable global resource!  Don't waste it!

  8. Gabe says:

    Well, presumably the client was thinking that maybe GUID_NULL would be returned as an indication of a transient error condition (perhaps insufficient entropy available to generate a UUID yet). You'd hope that would give you a non-success HRESULT, but I suppose it's a fair question to ask.

  9. bzakharin says:

    But has GUD_NULL ever been generated by a valid GUID generator? Just because it was written out by someone doesn't mean it was ever actually generated.

  10. AC says:

    I don't see how this is a valid argument.

    As the same can be said about any other GUID, that argument leads us to conclude that a valid implementation can't return any GUID at all. (Meaning it either has to abort/crash/throw an exception, or from a different angle, there is no valid implementation)

  11. Brian G. says:

    @AC: It's a statistical argument framed as an absolute argument because the statistics are so skewed. If you were to remove that skew by enumerating every GUID possible and saying, "HAHA! Now I have them all, you're all screwed!" it would indeed break the argument.

  12. Lars says:

    @Boris Zakharin: I'm sure someone wrote a program that printed it to the screen and destroyed itself afterwards ;)

  13. jalopy says:

    I generated GUID_NULL from the MAC address of a non existent network card which I then destroyed

  14. > But has GUD_NULL ever been generated by a valid GUID generator?

    Nope; there are various generation schemes that are defined, but whichever one you choose, there are four bits you have to set to identify the scheme you used.

    None of these schemes use a value of 0000 for those four bits.

    So GUID_NULL, while a perfectly valid GUID, can never be generated.

  15. Jim says:

    In fairness, they could have been asking whether CoCreateGuid might fail somehow (e.g. if it uses a MAC address, but finds the computer has no network card), and might return GUID_NULL in that case, rather than just returning it by chance. But obviously the documentation would be the right place to look for that answer.

  16. Off topic says:

    Could FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFF be called GUID_FULL? (I wish it could be INVALID_GUID_VALUE to align an imaginary GUID CreateGuid() function error return with CreateFile's INVALID_HANDLE_VALUE return, but that's sort of like comparing apples to handles, since there are no invalid GUID values, or invalid integers for that matter.)

  17. @ Brian G says:

    Raymond has covered that already.

    blogs.msdn.com/…/10461148.aspx

  18. Gun says:

    Hmmm… Where in the galaxy is located that database that remembers all the "already seen" generated guids then?

  19. Engywuck says:

    @BrianG: especially since if generating a GUID takes 1 millijoule it would take the whole energy output of the sun (as is now) over 8 billion years just to generate them all (if I calculated correctly). So if anyone wants to evaporate all oceans of the earth multiple times over just to have that "ha, I've seen that GUID before" moment….

  20. Kramii says:

    According to Eric Lippert there are "about 40 billion billion billion unique GUIDs for every person on earth". Who do I write to to get Microsoft to send me mine? And how can I be sure that nobody else is wasting them on wasteaguid.info?

  21. DWalker says:

    An interesting observation is that, from the point of view of a computer with no network card, it's hard for it to "see" any other computers — the computer is pretty much isolated.  So any generated GUIDs typically stay within that computer, and therefore, they won't "collide".

    Of course, that computer could generate a GUID, and you could write it down and carry it to a networked computer; or copy some GUIDs from the isolated computer to elsewhere on a flash drive, or whatever.  In practice, network card addresses aren't used much in GUID generation any more anyway (as has already been mentioned); a computer without a network card can use a random-number generator to come up with those 47 bits (or whatever) that came from the network card in the original spec.

    Speaking of how many GUIDs you can assign to each star and planet, I thought there were more than enough GUIDs to assign one to every atom in the known universe.  This doesn't cover the "temporal" aspect though.

  22. Marc K says:

    Thanks to your colleague, the customer is _still_ running their generator 24×7 waiting for GUID_NULL to be generated.

  23. GregM says:

    "An interesting observation is that, from the point of view of a computer with no network card, it's hard for it to "see" any other computers — the computer is pretty much isolated.  So any generated GUIDs typically stay within that computer, and therefore, they won't "collide".

    Of course, that computer could generate a GUID, and you could write it down and carry it to a networked computer; or copy some GUIDs from the isolated computer to elsewhere on a flash drive, or whatever."

    Or you can just turn the network card back on.  ;)

  24. Paul Parks says:

    @Partner: You might find this entertaining, if you're in a wasteful mood.

    http://wasteaguid.info/

  25. Nick says:

    I just ran Apache Bench on that website. Sorry, I wasted about 1000 GUIDs. I think we're still good.

  26. smf says:

    "In other words, no valid implementation of Co­Create­Guid can generate GUID_NULL because the specification for the function says that it is not allowed to generate any GUID that has been seen before."

    If CoCreateGuid is called and no one is around to see it, has a Guid been generated?

    Most of the distrust of Guid's comes from the majority of people not understanding collision probability (*). Their definition of never is a little loose which allows them to write the code quicker. The old grumpy guy in the corner saying that it won't work and it needs more time spent on it is not listened to by management, because they already have an implementation that works and the person who wrote it says it will never generate a duplicate.

    I assume Microsoft's guarantee comes with some caveats like reformatting/changing the time etc resets the contract. The comment about making sure it happens in test so it doesn't happen in production is either sarcasm, or a tragic misunderstanding of collision probability.

    (*) The majority of developers also failed to predict the year 2000.

Comments are closed.

Skip to main content