ASRock & 9800X3D Instability and Failures | Report & Summary So Far

Google Form results, collected by u/ofesad, who granted us permission to share his results, show numerous failures sharing the same CPU batch/lot number. This highlights possibly bad batches from AMD, but we think it’s more likely a BIOS issue.

Other users claim they “revived” their seemingly dead CPU by downgrading to a previous BIOS, and ASRock sent two users a then-unreleased BIOS that resolved their issues, but asked them not to share it.

If these issues keep happening and AMD and ASRock can’t get to the bottom of it, we’ll do first-party, hands-on testing with some of the boards and CPUs that might be affected. But we think it looks like they’re getting to an answer so we’re going to monitor the situation because it looks pretty close to a resolution. This appears to be a couple possible issues. BIOS is definitely one of them. We’ll also talk about the batch thing, which seems a little shaky. 

We’ll be able to use this piece later if ASRock and AMD can’t resolve the situation. This story offers a quick recap. We’ve compiled all the information we could find out there so far on the specific issues and failures so that you’ll have all of the evidence. If this helps you research any issues that you’re running into then we’ll also present a couple of solutions we found or we’ve thought up. 

We’re making this because we compiled all of the research for it but we haven’t done a first-hand testing deep dive on it yet because we’re basically at a stage where we’re trying to figure out if that’s necessary. This is a new approach for us, where we’re compiling all of our research and we’re just going to put it out there and hopefully it helps someone. Likewise, hopefully some of the people who are running into problems with this issue might contact us with potential leads on where to go next.

This is also Tannen’s first research piece and he’s done a great job compiling everything, digging through the forums, and putting together this report to share with you all and to hopefully help some people who are running into this. We plan on following up on this as we learn more. It may be contained to just hardware news, but if a lot of people inform us of potential leads then it may be possible that we revisit this with hands-on testing.

Defining the issues

Failures in any CPU line happen, but Intel’s recent issues were uniquely bad. We don’t see that too often. 

The 9800X3D that famously exploded on Reddit a few months ago is also in recent memory, but after doing some forensics on that one, all evidence pointed toward crushing the socket at an angle and not being correctly oriented when the clamp was closed. That CPU also died immediately and before the user was ever able to boot, further reinforcing that 12V shorted to ground because it just died on boot.

These ASRock and 9800X3D failures are different: They’re happening sometimes months into use, meaning that the systems did work, but stopped spontaneously.

Generally, CPUs are among the most stable components, and so it’s easy for the story to run away with the social media cycle -- but dozens of failures on one platform in a relatively short time span does cause questions.

For perspective, though: Retailer Mindfactory alone has sold over 20,000 9800X3Ds, leading us to estimate the worldwide units sold are in the hundreds of thousands. 

There’s a very small chance of experiencing these issues yourself, even if you’re using a 9800X3D and ASRock motherboard. Both the number of reported failures and ASRock’s seemingly higher incident rate both stood out to us.

The Problem

Here’s what’s going on: Some user systems with a 9800X3D are able to POST, or power-on self-test, and run as expected. The time until failure ranges from under an hour to 3 months. Those with debug displays encounter a “00” error code, which commonly indicates a CPU problem. 

There seems to be two root causes: First is a possible bad batch of CPUs from AMD; second appears to be ASRock BIOSes causing problems with system boots as well as motherboard settings possibly leading to potentially unstable CPUs.

One of the things we came across here was a potential for voltage that was too low, which shouldn’t hurt anything. It just wouldn’t be able to boot. So that’s actually good news because that means you don’t have to, hopefully, worry about the CPU exploding. That has happened in the past.    

One challenge is that there are some dead CPUs out there with burn marks. Currently, the research we’ve been able to do makes it unclear how connected these issues are. We just want to be very transparent about that. Right now, it is impossible to differentiate with our current research between those possible failures without some more hands-on testing. We’ll keep monitoring to see if we need to more aggressively bring in components for testing, but with the pace ASRock has been working on this, we suspect they’ll hopefully have a fix before we could root-cause it since the lab team is bogged-down with other failure analysis right now.

Strangely, we also noticed that many users note their boards work fine with other processors either prior to or after their reported 9800X3D failures. 

Findings Between All Reports (Cause Unclear)

Let’s get into the causes of failure we found across the posts.

All reported failures produce the same initial symptoms of failure, making it challenging to establish the source. Adding to the complexity, not everyone using a 9800X3D and ASRock motherboard experiences failures. We’ll start with findings from all failure types before covering specific cases where the origin is more easily identifiable.

In the sample report of 42 9800X3D failures at the time of writing, the boards affected include: 34 ASRock, six ASUS, one Gigabyte, and one MSI. Chipsets include: 30 X870s, six B850s, four B650s, and two X670s. It appears to be distributed across multiple chipsets and multiple motherboards but the distribution seems to match what people tend to buy right now. Failures occurred on BIOS versions: 3.11, 3.15, 3.16 , 3.17 (beta), and 3.18 (beta), though it’s unclear if failures were necessarily caused by those BIOSes. For the time before failures: six weren’t specified, 15 occurred in a week or less with four of those happening in less than a day, 14 took place in the range of one week to one month, and seven took over a month before failing. 

Also, four listings report the CPU showing burns or markings, which is what caught our attention.

Issue 1 (BIOS Boot issues)

It’s hard to parse what might be causing those specific burns versus everything else so we’ll start with BIOS issues.

At least four users fixed their presumably dead 9800X3Ds by flashing back BIOS to a previous version, which means the CPUs weren’t dead, and two remedied their issues by updating to a “special” BIOS sent to them by ASRock.

u/Flaringup noticed failure after updating to BIOS 3.16. u/Eldaroth experienced the issue after updating to BIOS 3.18. u/Fancy_Potato1476’s system malfunctioned shortly after installing Windows with the motherboard running 3.15 out of the box – turning the computer into a truly fancy potato. This was also the same BIOS u/Kojac4323 was using when he encountered failure.

These user reports indicate failures typically happen after a BIOS update and suggest versions 3.15, 3.16, and 3.18 may cause boot issues.

Three of those users claimed a BIOS flashback to an older 3.10, 3.11, or other old versions resolved their issue.

User u/Eldaroth explained that a 3.10 flashback didn’t immediately solve the problem, but after a second attempt at a 3.05 flashback, Eldaroth was able to “revive” the system. From there, the user flashed back to newer BIOSes and found 3.10 was the latest option working for the build.

This suggests that the issues may not be killing the CPUs (except for the ones with the scorched marks, but that’s a different story), but that it may be a boot issue. The hope would be that a botched BIOS is just causing issues booting and not causing any damage to the CPU itself. It’s rare for a BIOS to damage a CPU, but it can happen. We saw that with ASUS previously on the 7800X3D, which is why everyone is so sensitive to this issue.

At the time of writing this, we haven’t spotted any 9800X3D boot issues occurring on BIOS 3.10, possibly establishing it as the most stable option currently. Users who reverted to 3.10 reported their systems being fixed.

As for the users who received a BIOS from ASRock: According to one, ASRock stated, “Attached is the new BIOS. Please do not spread this yet. It will probably be released soon. This BIOS is not related to the dying CPUs. But it can help with some other boot issue. If you can try it that would be great. After the update, please remember to give the system a few minutes to see if it boots.” 

That’s likely a reminder that memory training can also look like a boot failure. Especially in some configurations, memory training can take 5-10 minutes in some situations.

The other user with the new BIOS claimed: “ASRock confirmed to me that 3.18.MEM03 that they provided to me increases the voltage to 1.2V for the 9800X3D and that allows it to boot and fix the 00 debug code. The issue is that not enough voltage was applied for some 9800X3D units and it was not stable.” Both users reported this BIOS resolved their situation.

This would be better than the possibility that it was overvolting the CPUs, which would be the only likely way the BIOS would actually inflict damage to the CPU. Too little voltage likely won’t hurt, but it’d also be unstable. If this is the case, then this would be one of the better failures to have.

On February 24th, ASRock released a beta BIOS 3.20 with the description stating, “Improve minority proportion of AMD 9000 series CPU boot issue.” We assume this was the same BIOS previously sent out to those select users. 

To be clear, BIOS updates won’t “revive” a literally dead CPU, but they can potentially solve boot issues causing your CPU to appear as dead. We think some users experiencing boot issues and concluding it’s a dead CPU might’ve partially contributed to ASRock’s disproportionate CPU failures, and actually what they might have been seeing instead was just that it wasn’t booting without the CPU being dead, though we can’t fault the users for believing that.

Issue 2 (CPU Batch Failures):

Moving on to the failures possibly caused by a bad CPU batch.

As seen in the “9800X3D fails” Google Form results, out of the nine users who included their CPU’s batch/lot number in their response, seven are from batches CF 2443PGY or CF 2442PGY. 

But remember that this could be completely coincidental and doesn’t necessarily guarantee bad batches. We at GN have CPUs from both of these batches and they’re fine. There is a lot of coincidence here: AMD’s 9800X3Ds have been in high demand and they haven’t been out too long yet. We don’t know how many batches there are, but we wouldn’t think it’s a crazy amount. Likewise, people experiencing any kind of failure, whether that’s caused by the board or the CPU, would be likely on a similar batch if they’re all building and buying around the same time. 

We wouldn’t definitively state that there is a bad batch, but it’s still worth exploring and considering in case this develops and more people report failures from these batches. CF 2443PGY and CF 2442PGY would be the 2 codes to pay attention to.

In those seven responses of the exploded CPUs, the motherboards include: three ASUS, two ASRock, 1 Gigabyte, and 1 MSI, illustrating an expected distribution of failures. ASUS is the largest vendor by market share.

Issue 2 - How to identify the batch number / do some basic checking

If you have a definitely dead CPU and you want to check the batch number, here’s how to identify it. This is also useful for warranty claims. 

The CPU batch number can be found in the image above, outlined in red. The batch number begins with two letters, which we believe to indicate CPU stepping. 

As explained by u/rigred on Reddit, the letters are followed by four digits specifying the year and week the CPU was manufactured, and ends with three letters specifying ATMP and wafer production location.

In the case of the “CF 2443PGY” batch, these were produced towards the end of October 2024 and assembled in Penang, Malaysia.

ASRock Response

There’s been something of an ASRock response, though as of writing this, they’re still investigating.

Current boot issues are addressed by the company’s most recent 3.20 beta BIOS, though its efficacy has yet to be determined on a large scale.

ASRock Japan’s post on twitter, which has been machine translated, states issues occur after updating BIOS on already stable systems. 

If we jump back to u/Fancy_Potato1476, mostly because the name conveys a certain opulence that we appreciate, the fancy potato didn’t update BIOS and still experienced boot issues, seemingly contradicting ASRock's claim. The ASRock post further explains:

"The issue is caused by some older DDR5 RAM and certain memory controllers on X3D CPUs, as well as the impact of Agesa.” 

The first part of that wouldn’t really make sense because if the system is working and then it stops working, that doesn’t really link up to RAM that was stable and then just suddenly wasn’t, but what might connect it is the Agesa part, which is the binary that AMD distributes that’s part of the BIOS and that would affect memory behavior. So if there’s any truth to that statement, then it’s the Agesa part that’s key.

When asked if it’s AMD or ASRock who’s responsible, the company stated via translation, “It is caused by a very specific combination of components.” 

The post ends by repeatedly expressing, “Do NOT update the BIOS if it’s running stably.” 

Generally, we’d agree. These days, new BIOSes can offer important security patches; however, broadly speaking, we prefer not messing with BIOS if everything is working well and there’s no strong security reason to. 

Conclusion

It looks like a combination of issues. There’s definitely a BIOS problem. There’s potentially a problem with the voltage being too low, which is causing inoperability at attempted boot that shouldn’t harm anything physically, so that’s a good problem to have as far as problems go. There’s also a potential bad batch issue. The BIOS issue could have multiple sub-issues, including too high voltage. Some users reported excessive VSOC via HWINFO, but these numbers aren’t always accurate and should be double-checked with physical measurements. 

Some general advice for anyone running into things like this: First, you’d want to rule-out memory training on initial boot. AMD systems, in particular, may require additional time to complete memory training where it’s essentially tuning your memory timings. Memory training normally only happens on the first boot. This shouldn’t take over 15 minutes with a new configuration and should finish much faster for configured systems.

For those using a 9800X3D on an ASRock board, we’d follow ASRock Japan’s recommendations of not updating BIOS unless something appears unstable. 

If something does appear off, we’d advise a flashback to version 3.10 or 3.11 if 3.10’s unavailable. These appear to be the most stable versions of BIOSes in relation to the boot issues. We’d temporarily hold off on updating to the latest 3.20 beta BIOS (unless you have issues already, in which case you should just update) mainly because it’s extremely recent, and beta BIOSes are generally less stable.

Use Flash Back if you already are on an unstable BIOS. This allows a BIOS flash without stability of the platform via a USB key.

If your system’s failing to post after previously working, we’d first recommend inspecting the CPU for any markings before going forward. We’d also advise checking your batch number at this point while your cooler’s uninstalled. 

For the handful of users with another compatible motherboard, we’d suggest using it to test your CPU’s ability to post. This would determine whether your processor’s dead or if there’s a boot issue. If your CPU’s unable to boot in the secondary motherboard or if you don’t have access to one, we’d advise flashing back to BIOS 3.10 first, then 3.20, and finally 3.05, in that order. After each flashback, give your system a few minutes before attempting to boot. If any of these resolve your issue, we’d suggest staying on that version.

If these options don’t go anywhere, you’re unfortunately left with returning the parts to the retailer if you have a warranty or going through an RMA with AMD. Luckily, we haven’t found any claims rejected and have spotted RMAs approved less than 24 hours after submission. 

If you’ve experienced a failure with one of your components and you don’t think it was something that we’ve already covered, you should email us at [email protected]. Conversely, if it’s something we’ve covered and we’re just not done yet, like with this story, for example, then let us know and we might be interested in buying components. We’re also doing an RMA rescue series on our GNCA channel, where we’re basically buying people’s failed components and then pursuing the RMA instead of them having to go through the process of having to do it so that we can test a manufacturer’s warranty process with an actual failed component from an end user. 

Moving forward, we’ll keep following this story if anything develops further.