@[email protected]

Just an observation from someone who happened to memorize some ASCII code: from an ASCII viewpoint, 45 73 63 is hex code for “Esc”, with “s” being 73 and “c” being 63. I can readily see where bits flipped: at the fifth least-significant bit (compare 73 (0111 0011) and 63 (0110 0011).
Similarly, “no0errors” where “0” should be a space. “0” is 30 while space is 20. Again, another specific flipping at the fifth least-significant bit, only difference that this time a 0 became 1 (compare 30 (0011 0000) and 20 (0010 0000)).

The delimiter from the status of “Test #0” seems like a control char-code emerged from a start bracket. If the start bracket has the same char-code as expected from ASCII (5b), and considering how the flipping of the fifth least-significant bit seems to be recurrent, it’d be 4b but this would result in uppercase K, so it’s either a different char-code for bracket or a bit-flipping happening in another position.

But what renders text is the graphics card. Given that the background is slightly shifted rightwards (notice how the blue background cuts through the initial letters from the first column of text, particularly “A” from “Athlon”, “L” from “L# cache” and so on), this seems a graphics glitch rather than a memory glitch. And memtest86+ isn’t designed to test the GPU, so it’s beyond the heuristics. It’s akin to expecting memtest86+ to test for dead pixels on a LCD panel: it simply can’t.

(P.S.: it’s unnecessary and disrespectful to attack others just because others couldn’t see what you wanted them to see; slurs won’t help people see what you see)