Vista Memory Diagnostics failing at 21%

[cquirke (MVP Windows shell/user)]

On Sun, 15 Apr 2007 13:32:29 +0530, goatmonger

My conclusion (at least for my case): MS screwed the pooch on their
completion bar for the test. They don't use a weighted scale to take
into account that some sections of the test take far longer.

Heh - I've just been thumping on MS's RAM tester, and now I'm coming
to its defence ;-)

RAM testing's tricky, in that it's not enough to simply write known
data into a location, then read it back to see if it's the same. What
if there's an addressing bug that causes writes to addess A to also
flip a bit in addess B? To test for that on the basis of "write a
byte to addess A, test-read every other address" takes A While.

Not only that, but different processor designs, states (e.g. cache on
or off) and motherboard architectures can skew relative timings. This
is a potential source of software bugs, where software may draw timing
assumptions from the behavior of a loop of particular instructions,
and apply this code containing different instructions.

So it's hard to render a progress indicator in a way that is accurate,
in terms of time, especially if you want to minimize processing while
the test is in progress so that it's no slower than it needs to be.

What I'd *love* to see, is a RAM tester that also displays and
periodically updates all system temperatures and voltages...

------------ ----- ---- --- -- - - - -

The most accurate diagnostic instrument
in medicine is the Retrospectoscope

 

[mikeyhsd]

seems like I remember reading the original posts and the person finally admitted that the failure only occurred if he was over clocking. without over clocking the mem diag ran successfully.
might be wrong. but that what I remember reading




(e-mail address removed)

I have been running VMD with no failures. The room I work in has no
air-conditioning (we live at 9000 ft and really don't need it) so the temp
does vary from day to day and with the cold front that went through here
yesterday the room is about 5-10 degrees below two days ago. If the problem
is marginal, which is what it appears to be, this could explain it passing.
On the other hand, it still hangs for disproportionately long times at 21%.

RAM generally operates at full speed, whether it is working properly
or not - unlike a failing HD, the system does not detect errors and
retry operations until success. Even systems that do detect RAM
errors do not retry on error; they either correct on the fly (if
there's enough data redundancy to do so) or they halt the system.

Regarding memtest86, although I have a lot of respect for the program, I
have been in the PC design and engineering business for 25 yrs and I get a
little paranoid about marginal problems.

Me too, but I'd trust MemTest86 further than I'd trust MS's RAM
tester, the design of which is simply brain dead - rather like the
"idiot's parachute" (opens automatically on impact).

OTOH, if one gives errors and the other does not, then I'd believe
whichever one showed errors. When I use either test, I do so for
typically 24 hours; MemTest86 will accumulate results, whereas MS
tester shows only current pass (see what I mean about "brain dead"?)

After seeing some of my data corrupted after a "Easy Transfer" I want
to make sure this memory is solid.

That, too, is a test. Do two successive bulk copies of material that
does not change, and FC (File Compare) their contents. Any mismatch
indicates some sort of problem that should be fixed (i.e. such that
repeat testing is problem-free) before using the system again.

So, two questions: First, does Microsoft offer ANY support for VMD (Vista
Memory Diagnostics), so I can find out more about why it is hesitating at 21%?
Second, does Easy Transfer do any error checking while doing its job? Or,
maybe it does error checking and the problem was that during the read of the
data on the old computer it read the data wrong and created a CRC code based
on the wrong data so that when it put the data on the new computer the CRC
code checked ok? I.e., How could I transfer data using Easy Transfer from one
computer to another and end up with corrupted data, without it knowing it.

BTW: I've seen exactly this sort of error when one of the HDs was not
chassis-grounded, on doing 500M transfers followed by FC checking. FC
would show anything from 1 to 5 mismatches that were always 4 bytes
(32 bits) long, where the contents were completely different (i.e. not
as clean as flipping a single bit).

 

[cquirke (MVP Windows shell/user)]

seems like I remember reading the original posts and the person finally
admitted that the failure only occurred if he was over clocking. without
over clocking the mem diag ran successfully.

Ah, OK. That's a good way to create tshooting opportunities.

I'd be interested to know what hardware subsystems were being
overclocked, as this could be a failure at the chipset level, rather
than "memory" as such. What's odd is that the system's still
responsive; I wouldn't expect that if, say, a page latching operation
didn't ramp up the pulse edge in time for the next clock sample...
usually when that sort of thing knocks the system over, it doesn't get
up again until a button-reset or power cycle.