DRAM Q-LED blinking when Q-Code: 8 occurs is "normal" if you get what I mean.

Q-Code: 8 from what I have experienced is pretty much a universal Q-Code for instability. I can trigger this by various methods:-

- Lowering VCORE so OC destabilise.
- Lowering SOC so OC destabilise.
- Too aggressive an OC on CPU/RAM.
- Too aggressive RAM timings.
- Once or twice I believe I have had this when a program has made PC crash. Ryzen is odd, in that I have rarely experienced a BSOD under W7, it just sorta crash to black screen or Q-Code: 8, only in W10 have I experienced Stopcodes / BSOD.

Don't worry about the RAM not being on QVL. The F4-3200C14D-GTZR will be Samsung B Die, what Ryzen luvs 😄 .

Ryzen loves *some* Samsung B. It's indifferent or downright hostile with other Samsung B, lol. From what I've read, it seems to depend on motherboard part more than on processor part.

I'm guessing Q-Code 8 is a symptom of unstable overclock. Your Ryzen might overclock well, your DDR4 might overclock well, but overclocking both to full overspec simultaneously might be too much. I'd graph out the clock/voltage/temp limits of each overclock in isolation to get a better idea of where the "sweet spot" which balances them can be found on the particular part combination. Sorry, that's all I got, lol.

Korth, been living breathing Ryzen/C6H since launch 😉 .

At first there was an issue where due to lack of firmware development (mainly from AMD side IMO), there where cases of 2933MHz/3200MHz max on Samsung B die. I was such a owner. Later with AGESA 1.0.0.6 same HW has hit ~3500MHz, the OCN thread for C6H is pretty high traffic, a lot of members also had improved results with these later UEFIs. IMO anyone now not achieving at least 3200MHz tight on 1DPC SR Samsung B Die, total RAM 16GB, is doing something vastly wrong on their C6H. 3333MHz fast is pretty much achievable by many IMO. There are several members on OCN with 3466MHz 2DPC SR 4x 8GB Samsung B Die as well, on a C6H. Recently a new member in the C6H thread has 64GB 3200MHz. From 3200MHz RAM MHZz the gains on linked "Data Fabric" of Ryzen is minimal, tightening up RAM is more beneficial.

Besides the AGESA containing CPU microcode updates SMU FW was also updated and IMC FW. Coupled with many of the options which were not exposed in earlier UEFI it has become easier to achieve higher RAM MHz. ProcODT was first exposed in AGESA 1.0.0.4a UEFIs, this did help but was really not enough. Later AGESA 1.0.0.6 opened up timings tweaking and had CLDO_VDDP option, this allows moving memory holes. A CPU which I have is able to do 3333MHz tight but it would not have been possible without access to CLDO_VDDP as that RAM frequency is a memory hole for it. Later AGESA 1.0.0.6RC4 UEFI has also CAD Bus options, tweaking those again can aid stabilising RAM.

Kiaxa, if you're have Q-Code 8 at stock then I reckon it is as I had stated before.

- Once or twice I believe I have had this when a program has made PC crash. Ryzen is odd, in that I have rarely experienced a BSOD under W7, it just sorta crash to black screen or Q-Code: 8, only in W10 have I experienced Stopcodes/BSOD.

As I use W7/W10C I had the case quoted above whilst using FireFox to browse web and Steam to download a game. I tested in both OS with known good setup. Now I can't replicate it for myself. So I reckon due to updates of those SW the issue subsided.

I'd run HCI Memtest, 12 instances set to 1136MB. GSAT is also another good app to use, you can install BASH in W10, info in OP of this thread.

I don't think you have a RAM issue.

I use a GC-WB867D-I (rev. 2.0) which has Intel AC7260 module. I use the latest Intel drivers, 19.xx.x on W7, with the C6H, no issues to report. W10C IIRC I don't install any drivers for that, but will check. I have fresh installs of W7/W10C.

So is still the only situation you get a code 8 when you download game in Steam?