RAM errors only after Win7 restart

[tomidis]

Hi all,
I have a dual boot system Win7 and Linux Mint, and sometimes I have a BSOD's only with Win7. I suspected at faulty RAM so I run Memtest86+ v4.20 (from Linux boot menu). The errors appeared very quickly so I decided to test separately each of total 4 modules to find the faulty one. Each RAM module I tested for more than 24 hours and it didn't find any error. I was very confused. After some time I decided to run the Memtest86+ again, but that time I was logged into Win7 and after restarting Windows and starting Memetest, it found memory errors again. So now I tried many more times to restart the computer (from Win7, from Linux and from Memtest) and start memtest (with all 4 modules separately and together) and finally I concluded that Memtest86+ finds memory errors only after just restarted machine from Win7 (when restarted from Linux, or restarted from Memtest86+ I don't have these errors). Now I installed the last Memtest86+ version 5.01, and all is the same like with v4.20. I also tried with Windows's memory diagnostic, all modules separately and together (Windows memory diagnostic was run directly after windows restart), and it didn't found any error. The last time I tried with 2 modules so attachd are some pictures.


So this happens only with Memtest86+ and when machine is restarted from Win7
I tried also with Memtest86 v4.3.6 from USB stick, and the same happens like with Memtest86+

[David (PassMark)]

MemTest86+ (with the plus) is not our software and we don't support it. The author of MemTest86+ used the same name when he made an alternative version using the MemTest86 source code leaving a large number of people confused.


Do you have the latest BIOS for the motherboard. I see on the Gigabyte site they are listing, "Enhanced memory compatibility" as a feature of their last BIOS version.
http://www.gigabyte.com/products/product-page.aspx?pid=3439#bios

[tomidis]

Hi David,
thanks for answering
yes, I have the latest bios version
absolutely the same happened when I tried with memtest86 (without plus) from usb stick
Isn't strange that errors shows the failing address at more MB than currently installed (the same with Memtest86 v4.3.6)??
I'm very confused. What can be wrong???

[David (PassMark)]

It is possible to have a RAM address that is slightly above the listed maximum RAM installed. The memory manager can put holes into the address space. It doesn't mean you have extra RAM, it just means the address space isn't continuous.

So just to recap;
If you power up the machine from a powered off state you never get any errors with MemTest86 4.3.6.

If you power up the machine then boot into Windows, then select "Restart" from the Windows start menu, then (without powering down) reboot into MemTest86 4.3.6, you get errors straight away.

Both these cases happen regardless of how many sticks are in the machine, or what slots they are in?

[tomidis]

yes, yes, yes,...... to all you wrote
also if I restart from Linux Mint I never get any errors. If I restart from Windows but testing with Windows's memory diagnostic, I also don't get any error.
only with Memtest86 (with or without plus) when I boot into Win, and then select "restart" from start menu I get errors. If I restart with "esc" from Memtest86 and then start again Memtest86 there is no errors anymore

[David (PassMark)]

I think there are only a few possibilities.

- The cause and effect is just co-incidence. And what you are seeing is just random RAM errors (or CPU/MB errors) that happen to fit the pattern you describe, so far.

OR

- When you boot into Windows, then the values left sitting around in the RAM provoke an error (somehow). If this was the case then you should not see the same errors on the 2nd pass in MemTest86.

OR

- The errors are not really random, but instead related to some other effect. e.g. temperature. Having booted the machine into Windows might heat it enough to provoke the errors upon the reboot.

OR

- There is a common bug in both versions of MemTest86 that no one has noticed up until now.


Note that RAM errors don't mean the RAM is bad. There might a slight incompatibility. So if you had another stick (from a different vendor) I would try that to start with.

What are the details for the BSOD?

[tomidis]

Hi,
I tried some more testing, so I can confirm the following patterns:
- when errors are detected, they are detected very quickly after Memtest86 start (if they aren't detected before test #5, they will never be detected)
- when errors are detected, the longer testing time is, the more errors is detected, all following passes after the first pass also detects the errors
- errors are detected only after the machine has been booted up into Win7
- the last testing confirms the machine can be booted into win7 up until the user logon screen (I don't need to login to win7) and the errors will be detected after reboot from the user logon screen
- also I can 100% confirm that errors are detected if the machine is started from the completly powered OFF state, but ONLY if previously was booted up into win7 (enough until logon screen)
- if I turn OFF the machine from Win7 (or from Win7 logon screen), then cut the power supply for up to 10 seconds (until the capacitors are emptied), then switch ON the power supply and start the Memtest86, there are no errors detected!!

[David (PassMark)]

I don't suppose you have a spare CPU or spare motherboard to try?

You could also try adjusting the voltage levels in BIOS. Manually bump it up by 0.1V. You could also try using the slower standard RAM timings in BIOS, rather than any XMP settings the RAM might support.

[tomidis]

unfortunately, I don't have any spare CPU or motherboard
so you think the RAM is OK?
I also thought, this may be motherboard fault, but didn't know there might be even an CPU fault
I'll try to increase the RAM voltage, but I'm not quite familiar with other settings you mentioned (RAM timings, XMP settings). Currently, all settings are at their default values.
Can you help me what timings to change? to which values?

[David (PassMark)]

Hard to give exact steps as it is different in each BIOS.
On some machines nothing is adjustable. On other machines, everything can be adjusted.

[tomidis]

I tried to increase the RAM voltage up to 1,620V, and the errors remained
I noticed when DRAM voltage setting is set to "Auto", this auto value isn't 1,500V but 1,584V (see the last picture)
Please can you look at the timings picture, and tell me what to change?

[David (PassMark)]

Generally I wouldn't suggest planning around with all the individual settings. You really need a huge amount of expertise before you start playing around with these advanced settings.

RAM sticks come with a number of profiles. Which define all the settings at various speeds. Often there is a place in BIOS to just pick the profile. The slower ones are sometimes referred to JEDEC profiles, while the faster ones are called XMP profiles. So if you are running on a XMP profile, try switching back to a JEDEC profile.

[tomidis]

So does this mean the RAM, CPU and mainboard are OK ???

[David (PassMark)]

Interesting.
Are the errors always being reported in exactly the same small range of memory addresses?

If what you say is correct. It implies that the USB3 controller using some the address space for its own purpose (this is known as memory mapped I/O). This is common enough, but when this does happen the BIOS's memory map, which records available free memory blocks, should exclude the addresses being used be the controller. Maybe this didn't happen.

So it might be the case that this Gigabyte P55A-UD3 has a firmware bug. This 4 year old board was one of the first with USB3 on the board. So it wouldn't be too surprising if it was buggy.

[David (PassMark)]

Been doing some more digging. It seems you aren't Robinson Crusoe and there are other people with the same motherboard reporting the same issue.

For example, this guy reported an identical issue a couple of years ago.
http://www.tomshardware.com/forum/28...atriot#4260623

So here is a new theory. Maybe when you boot into Windows, the device driver sets up the USB3 controller and makes it active. When you boot into Linux, the USB3 device driver isn't available (or is at least different) and the NEC/Renesas USB3 chip doesn't get activated.

Once the hardware activated in Windows, it stays in this state until you power down the machine, regardless of reboots. Further hypotheses is that it only messes up the RAM test when it is active.

I will add a comment to the old Tom's hardware post above to see if the guy still has the same motherboard to test with.