I think I found a weird registry bug.

[HyperHacker]

Dunno if this would go here or in Programming, but it's kind of interesting, and may help some developers who have a similar problem. I've found that if you pass RegSetValueEx() 0 for the cbData parameter when writing a string (REG_SZ) value (I missed the part where it said it should include the size of a null character ), it fails. Now here's the interesting part... the function returns OK as if it wrote the string, and if you check the key in regedit, that value will indeed be an empty string. However, the next time you write a non-empty string in that key, the registry gets corrupted somehow. As a result, regedit still shows that the first value is empty and the second is whatever you set it to, as it should be... however, when RegEnumValue() is called, it will return the second value's contents for both the first and second value! I'm not sure exactly what causes this (it could be a bug in my code, but I tested it pretty thourougly, and editing the empty string in Regedit, even if you leave it empty, fixes the corruption) but it can be avoided simply by specifying a length of 1 instead of 0.

For example, let's say Value A and Value B are both string values in Key X. If I write a zero-length string to Value A, specifying 0 for its length, and a nonzero-length string to Value B, Value A becomes corrupted. Regedit won't show anything odd, but if I run the program again, when it reads the values back by calling RegEnumValue() in a loop, it will be told that Value A and Value B both contain the same string.

A contributing factor to this may be that I had Value B's length one byte too short as well, but this doesn't seem to be the case; none of the other strings or dwords got corrupted, and if I wrote a nonzero-length string to Value A or didn't write to it at all, everything seemed to work fine.

[EdrickV]

There's a very simple explaination for what's going on. A zero length string would not have the required null terminator. Thus, when it later tries to read the zero length string, it keeps reading till it hits a null terminator. Assuming the file/memory/whatever is contiguous, then it will return the contents of the next entry. To quote MSDN's entry on the function you mentioned "cbData must include the size of the terminating null character or characters. " A 1 character sized string would consist of only the null terminator.