ECC Memory & AMD’s Ryzen – A Deep Dive

Looking for answers in Windows

With the presence of ECC on the processors confirmed, and the motherboard manufacturers not actively disabling it, it was time to see what Windows 10 Pro had to say about whether ECC was actually enabled on this new AM4 platform. As we established on the previous page, given the lack of motherboard-based ECC logging, we have to rely on the operating to do so.

We started off with two popular commands, both of which can be run in command prompt:

The first command (wmic memphysical get memoryerrorcorrection) essentially queries Windows as to whether it detects any form of memory error-correcting code functionality. Regrettably, 3 signifies “none”. The other options could have been 2 (unknown), 4 (parity), 5 (single-bit ECC), or 6 (multi-bit ECC).

The following command (wmic memorychip get datawidth, totalwidth) queries Windows as to what the per-channel memory interface is. If the TotalWidth value is larger than the DataWidth value then ECC is enabled. Ideally, we would have liked to see 72 for the TotalWidth instead of 64, since that would have indicated that the OS detects a 72-bit memory bus width, which as we discussed in the first page is the norm for ECC memory. Once again, no such luck.

Now while that might seem like a terrible start, the truth of the matter is that despite being popular, both of the commands have proven themselves to be exceptionally unreliable on newer platforms. Similar results have been returned to those running Intel Xeon E3-1200 v4 and E3-1200 v5 workstations, despite the fact that those platforms were running ECC memory and absolutely had ECC fully enabled.

Therefore, it was time to see what some popular diagnostics/system information programs had to reveal:

Despite the fact that the SPD tab in CPU-Z hasn’t properly reported correction in quite a while, this popular utility does have a handy system report feature that few people are aware of. We were hoping that it might provide us with some different type of information, but regrettably it also just showed that there was no memory correction enabled.

Next up was the very latest 5.47-3125 Beta version of HWiNFO64:

While HWiNFO did detect that our Crucial memory modules were in fact ECC capable, it still reported that the system did not have any type of memory correction enabled.

Another failure, so on to the always popular AIDA64, in this case AIDA64 Engineer version 5.80.4098 Beta:

As in the case of HWiNFO64, when we looked at the memory arrays, AIDA64 also reported there were was no error correction enabled.

However, we went through every possible category and found this in the chipset sub-menu:

Eureka! The first confirmation. Could it be wrong? Perhaps, so we installed a non-ECC memory kit and as expected AIDA64 reported ECC as disabled. Not only that, but if you pay attention to the DRAM Scrub Rate, the rate on the ECC memory is almost 500 times slower than on the non-ECC kit. Just to be clear, the scrub rate is not affected by differences in memory speeds or timings. Clearly, that gives us an indication that something is happening in the background. If you don’t know what memory scrubbing is, there is a basic Wikipedia page available that explains it.

We also tried an even newer AIDA64 version (5.90.4200 stable), but the results were the same.

Our next attempt was just a shot in the dark:

Just for the hell of it, we loaded up Windows Server 2016 in the slight hope that an operating system that was designed to be used on exclusively ECC-enabled hardware might produce different results. We tried all of the same Windows commands, as well as all the same applications, and they all reported the same information as Windows 10 Pro.

Based on just the above information, it would not be prudent to say that ECC is enabled on this platform – at least in Windows – but clearly something is going on given the scrub rate. We also can’t yet say whether Windows has the ability to log errors and corrections yet…but you will want to keep reading until the conclusion.

Since our efforts in Windows proved to be less than entirely fruitful, it was time to turn to Linux, which can be surprisingly quick at supporting new hardware due its lack of stifling corporate bureaucracy.