This * is printed by hexdump and means "any (nonzero) number of repetitions of previous line".
Your keyboard controller seems to be running in translated mode, so the keyboard sends 15 (which gets translated to 10) for Q (with nothing at release) and 14 (translated to 1D) for CapsLock (with F014, translated to 9D, at release).
AT scancode and translation tables.
This indicates scancode set 3 and is the usual behavior for terminal Ms.
The keyboard doesn't seem to send either E0 or 3F (and, in fact, it shouldn't), so this E03F prefix is probably produced by some weird interactions between the keyboard and Windows driver (which AFAIK doesn't support set 3). I have no clue where E0 comes from, but 3F is translated 03 and 03 *might* be keyboard's response to scancode set query sent by Windows driver, misinterpreted by Windows as part of some scancode.
However, I don't really know if this is true and how to fix it. You might try
this (XP/2k only) driver for terminal Fs, they are similar to Ms so it might work.
BTW, does this keyboard work in Linux? If Linux correctly interprets letters, (but not other keys), then with "i8042.direct=1 atkbd.set=3 atkbd.terminal=1" kernel parameters everything (except for the left block and high row of Fs) should work perfectly. This, if true, would be a definitive proof that we are dealing with Windows bug
