Upon first examination, I thought this was a result of the fragility of the Windows Registry with respect to race conditions, as I'll discuss in a follow-up post.
However, closer examination reveals it to be a true defect. The precise circumstances in which this occur are as follows:
- the registry-value whose value is being elicited - as a string (REG_SZ) or as an array of strings (REG_MULTI_SZ) has zero size, and
- it has one or more peer registry-values whose values are of non-zero size
The problem occurs when the value's size is 0. The last block in the method decrements this - to account for the space for the nul-terminator added earlier - and then explicitly sets the nul-terminator. (I actually forget why it does this, but I do recall that it must be done this way.)
Anyway, when the value's size is 0, decrementing it gives a very large number, and so the next statement results in an access-violation. Yuck!
STLSoft 1.9.83 will contain the fix for this, which is simply to test again that the data size is non-0.