As quoted from the Memtest website:
Please be aware that not all errors reported by MemTest86 are due to bad memory. The test implicitly tests the CPU, L1 and L2 caches as well as the motherboard. It is impossible for the test to determine what causes the failure to occur. However, most failures will be due to a problem with memory module. When it is not, the only option is to replace parts until the failure is corrected.
Once a memory error has been detected, determining the failing SIMM/DIMM module is not a clear cut procedure. With the large number of motherboard vendors and possible combinations of memory slots it would be difficult if not impossible to assemble complete information about how a particular error would map to a failing memory module. However, there are steps that may be taken to determine the failing module. Here are four techniques that you may wish to use:
- Removing modules This is simplest method for isolating a failing modules, but may only be employed when one or more modules can be removed from the system. By selectively removing modules from the system and then running the test you will be able to find the bad modules. Be sure to note exactly which modules are in the system when the test passes and when the test fails.
- Rotating modules When none of the modules can be removed then you may wish to rotate modules to find the failing one. This technique can only be used if there are three or more modules in the system. Change the location of two modules at a time. For example put the module from slot 1 into slot 2 and put the module from slot 2 in slot 1. Run the test and if either the failing bit or address changes then you know that the failing module is one of the ones just moved. By using several combinations of module movement you should be able to determine which module is failing.
- Replacing modules If you are unable to use either of the previous techniques then you are left to selective replacement of modules to find the failure.
- Avoiding allocation The printing mode for BadRAM patterns is intended to construct boot time parameters for a Linux kernel that is compiled with BadRAM support. This work-around makes it possible for Linux to reliably run with defective RAM. For more information on BadRAM support for Linux, sail to ISP trouble --- redirect
Sometimes memory errors show up due to component incompatibility. A memory module may work fine in one system and not in another. This is not uncommon and is a source of confusion. In these situations the components are not necessarily bad but have marginal conditions that when combined with other components will cause errors.
Often the memory works in a different system or the vendor insists that it is good. In these cases the memory is not necessarily bad but is not able to operate reliably at full speed. Sometimes more conservative memory timings on the motherboard will correct these errors. In other cases the only option is to replace the memory with better quality, higher speed memory. Don't buy cheap memory and expect it to work reliably. On occasion "block move" test errors will occur even with name brand memory and a quality motherboard. These errors are legitimate and should be corrected.
Referring to your original post, I believe this is one of those uncommon cases where the error actually may be caused moreso by a motherboard, CPU or power supply issue than the memory, though read the entire quote to understand all that's implied when an error is struck in Memtest. If it's a memory module suffering a problem, that same bad bit should be showing up on recurring tests, but it isn't. Instead it seems erratic or almost seemingly happenstance. That leaves me to venture about it being less on the RAM and more on something else.
Here's hoping that BIOS update takes care of things, but also you should test using
Prime95 just in case. First, do a preliminary by running it on Torture Test on Blend for 30 minutes and have
HwInfo on
Sensors only to watch temps. If the CPU temp gets high (above 60 and increasing) then stop Prime95 and consider cleaning your system and/or reinstalling the CPU cooler. Otherwise, if it stabilizes at a good temp, you can start running it overnight. After that is done, regardless of what the results are, do another several hour test on Large FFT settings instead of Blend. Report to us results and provide us crashdumps if present.
The fact, is, whether the MULTIPLE_IRP_COMPLETE_REQUESTS was from drivers or not is immaterial, what is true is that Memtest detected an error with a very high confidence value, so without doubt there's some hardware problem slinking around, but what hardware it is we've yet to discover. I can tell you the hard drive nor GPU would be involved with the Memtest error so you can rule those out. Typically it's the Trio of Trouble, which is CPU/Mobo/PSU. The problem with these is that there's no real definitive software test for them, the only tried and true method is swapping them with reliable parts and crossing fingers. Prime95 may give a better suggestion than what we have now, but I'm not sure it'll be definitive.
