Two tales today, both arising from MemTest86 burn-in sessions...
Case 1: When is an error not an error?
What's wrong with this picture?
How about this one?
Hmm, first we have an error where test = expected value with no error bits at all. Then we have an error count of 1 with no errors listed. Does that have an amusing aroma or what? No surprise when this happens next:
This is a laptop, and suspect the problem lies at the motherboard level. Shroud time, perhaps; especially as in both of the first two cases, the PC locked up hard and wouldn't power on until left off for several minutes. There doesn't seem to be any fan or ventilation issues; the fan sounds normal, for what that's worth.
Case 2: Say what?
Another "what's wrong with this picture?" test:
No errors, but what's with the spurious "(" characters?
MemTest86 runs in text mode, where bytes sent to the display adapter are interpreted as ASCII, sometimes with color codes sent in between. As the picture before this one indicates, MemTest seems to write characters only, given that the registry dump doesn't change the screen colors set up when the program started.
The ASCII codes for "(", "0" and space are 40, 48 and 32, respectively, so what you see here may be "bit puns" affecting what should have been spaces or digits written to update the progress line.
After cleaning and reseating the SVGA card, the system black-screened before POST with beeeeeeep beep beep indicating absent display. Stripping and rebuilding the PC revealed this: "Before"...
...and "after":
Even though Intel CPU fans that don't fail, and Socket 370 has widely-spaced heat sink fins, dust build-up can still block airflow. The system's currently being re-tested after re-assembly; on test 9 of 11 and so good, so far.
(C) Chris Quirke, all rights reserved, April 2005