ASUS ProArt X670E-CREATOR WIFI: Random Crashes

[moddingfox]

Have had this board for a couple months now. It has had fairly significant issues with stability on bios 1710 from day 1. The issue presents as an instant system crash with red dram diagnostic led lit. System comes back up on power on just fine after. The interval between crashes ranges between a few minutes to a week with typical being a crash 2-3 days. This happens even under no load. Have swapped ram kits a couple times and reseated all attached components and gotten the same result. 

Linux and Windows 11 both experience the issue, though most of my testing has been on the linux side. I have been collecting system metrics with telegraf and have not seen anything out of the ordinary leading up to the crashes events(in terms of cpu, mem, power, and io usages). journalctl has normal activity up leading up to the time of crash than followed by normal boot. Running linux with kernel 6.5.11 with "rcu_nocbs=0-31 processor.max_cstate=1 apicmaintimer idle=nomwait" seem to help though do not really solve.

For now I just updated to the new 1807 bios some hope as it notes stability improvements(definitions of what types of unstable things maybe under that umbrella would be nice). If things can hold for a month uptime Ill post comment here for the next poor soul with this junk going on to find.

Aside from that I guess I should stop rambling on and get to my ask. Anyone else seeing these types of issues with this board? If so whats your hardware config and did ya find any thing that helps or solves?

--Attached Hardware--

MB: ASUS ProArt X670E-CREATOR WIFI

CPU: AMD 7950X3D

RAM: CORSAIR CMK128GX5M4B5600C40

GPU: GIGABYTE GV-N4090GAMING OC-24

PSU: CORSAIR HX1500I

AIO: NZXT Kraken 360

DISK: x2 Samsung 990 PRO 4TB

DISK: x4 PNY CS1311 480GB

DISK: x1 Western Digital WDC WD60EZAZ-00S

[Silent_Scone]

Hi @moddingfox ,

Judging by your memory configuration you're applying EXPO and then experiencing memory instability. Save you some soak time, all you really need to do is disable EXPO and then evaluate stability. Disabling overclocking when experiencing stability issues should be troubleshooting 101. Overclocking 128GB densities can be challenging, and manual tuning may be required.

[moddingfox]

Okay so follow up here. I found a way to intentionally cause the crash. Intalling ffxiv and using the alt launcher 'xiv launcher' to patch from base install to latest. For some reason after about 5-7 patches into it of the 207 patches it reliability dies. Though this only seems to apply when virtualizing in qemu hosts with the cpu type as host(required part of my stack as this system is intended to be a hypervisor). Gunna run with host cpu type off for a bit and if that is the issue ill go annoy the folks on qemu fourms as at that point its probably the more appropriate spot ^.^ Im still not 100% sure if this is the only thing going on or just a part of it but its what i have been able to dig up thus far. Im also not totally convinced the red dram diagnostic light cycleing at crash is an indicator of error but part of the reset sequence some how but truthfully i havent seen any documentation that denotes the behaviors of the lights in more depth that the tldr of "read component name by red light and associate the error with that some how"(not super great in my opinion but whateves).

[pscharnett]

So, similar setup here. 7950X3D, 64GB GSKILL F5-6000J3040G32GX2-TZ5NR on EXPO, 980 Pro 2TB, 7900XT, NZXT Kraken 240 AIO.  And I've had numerous crashes over months.  I've uninstalled and reinstalled programs, updated my PSU, reseated everything, completed every memtest and free thing I can find, and I can't consistently replicate the crashes, either.  I did note in my reliability monitor that ASUS' Noise Canceling Service seemed to crash at the same time as every crash, which made me think it might be related, but I'm just going to keep trying.  I'm considering starting an RMA with ASUS, since it *seems* like it could be a bad capacitor related issue.

[moddingfox]

My setup has been stable since my last post with what is now a 10 day uptime. I still dont have a percice nail on why win vm's in qemu trigger crashes but seems it only happens when they are given access to host cpu features. I went back and checked some initial wierdness the corsair and nzxt rgb controller applications did tend to make the crash more often. If you use those maybe worth a look them as suspects. After switching to x86-64-v4 all those seemed good as well.