-1

Here's a little background:
Desktop computer came to my desk with 32GB (4x8) DDR3 1600MHz non-ECC, a GTX960 graphics card, and an OS (Windows 7 Pro) that wouldn't boot. After an overnight memory test, and several video memory tests, everything looked great! I repaired the OS offline and booted it up. Black screen and crash. I figured the videocard, which had just had a driver upgrade was faulty, so I popped it out and booted again. Everything looked great, and it ran like a dream. In order to fix the remaining problems, I upgrade to windows 10 per client request. Boots up great after the install. And then... Total annihilation. It rebooted and went straight to chkdsk where it recovered about 40GB of files. WinSxS was gone, the OS was beyond repair, and I was shocked. We tested the RAM for over 18 hours, running 5 passes with memtest, and a pass using another memory testing platform.

Here's the question:
How did all this testing take place without any indication of a problem, before this massive amount of data was nearly destroyed by bad memory? After replacing the memory the system runs fine. What happened, and what kinds of tests will actually catch a problem like this?

14
  • 1
    Why do you think that bad memory caused the data loss? All of the evidence you mention points elsewhere. Dec 7, 2015 at 22:19
  • 1
    If this had been a RAM problem, I would personally expect it to have manifested itself very, very differently. Even writing the file system structures to cover 40 GB of data on a common system takes a non-trivial amount of time, especially in modern CPU terms. The PC would have had ample time to outright crash during that time, and almost certainly would have.
    – user
    Dec 7, 2015 at 22:22
  • 1
    "We figured memory after reviewing the crashdump we finally got from the last crash." I would recommend that you edit your question to include the specific information from the parsed dump that led you to draw this conclusion. As it stands, your question makes an unsubstantiated claim and then asks how that could happen. Note that comments should be regarded as ephemeral "post-it notes", and are subject to deletion at any time; however, question and answer posts remain, along with their revision history.
    – user
    Dec 7, 2015 at 22:25
  • 1
    "Replacing the memory entirely also resolved the problem" Sure, but you also had to do a clean install of the OS, right? And that was something you hadn't done before. All of the evidence you've presented to us (I can't speak to evidence you haven't shared) suggests memory was not the problem. Dec 7, 2015 at 22:26
  • 1
    Perhaps if you included pertinent information like getting specific errors like "MEMORY_POOL_CORRUPTION" and "CRITICAL_PROCESS_DIED" in your question, less guessing would ensue. ;) So please, edit and update your question to add all this valuable information that currently only exists in your comments - plus anything further you think could help... Dec 7, 2015 at 22:36

1 Answer 1

0

How did all this testing take place without any indication of a problem,

Easy, automated testing for a couple days cannot catch every defect that may arise.

what kinds of tests will actually catch a problem like this?

There are none that are 100% accurate. You do what you can, and have contingency plans in place. IE: As a builder, offer a warranty and stock extra RAM. As a user, ensure you keep a couple backups of the data you're putting onto a new, basically untested machine.

Related personal experience/anecdote:

"We tested the RAM for over 18 hours" -- When I worked as/for a system builder we used to burn-in the RAM (and system in general) in every system for 72 hours straight (minimum) before putting them out the door. Many times we had RAM die on the 3rd day of burn-in, and plenty of times RAM still failed in the field after that. Such is the nature of the beast.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .