Kit with 4 Corsair Vengeance modules showing up errors on every one

[PeTTs0n]

As the subject states, I'm running into problems with my current rig - during test #8, I'm getting thousands of errors on each of the modules in the two kits I purchased. (2x CMK16GX4M2A2666C16)

I've tried testing the modules one by one, in both JEDEC 2133MHz and XMP 2666MHz modes - still showing the same results during the same test.

Running the modules on a Gigabyte GA-Z170X-Gaming 7 (alongside a 6700K), with the newest BIOS (F5) in UEFI mode without CSM support, booting Memtest in UEFI mode as well, of course. Haven't tried the legacy BIOS mode of Memtest (yet).

Anyone recognize this issue, is it a false positive? (I highly doubt 4 out of the 4 modules are actually defective, the probability for that is likely *very* low. Faulty CPU/Memory controller also seems very unlikely, especially since I haven't noticed any stability issues at all, so far. Well, except for the BIOS resetting the frequency back to 2133MHz after having enabled XMP (2666MHz) - has happened during reboots twice, no crashes or errors shown anywhere though.) Windows (10 Pro) is booting up as normal, haven't seen any stability issues yet. (I have basically only installed the OS though.) But I want to make sure all the components are A OK before I start using the PC in my daily life.

(UPDATED) Just ran the Windows Memory Diagnostic tool (mdsched.exe) - no errors found, but it gets stuck on 21% when running the extended test (always 21%, the program itself doesn't crash though, and it isn't showing any errors - tried leaving it on for 6+ hours, and still no progress beyond 21%) so I have absolutely no idea what is actually causing this.


Hope someone has any insight into this!
/Chris

[keith]

It's possible that a UEFI BIOS bug could cause MemTest86 to test ranges in memory not available for usage (eg. MMIO).

Can you post the MemTest86.log file located in the EFI\BOOT\ folder of the USB drive.

[PeTTs0n]

It's possible that a UEFI BIOS bug could cause MemTest86 to test ranges in memory not available for usage (eg. MMIO).

Can you post the MemTest86.log file located in the EFI\BOOT\ folder of the USB drive.

Will do, before I do though - I noticed that after *every* boot (regardless of whether I actually boot into Memtest) with the USB stick plugged in, BIOS adds another UEFI [drive] partition 1 entry in the boot manager. So after having run several tests yesterday, the BIOS showed a dozen entries for the same partition - I'm starting to consider bugs in the UEFI. Or is this a known bug? Big thanks for the reply!

For some reason, Memtest86 is also showing the wrong frequency for the memory (1067MHz as opposed to the 1333MHz it should be, when running with the XMP profile enabled, and if the program doesn't account for DDR), something known causing that?

Update: Uhm, it might be hard to post a log, since every single write/read op is failing after a certain point. 300 000 errors after just a minute or so, and the test timer hasn't moved a second while continuing the error count. The log should be gigantic if nothing else... I'll leave the test on and see how it goes though. I have contacted Gigabyte as well (the RAM sticks are in the motherboard QVL, I had hoped they'd be compatible), no answer yet though.

[PeTTs0n]

So now I got this too... known bug or some other issue? (It doesn't seem to have crashed though, funnily enough. Test is still progressing.)

[David (PassMark)]

Can you post or EMail the MemTest86.log file located in the EFI\BOOT\ folder of the USB drive.

If you zip it up, it will be small enough. Or else stop the test after you get the first few hundred errors.

Contact details are here.

[PeTTs0n]

Didn't realize the log became truncated when the program detected too many errors - good, here's the log and HTML report! https://www.sendspace.com/file/7voflx

And thanks again for any help!

[keith]

Thanks for the logs. It looks like there was a problem with retrieving the multiprocessor details from the UEFI firmware. This may or may not be related to the errors you are seeing but it is an indicator of incomplete/buggy firmware:

2015-10-28 07:33:37 - Successfully located the PI MpService protocol.
2015-10-28 07:33:37 - WhoAmI failed: Not Found

Nevertheless, we compiled a debug build that will output the exact pattern that is written to memory (for the first 256 bytes), so we can verify if the errors are indeed real. Can you give the following build a try:

http://www.passmark.com/ftp/memtest8...6.2.0.1005.zip

Please select only Test 8 and run the test for at least 5 minutes. It will run quite a bit slower as it will be writing a log of debug output to the log file.

[PetrolHead]

(UPDATED) Just ran the Windows Memory Diagnostic tool (mdsched.exe) - no errors found, but it gets stuck on 21% when running the extended test (always 21%, the program itself doesn't crash though, and it isn't showing any errors - tried leaving it on for 6+ hours, and still no progress beyond 21%) so I have absolutely no idea what is actually causing this.
/Chris

Try leaving it on for an even longer time. It took my system 26 hours to run 4 passes of the extended test and I have only two 8 GB modules. I don't know why, but it seems to take the extended test several hours to move beyond the 21% mark (I've no idea where it jumps from there). If this doesn't help, start your troubleshooting by checking your event logs (search for "View event logs", then choose "Windows logs" and "System") for any errors or warnings.

[PeTTs0n]

Working like a charm now - CPU and RAM SPD detection is working as it should (detecting CPU cores and threads correctly, and frequency of the RAM depending on JEDEC or XMP setting), and the test is showing no errors at all, with all 4 sticks running in XMP mode.

Thanks a lot, one burden off my mind! Do you need the logs this time around? (500kb for 10min, slightly less truncated than the regular log. )

I might run the Windows memory diagnostic sometime in the future as well, leaving it on for even longer. Good to know it might take quite some time, thanks!

[David (PassMark)]

Yes, send in the log.
Would be good to confirm what the problem is /was.

[PeTTs0n]

Wilco, here is the new log: https://www.sendspace.com/file/gi4tw8

Hope it shows something useful.

[keith]

Thanks for that. Here's a new build with the debug output removed:

http://www.passmark.com/ftp/memtest8...6.2.0.1006.zip

The problem was indeed related to the bug in the UEFI firmware's multiprocessor services, which indirectly caused problems with our random number generation functions. This affected all tests that use these functions including Test 8. We were able to add a workaround for the bug and it appears to have worked. However, it is possible that the firmware bug may affect other functionality that use the multiprocessor services such as running MemTest86 in the various CPU selection modes (parallel, round robin, etc.)

[PeTTs0n]

Will try out more settings if I can manage to find time - I should've had that PC up and running last week, already behind schedule like crazy. (Graphics card with insane coil whine away for RMA as well, Murphy's law is messing everything up, I think.)

[staples1347]

I also get the same problem with test 8 and the "WhoAmI failed" error on a Gigabyte GA-B150M-D3H motherboard, with F5 BIOS and Intel i5 6500 CPU. Using the new Memtest build resolves the problem, but downgrading to F4 BIOS resolves the problem too.

[PeTTs0n]

I also get the same problem with test 8 and the "WhoAmI failed" error on a Gigabyte GA-B150M-D3H motherboard, with F5 BIOS and Intel i5 6500 CPU. Using the new Memtest build resolves the problem, but downgrading to F4 BIOS resolves the problem too.

Seems like it's a compatibility issue with a combination of some of the following: RAM, BIOS, Memtest. What brand and model of RAM are you using? For my motherboard, Gigabyte has posted a new beta BIOS - haven't tried it yet, but changelog states "improved DDR compatibility".

I also posted a ticket in the Gigabyte support system, they answered with "thank you for the information", basically.