by Michael S. Kaplan, published on 2010/08/24 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/08/24/10053436.aspx
So does everyone know when 17 equals 10?
When there is as bug! :-)
Now this bug was fixed a long time ago.
It first started happening in XP, and in fact I believe it still happens there.
When I say fixed, I mean they fixed it in the new version.
And by new version I don't mean Windows Server 2003, as the bug still happens there.
They fixed it in all the versions after that.
How to get the bug? Well let's say you tried to add a bunch of keyboards using KB 289125 to handle Regional and Language Options.
And your unattend looks something like this:
[RegionalSettings]
InputLocale=0406:00000406,0414:00000414,0816:00000816,041d:0000041d,0405:00000405,040e:0000040e,0415:00000415,0408:00000408,0419:00000419,041f:0000041f,040c:0000040c,0410:00000410,0407:00000407,0409:00000409,040a:0000040a,0411:e0010411,0804:00000804
Yes, there are 17 keyboards there.
When it runs, only 10 get installed, though.
That seems like a bug, right?
I wonder if anyone hads any ideas what might be happening.
Well, it is kind of a fun, oopsie kind of a bug that happens when the code gets confused somewhere.
Perhaps not much of a hint, but I don't want to make it too easy!
Now although the problem was fixed, the way of doing everything was also totally changed anyway, so the fix probably wasn't needed anyway (the only people who benefited were some internal folks who might have run into the bug back when Vista was Longhorn, etc.
Every once in a while someone hits the bug again, and it suddenly occurred to me that I never talked about it before -- so that maybe I ought to write something about it....
Any guesses?
Peter Ibbotson on 24 Aug 2010 7:29 AM:
Guess is some sort of hex to decimal problem as an 17 keyboard entries occupy elements [0x00] to [0x10] in an array but I'm struggling to see how 10 get installed (rather than 11 i.e. 0x00..0x09 + 0x10)
Jiří Zídek on 24 Aug 2010 8:06 AM:
10h = 16d almost zero based 17d ?
John Cowan on 24 Aug 2010 9:06 AM:
Perhaps when someone allocates a fixed-size data structure and sets its size arbitrarily to 10. "640K should be enough memory for anyone."
Donald Miller on 17 Nov 2010 7:59 PM:
The problem comes when they are shuffling entries in the registry. They want to move existing keyboards down to add newer ones, and they process them like this: move last (highest) entry up one slot, move next entry up one, repeat until first entry moved, write new first entry. The entries all have integer MRU values. When they write an entry they decode the MRU number, add one, and write that new MRU value.
They decode as if the MRU is hex, and write it as decimal. Values under 9 are decoded and incremented correctly, but 10 is interpreted as 16, incremented and written as 17. When the next keyboard is added, they read the 17 as 23, increment and write it as 24. The 17 keyboards will have MRU values of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 24, 37, 56, 87, 136, 311. When they load the taskbar/control panel they read up from 1, and stop when they see the missing value - there is no 11. So only 10 keyboards appear.
Michael S. Kaplan on 17 Nov 2010 9:33 PM:
It is indeed an encode/decode difference interpretting decimal vs. hex -- though slightly less intelligent (it is throwing out the hexadecimal numbers in string form that cannot be interpreted as decimal numbers!) :-(