Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I was reading another question about Memtest and started wondering: How does Memtest86 function with bad RAM?

Think about it: Memtest86 needs to store information about how large the RAM is, what it put in RAM to compare later, where to update the screen, and a lot more information. The act of using a variable requires RAM to be functioning properly. But how can you get reliable results when your running the program on possibly defective RAM?

An analogy to this is running a hard drive checking program from the hard drive that your checking. You would never do that, a bad block could affect the program in lots of unexpected ways

How does Memtest86 function with bad RAM?

share|improve this question
1  
FYI, all work done by the CPU is done in RAM. When a program is executed, its done in RAM, it has nothing to do with variables. You could write a program that does absolutely nothing, and never uses any variables, but that program resides in memory. Very interesting question though. –  Keltari Aug 24 '11 at 18:34
1  
Since all (non-trivial) programs use variables, the trick for memory testers/exercisers is to store their variables in registers, rather than memory. That also means no stack! Some memory programs execute out of ROM (e.g. Harvard architecture), or, if resident in the RAM under test, relocate the code after each pass. Success or failure to execute the testing program at various RAM locations was part of the exerciser. Of course there are probably badly-written memory testers that use the RAM under test like an ordinary program –  sawdust Aug 24 '11 at 20:48

6 Answers 6

up vote 7 down vote accepted

Mostly because the amount of ram that it takes to load memtest is extremely small. If the program runs, it's likely that the memory in this one area is ok.

The chance that-

  1. The small section of memory memtest was loaded in is bad.
  2. It was still good enough that the it was able to complete all the tests successfully without noticeable issues.

Is -highly- unlikely.

share|improve this answer

Think about it: Memtest86 needs to store information about how large the RAM is, what it put in RAM to compare later, where to update the screen, and a lot more information. The act of using a variable requires RAM to be functioning properly. But how can you get reliable results when your running the program on possibly defective RAM?

Well, this is what Memtest does - it writes various (known) patterns to your RAM, reads it back, and compares. If there is a mis-match, your RAM has to be be corrupted.

An analogy to this is running a hard drive checking program from the hard drive that your checking. You would never do that, a bad block could affect the program in lots of unexpected ways

While this is true, there are some cases where you have no choice. So long as you can load the program successfully, it should be able to perform it's diagnostic tasks (even if it's running on a faulty media of some kind).

How does Memtest86 function with bad RAM?

Well, it has to load itself into memory first. In most cases, this memory will still be good. In the event that it is not, Memtest will most likely determine that the program itself is corrupted by comparing some in-place variables with a checksum. In the event that they don't match, you would instantly know that either your RAM is bad, or the copy you downloaded is corrupted (and it would be a trivial task to determine if the latter is the cause or not).


TL,DR: Memtest86+ only works assuming the first megabyte of your RAM is still fine (the location where it would be loaded most likely). Assuming this area is corrupted, Memtest86+ itself would simply not function (which is a pretty quick indicator your RAM is bad without even having run the tests).

share|improve this answer

By being small. If some RAM is bad, the smaller the program is, the less likely it is that some part of the program will be in one of the bad spots. Considering that booting far enough to load the memory test will involve some firmware code using RAM, odds are that if you can get that far, the low areas of RAM are working well enough that memtest will be able to run from them.

share|improve this answer

If the RAM the application is saving the variables to is bad, then most of the tests will fail.

The algorithm writes all kind of different patterns and then checks if they are well written by reading them again, if a write or a read didn't go correctly it will make the test in question fail. By running most tests and letting it run for several hours you can then get to see how stable your RAM is...

share|improve this answer

Memtest is quite durable in that it doesn't really depend on the RAM it's testing.

For example, test 0 uses a walking ones algorithm, and all it requires for that test is a single pointer (probably cached), because it's only comparing two consecutive memory addresses.

So if we have a 3-bit RAM stick, memtest loads it with this:

<pointer location> 00000001 00000010 00000100 00001000 00010000 00100000 01000000

And if the first address is corrupted, it'll compare two random locations:

00000001 00100000

And it'll still fail, even if memtest's variables are corrupted.

share|improve this answer

Memtest absolutely has to make at least one assumption, that at least the memory it itself is loaded into is good. After that it is able to scan and test the rest of memory in its entirety.

It may be that it is still able to read and detect errors in its own memory as, being the only program loaded, it should have access to practically all of the memory on the system and so be able to read and compare that memory to a "known good" sample.

share|improve this answer
    
I was mainly thinking about the changes in behavior bad RAM could do. Eg if the bad ram changed the logic so that all tests always showed up true. –  TheLQ Aug 24 '11 at 18:46
    
I would say that it is possible that a single bit flip could make a false read as true while testing, but it is more likely that the bit that flips will be in something much more critical, in Memtest I would expect the size of actual running code to be larger than the "test cases" and so I would expect a bit error would cause the program to crash horribly before it detected a pass in place of a fail. I do admit it is a possibility though. –  Mokubai Aug 24 '11 at 19:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.