B850M-X [WiFi] quick review > it killed my 9800X3D

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   First, I wanted to say, I don't know why people post tech support posts on this "Media & User's Review" sub-forum, when there are separate Tech Support sub-forum here.

Anyway, I posted a positive review of this motherboard on Valentine's Day of 2025, and well, my 9800X3D CPU died on December 29th, 2025, 4 days after I updated the BIOS from 3.50 to 4.03.

I was watching some YouTube stream and just started a session of Holocure, and the screen went blank for a few seconds, came back to a static image of what was displayed before.  It was hard locked then, so I had to press the power button for 3+ seconds to power it down.  After that, it never came back up again.

All I got was  CPU (red) and DRAM (orange) diagnostic LEDs, just as described by many other known cases of ASRock motherboard + 9800X3D death syndrome.  Reseating memory, CPU, flashback to 3.50, CMOS clear, etc. didn't help.  Neither the CPU nor the socket had any sign of damage.  The CPU was installed once back in February and never touched, so I don't see how the socket pin would get damaged anyway.

I purchased ELEVEN ASRock AM4 boards, including one DeskMini X300), and never had a problem with them.  Some of them are so old, I had to replace CMOS batteries on them, yet they're all going strong.

But this B850M-X WiFi (R1.0) was my first and only AM5 board, so I couldn't do further testing.  It turns out, nothing else in the system was bad.  Power Supply, RAM (expensive workstation ECC UDIMMs), SSDs, and even USB devices are all fine.  I know now, because I resurrected the system using a new replacement CPU AMD sent me.  I did buy a new non-ASRock AM5 motherboard, because I saw someone in similar situation lose the SECOND 9800X3D to the same motherboard.

There are many write ups about these Ryzen 9000 series (mostly X3D chips) failures on mostly ASRock motherboard online (Reddit, various tech websites, and videos by Gamer's Nexus and Level1Techs), but no one has reached a conclusion as to why these chips were dying.

My case is likely quite unusual, so my intent is to document it somewhere (here).

I purchased the CPU in early 2025 and completed the build in the first week of February, 2025.  The CPU was manufactured in the last week of November, 2024 (CF 2448PGY).  2448 (Year 2024, Week 48) is the #1 represented failing batch when you add up 2448PGE and 2448PGY, so this points to manufacturing issue at AMD / TSMC.

I've NEVER enabled PBO.
I even disable standard Performance Boost feature, so my CPU was limited to 4.7GHz (rather than 5.25GHz boost) the whole time I had it.  The only times it might have gone over that is on the first boot and after each BIOS update.  I'd immediately go into BIOS and disable Performance Boost.

I've NEVER enabled EXPO/XMP.  I don't even have a DDR5 DIMM with such profiles.  The only DDR5 DIMMs I have are two sticks of Micron MTC20C2085S1EC56BR, which are 100% JEDEC spec 5600MT/s CL46 Unbuffered ECC Workstation DIMMs.

I've also NEVER used SLEEP feature.  I turned the PC on soon after waking up, and turned it off right before going to sleep.  Other than occasional overnight runs, it lived like this for close to 11 months before dying.

I also ran the CPU in 65W TDP ECO mode.

For maybe the 2nd half of its life, I also ran the memory underclocked to 5200MT/s, because I didn't like the relatively high VSOC of 1.19V when running 1:1 MEMCLK:UCLK.  Running it at 5200MT/s allowed VSOC to be lowered to 1.10V.  Running it in 2:1 mode (MEMCLK at 1400MHz, UCLK at 2800MHz, 5600MT/s) allowed way lower VSOC, at 0.90V, but I didn't want to give up that much.

I started with L3.18 AS01 BIOS, then updated sequentially to L3.18 AS02, 3.20, 3.25, 3.30, 3.40, 3.50, then 4.03.  Some people claim that the issue was fixed at 3.25, and since I ran the system for a few months prior to 3.25, it could've degraded the CPU by then.  I honestly don't believe this, because there are people who managed to kill the CPU starting out with BIOS 3.25 or later.

Other than maybe a couple of weeks when I had a RTX 9060 XT 8GB in the system, it did NOT have a dGPU, so I was using the 2CU RNDA2 iGPU.  I doubt that had anything to do with the failure, though.  Almost no one with 9800X3D would run without a dGPU, so it's just another uniqueness with my case.

Have ASRock & AMD root-caused this issue?  I can believe it if at least one of them did, but won't say anything because it's cheaper to stay silent.  I can also believe they're both clueless.

Ryzen 7000 series and 9000 series CPUs (not APUs) have IDENTICAL IODs, so unless AGESA is misprogramming it on the 9000 series, I don't see the IODs themselves being the problem.  If IODs were the problem, 7000 series would be failing the same way.  So I'm more inclined to think that it's the 9000X3D's CCDs that are dying.  Surely, AMD must've analyzed bunch of returned CPUs to see what's going on.  Silence from AMD is deafening.  Then why are ASRock motherboards so overtly represented?  I've no idea.

Whatever is the case, I needed to absolutely minimize the chance of killing the warranty replacement CPU, so I bought a new ASUS TUF Gaming B850M-PLUS WIFI to resurrect my system.  The once murderous ASRock B850M-X WiFi now sits in its original box.  I've no idea what to do with it.  This ASUS model did not exist when I built my system originally, but it turned out to be a nice upgrade for me.  I went from pokey 6+1+1 VRM to 14+2+1 VRM.  I got an extra NVMe slot, and also the audio is the top-notch ALC1220P.  If I had ALC1220P from the get go, I probably wouldn't have gone out of my way to buy a Topping D10s DAC.  Of course, even ALC1220P is no match for the D10s, and I already have it, so I'll keep using the D10s.

The replacement CPU is CF 2538PGE (manufactured mid-to-late September, 2025), so is much newer.  If the problem was with CPU itself, hopefully the issues were resolved long time ago and my new CPU won't ever have a problem.

I can't even remember the last time any of my PC components died on me.  So this was a bit traumatic for me.  I'm talking over 25 years of me keeping records.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
eccential Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 10 Oct 2022 Location: Nevada Status: Offline Points: 6910	Post Options Post Reply Quote eccential Report Post Thanks(0) Quote Reply Topic: B850M-X [WiFi] quick review > it killed my 9800X3D Posted: 14 Jan 2026 at 3:40am
	First, I wanted to say, I don't know why people post tech support posts on this "Media & User's Review" sub-forum, when there are separate Tech Support sub-forum here. Anyway, I posted a positive review of this motherboard on Valentine's Day of 2025, and well, my 9800X3D CPU died on December 29th, 2025, 4 days after I updated the BIOS from 3.50 to 4.03. I was watching some YouTube stream and just started a session of Holocure, and the screen went blank for a few seconds, came back to a static image of what was displayed before. It was hard locked then, so I had to press the power button for 3+ seconds to power it down. After that, it never came back up again. All I got was CPU (red) and DRAM (orange) diagnostic LEDs, just as described by many other known cases of ASRock motherboard + 9800X3D death syndrome. Reseating memory, CPU, flashback to 3.50, CMOS clear, etc. didn't help. Neither the CPU nor the socket had any sign of damage. The CPU was installed once back in February and never touched, so I don't see how the socket pin would get damaged anyway. I purchased ELEVEN ASRock AM4 boards, including one DeskMini X300), and never had a problem with them. Some of them are so old, I had to replace CMOS batteries on them, yet they're all going strong. But this B850M-X WiFi (R1.0) was my first and only AM5 board, so I couldn't do further testing. It turns out, nothing else in the system was bad. Power Supply, RAM (expensive workstation ECC UDIMMs), SSDs, and even USB devices are all fine. I know now, because I resurrected the system using a new replacement CPU AMD sent me. I did buy a new non-ASRock AM5 motherboard, because I saw someone in similar situation lose the SECOND 9800X3D to the same motherboard. There are many write ups about these Ryzen 9000 series (mostly X3D chips) failures on mostly ASRock motherboard online (Reddit, various tech websites, and videos by Gamer's Nexus and Level1Techs), but no one has reached a conclusion as to why these chips were dying. My case is likely quite unusual, so my intent is to document it somewhere (here). I purchased the CPU in early 2025 and completed the build in the first week of February, 2025. The CPU was manufactured in the last week of November, 2024 (CF 2448PGY). 2448 (Year 2024, Week 48) is the #1 represented failing batch when you add up 2448PGE and 2448PGY, so this points to manufacturing issue at AMD / TSMC. I've NEVER enabled PBO. I even disable standard Performance Boost feature, so my CPU was limited to 4.7GHz (rather than 5.25GHz boost) the whole time I had it. The only times it might have gone over that is on the first boot and after each BIOS update. I'd immediately go into BIOS and disable Performance Boost. I've NEVER enabled EXPO/XMP. I don't even have a DDR5 DIMM with such profiles. The only DDR5 DIMMs I have are two sticks of Micron MTC20C2085S1EC56BR, which are 100% JEDEC spec 5600MT/s CL46 Unbuffered ECC Workstation DIMMs. I've also NEVER used SLEEP feature. I turned the PC on soon after waking up, and turned it off right before going to sleep. Other than occasional overnight runs, it lived like this for close to 11 months before dying. I also ran the CPU in 65W TDP ECO mode. For maybe the 2nd half of its life, I also ran the memory underclocked to 5200MT/s, because I didn't like the relatively high VSOC of 1.19V when running 1:1 MEMCLK:UCLK. Running it at 5200MT/s allowed VSOC to be lowered to 1.10V. Running it in 2:1 mode (MEMCLK at 1400MHz, UCLK at 2800MHz, 5600MT/s) allowed way lower VSOC, at 0.90V, but I didn't want to give up that much. I started with L3.18 AS01 BIOS, then updated sequentially to L3.18 AS02, 3.20, 3.25, 3.30, 3.40, 3.50, then 4.03. Some people claim that the issue was fixed at 3.25, and since I ran the system for a few months prior to 3.25, it could've degraded the CPU by then. I honestly don't believe this, because there are people who managed to kill the CPU starting out with BIOS 3.25 or later. Other than maybe a couple of weeks when I had a RTX 9060 XT 8GB in the system, it did NOT have a dGPU, so I was using the 2CU RNDA2 iGPU. I doubt that had anything to do with the failure, though. Almost no one with 9800X3D would run without a dGPU, so it's just another uniqueness with my case. Have ASRock & AMD root-caused this issue? I can believe it if at least one of them did, but won't say anything because it's cheaper to stay silent. I can also believe they're both clueless. Ryzen 7000 series and 9000 series CPUs (not APUs) have IDENTICAL IODs, so unless AGESA is misprogramming it on the 9000 series, I don't see the IODs themselves being the problem. If IODs were the problem, 7000 series would be failing the same way. So I'm more inclined to think that it's the 9000X3D's CCDs that are dying. Surely, AMD must've analyzed bunch of returned CPUs to see what's going on. Silence from AMD is deafening. Then why are ASRock motherboards so overtly represented? I've no idea. Whatever is the case, I needed to absolutely minimize the chance of killing the warranty replacement CPU, so I bought a new ASUS TUF Gaming B850M-PLUS WIFI to resurrect my system. The once murderous ASRock B850M-X WiFi now sits in its original box. I've no idea what to do with it. This ASUS model did not exist when I built my system originally, but it turned out to be a nice upgrade for me. I went from pokey 6+1+1 VRM to 14+2+1 VRM. I got an extra NVMe slot, and also the audio is the top-notch ALC1220P. If I had ALC1220P from the get go, I probably wouldn't have gone out of my way to buy a Topping D10s DAC. Of course, even ALC1220P is no match for the D10s, and I already have it, so I'll keep using the D10s. The replacement CPU is CF 2538PGE (manufactured mid-to-late September, 2025), so is much newer. If the problem was with CPU itself, hopefully the issues were resolved long time ago and my new CPU won't ever have a problem. I can't even remember the last time any of my PC components died on me. So this was a bit traumatic for me. I'm talking over 25 years of me keeping records.

Xaltar Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 35863	Post Options Post Reply Quote Xaltar Report Post Thanks(1) Quote Reply Posted: 14 Jan 2026 at 5:04am
	Thanks for the info eccential, hopefully someone at ASRock or AMD will find it useful. This issue has really got me scratching my head. I have seen other brands report failures too but far fewer. I don't know if it's because ASRock sells more boards in this segment or if their boards are actually more susceptible. I know both AMD and ASRock are honoring RMAs without too much issue but the cause is what's bothering me. I don't have an AM5 system to test with myself so all I can do is look at reports like yours and ponder.


dynetra Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 07 Apr 2026 Location: 649 Cedar Ave, Status: Offline Points: 30	Post Options Post Reply Quote dynetra Report Post Thanks(0) Quote Reply Posted: 07 Apr 2026 at 10:53am
	Appreciate the detailed write-up, cases like this are useful for spotting patterns. The batch correlation you mentioned is interesting, have you seen any confirmed failures from newer production like your replacement CPU?

Xaltar Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 35863	Post Options Post Reply Quote Xaltar Report Post Thanks(0) Quote Reply Posted: 07 Apr 2026 at 3:47pm
	With the recent uptick in failures on CPUs in use for over 7 months I am suspecting more and more that the IMC is the issue. It also tracks with ASRock boards being hit harder early on. ASRock has always pushed the RAM side of things in their BIOS to get a competitive edge over other brands. It has worked very well for them in the past so why wouldn't they continue doing what works for them. They had the experience, knowhow and baseline data to work from. IMO, and this is purely speculative on my part, AMD did exactly the same thing with the 9k series, pushing the RAM to it's absolute limit to widen the performance gap between the 7k series and the 9k series. Combine the already aggressive settings from AMD via their AGESA and ASRock's usual performance tweaks and you have overloaded IMCs. The thing is, I think AMD pushed the aggressive settings further than they should have. This is based on the number of failures we are seeing 7 months+ out from initial build. When a CPU fails within a month it's almost always either a badly binned CPU or a serious issue with a BIOS version. When a CPU fails after 6 months+ of reliable use, it's degradation. Yes, BIOS settings can cause said degradation, I used to see this quite often in my heavily overclocked systems, but many of these reported failures are happening on other brands now. This tells me that either AMD's binning is not aggressive enough or their RAM/IMC related settings are overly aggressive and causing degradation. Batch numbers would certainly be a factor here, if a batch was binned less aggressively then it will have a higher failure rate. I imagine AMD has been steadily tightening up their binning as the platform matures and yields improve as well as to prevent the failure rate from climbing beyond acceptable industry failure rates. Basically, they are doing what they are supposed to be doing. My opinion is that the initial timings, voltages and related settings were slightly too aggressive and this resulted in clustered failures (all IMC related). The thing is, these failures still fall well within acceptable margins so we are not talking some massive mess-up or critical error. Unfortunately the fact that so many of the failures happened quickly and were reported on the same platform all at once (redit) made the issue appear far more alarming than it is. TLDR, I think IMCs in the 9k series are degrading faster than they did on the 7k series. All IMCs will degrade, this is the Achilles heel of pretty much all modern CPUs. AMD was a little too aggressive with their RAM performance push on the 9k series and it just pushed the IMC a little too hard on less stringently binned CPUs/batches. Given the physical IMC (contained in the IOD) in the 9k series is identical to the 7k series I think they pushed it right to the edge with the 9k series and it resulted in somewhat higher failure rates. I could naturally be entirely wrong but that is my take for whatever it's worth. Edited by Xaltar - 07 Apr 2026 at 3:55pm


dynetra Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 07 Apr 2026 Location: 649 Cedar Ave, Status: Offline Points: 30	Post Options Post Reply Quote dynetra Report Post Thanks(0) Quote Reply Posted: 4 hours 52 minutes ago at 10:04am
	Interesting take, but have you ruled out SOC voltage and EXPO profiles being the main cause of IMC stress over time? It might be worth comparing failed systems running high VSOC or aggressive memory timings versus those on stock JEDEC to see if degradation patterns differ.

Xaltar Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 35863	Post Options Post Reply Quote Xaltar Report Post Thanks(0) Quote Reply Posted: 1 hour 7 minutes ago at 1:49pm
	VSOC and EXPO will strain the IMC more than JEDEC and conservative timings. Looking at various forums where failures have been reported there is a disproportionately larger number of EXPO users who have experienced failures (unlocked VSOC too in many cases). The thing is, people taking precautions have also experienced failures, like eccential the OP but these tend to be cases where the failure occurred after 6+ months of use. What you mention isn't something to be ruled out, it supports my assessment. Lower VSOC and conservative RAM profiles (JEDEC) will place less strain on the IMC and that tallies with the failures I have seen reported (baring in mind many of these sources are unreliable). The majority of reported failures were using EXPO and no limits on VSOC. There are still failures reported with locked VSOC under 1.15v and no EXPO/XMP loaded (using JEDEC or conservative custom profiles). 4.10 seems to change a number of secondary timings for various RAM kits even at the JEDEC level, this is one of the primary reasons I suspect the IMC is degrading faster than AMD expected. Bare in mind, I am just a community moderator, I don't have access to actual failure rates, statistics and other data that AMD/board manufacturers would. This is purely my personal opinion based on observations drawn from keeping an eye on failure reports from various unofficial sources (forums like this one). My point is, VSOC, EXPO, aggressive timings, misconfigured sub timings, all of this puts strain on the IMC. It's an incredibly difficult issue to pin down because everyone with a dead CPU is reporting it as though their board killed it. This includes user error, overly aggressive overclocking, DOA CPUs (QC issue by AMD), EXPO profiles that failed to POST and a huge number of other causes. Basically, any time someone gets a "00" code or DRAM and CPU debug lights are lit, they think the board killed their CPU. I have seen multiple cases where all that was needed was a proper CMOS clear with battery out. All this muddies the data. There is an issue but what symptoms are real and which are misreported failures with completely unrelated causes? We now have a lot more data, muddy as it may be, to guess based on. To me "00" and DRAM + CPU LEDs lit indicate a failed IMC or IOD based on carefully sifting through the data. I am not an electrical engineer however so my speculations should be taken as just that.


Xaltar Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 35863	Post Options Post Reply Quote Xaltar Report Post Thanks(0) Quote Reply Posted: 53 minutes ago at 2:03pm
	I have absolutely no influence on AMD, ASRock or any other manufacturer. I do not have access to any of their statistics or data and I do not speak on behalf of anyone but myself. Sorry, I need to repeat this every once in a while because people often take my word as coming from ASRock. ASRock and AMD won't provide me with any data on the issue. I am no different to any other forum member in that regard. I am not under any kind of NDA so there is no way I would be given access to sensitive in house information.