Random hard freezes fw13 amd7840u win11

My Framework 13 7840 arrived earlier this week, and every day has been BSODing. Entirely stock hardware. What’s the deal, what’s going on? I’ve read this entire thread and there doesn’t seem to be much clarity here. It’s ridiculous for how much I spent on this laptop and I’m on the verge of getting a refund, which I’m entitled to in my country.

Absolutely agree with you. I’m frustrated by the lack of communication here. I bought this laptop last week, and only now finding out about this issue that has apparently been going on for THREE MONTHS? I would not have bought this laptop if I was aware of this. This is a serious issue, it’s really very bad that they’re selling laptops they know for a fact are faulty (literally illegal in Australia and I am entitled to a full refund, but it would be more convenient to give it a week to see if they actually release a BIOS update).

If this apparent bios update that’s ‘in the works’ doesn’t come by next week then it’s a 100% refund for me. If it does come, but we still don’t get a clearly written acknowledgement, I’ll happily accept the BIOS fix but definitely won’t be recommending Framework. Such a shame, I was so excited for this laptop.

It’s simply absurd that I had to read a forum thread to get this information. My extremely expensive laptop is faulty, and I had to read a forum post? Where’s the public statement, Framework? Where’s the acceptance that you sold me a laptop that just - doesn’t work? What about the people who don’t know about this forum and the scattered, buried responses by staff members?

What a joke.

1 Like

I know better than to say it’s definitively fixed… but I’ve now got uptime of 8 days, 22 hours, 26 minutes, running the latest AMD Adrenalin and chipset drivers. Probably couldn’t hurt to give it a try while we wait for the Framework BIOS fix.

Adrenalin 24.2.1 / Drivers 23.40.19.01 from 2/15 https://www.amd.com/en/support/kb/release-notes/rn-rad-win-24-2-1-helldivers-2
Chipset 6.01.25.342 from 1/31 https://www.amd.com/en/support/chipsets/socket-fp5-mobile/amd-ryzen-and-athlon-mobile-chipset

3 Likes

So do we actually know if it’s the trackpad at fault? To stop it from BSOding, am I supposed to use an external mouse until the bios update?

This is what I and many others mean by lack of communication. Am I expected to parse this 283 reply thread to understand the situation? The only reason Framework refuses to make a simple public statement clarifying what the issue is and how and when it will be resolved is because it’ll hurt sales. obviously, because I just bought one, but wouldn’t have if I saw such a post. But it’s the right thing to do, and by not doing so they’re entirely demolishing their reputation among everyone who bought these Ryzen laptops. It’s crazy to witness.

Have you contacted support? Was your laptop a prebuilt, or a DIY? Just because you are getting BSODs does not mean you have this exact issue, and Support is willing to help you if you ask them. Even if the bluescreens are reporting watchdog errors there are so many other things that this could be.

While Framework are releasing a BIOS with the same trackpad fix that was made on the Framework Laptop 16, it cannot be known that that is the issue that everyone in this thread is seeing. The Error that the laptops are giving is a general error with many causes, which is why Framework has told people seeing bluescreens to contact support, so that they can address things more specifically for each person. According to Framework there are still not many reports of this issue, so either people are not always contacting support when they get bluescreens, leading Framework to under-report the issue, or there are not that many occurrences of this issue, and it has not become something that Framework feels the need to post about publicly, as they believe they can handle it with a BIOS update or hardware swaps if need be.

1 Like

I do have the exact issue, I’ve checked the crash dump logs. DPC_WATCHDOG_VIOLATION every time, and the behaviour is exactly as has been described multiple times over in this thread - the laptop stutters for about a second before entirely freezing, hangs for about 3 minutes, then BSOD.

Don’t be an apoligist for a corporation’s lack of communication over an issue that is entirely their fault.

1 Like

“Not many reports”, this is one of the most active threads on the forum and has been up for three months.

2 Likes

I am not being an apologist, I’m being fair?

I would be mad too if I had contacted support and got nothing, but instead, Framework has replied to this thread not only telling everyone with this issue to contact support so they can help, but it has been explained many times here that DPC_WATCHDOG_VIOLATION does not mean “trackpad issue”. So who knows if you’re experiencing a trackpad issue, or if you have a common hardware issue, or your drivers didn’t install correctly, or anything else that could cause an issue with the watchdog. Framework have identified a similar issue on the 16 and are addressing both in a BIOS update, but that may not even fix the problem for some people because there is no clear proof that all the people in this thread are even experiencing the same issue.

I can count 24 posters on this thread, one of which is me, who does not even have this issue. So 23 people talking about it on the forum.

If you aren’t happy with how Framework has handled this issue, get your refund and buy something else.

3 Likes

The issue is very clearly a consistent one. There is a specific issue with either the mainboard, the BIOS, or how framework’s BIOS is interacting with the AMD drivers. It always happens when under a moderate to high load. Every person has described the same issue. There are multiple threads about this on reddit. There are thread’s on microsoft’s website and on the LTT forum. It’s a specific issue and I am very frustrated, as others have said here and on other forums, that Framework refuses to make a clear, concise, public statement. Rather, they choose to make comments on forums hidden away from the public view which only become apparent AFTER you buy their faulty laptop and google the specific issue you’re having.

1 Like

Mate, this thread alone has 10.2k views.

1 Like

I’ve offered what I can, and told you multiple times that Framework Support is the place to share your grievances IF you actually want help with this issue. They have a great support staff who wants to help you, they have a 1-year warranty if there is a hardware/software fault that they need to fix, and they have a 30 day return window if the laptop isn’t something you want. If you wish to complain about how Framework is handling this issue, then I don’t really feel the need to argue anymore.

2 Likes

You are not understanding what the issue we’re having here is. Our issue is that: there is a specific, consistent issue with their laptops, and they are continueing to sell this model of laptop without making a public statement and a disclaimer on their purchase page.

What they’re doing is illegal under Australian law, and as the other member pointed out, illegal under UK law. I don’t know where you’re from, but in countries with strong consumer protection laws, we take it very seriously and get rightfully frustrated when we see this sort of behaviour.

I don’t care how helpful support may be - I spent a lot of money on a faulty product and Framework refuses to publicly ackknowledge that and inform potential customers, which is a legal obligation that they have. It’s an very bad look for them and upsetting that a company I had respected for their right to repair advocacy is doing this.

4 Likes

I’ll just leave this here as it seems to have been forgotten already only 12 days later.

There are plenty of us who HAVE NOT had this issue and are using our AMD frameworks daily just fine.

I understand it’s frustrating but “DEMANDING ANSWERS” isn’t going to make things move any more quickly. And if what they’re doing is truly illegal, surely there’s an official means for you to submit a formal complaint to rather than flaming the Framework run discourse which they so kindly allow you to belittle them on. Please be nice.

5 Likes

But making noises here is not providing Framework Support with BSOD reports.

1 Like

Checking in on my system after some back time, looks like it’s been 14 days since my last update post. My system has been stable since then under similar workloads that have historically produced the DPC_WATCHDOG BSOD.

This has been under the configuration as described in that post. I have no idea what exactly I did to improve the stability of the system, but probably the last step taken of importance was running DDU (Display Driver Uninstaller) and doing a clean install of AMD’s 24.1.1. I have not migrated to 24.2.1, although will do so shortly, hadn’t noticed it came out. I use the system 80% of the time with the trackpad (otherwise bluetooth mouse), and a mix of plugged in/battery. I don’t know if the RMA’d ram is ultimately a red herring, or if I accidentally “fixed” something by having opened the chasis so many times while doing diagnostics. Once the system became stable, it’s been rock solid since.

I hope the root cause can be found as there is certainty some bizarre interaction going on. I have made memory dumps available to support under my ticket, but no idea if those got anywhere inside the company.

1 Like

Since other people seem to be having similar experiences, I think it’s pertinent for me to also post my experience. I used to reliably get DPC_WATCHDOG_ERROR BSODs after a few days of uptime until somewhere around last month. I have not seen any BSODs in at least a month, despite having uptimes of over 10 days (my system stands at 13 days currently).

The last major thing I remember doing was installing 24.1.1 and the corresponding new chipset drivers, but I then downgraded to Framework’s drivers since it broke the UMA setting which increases dedicated GPU memory. Whether it’s something to do with that or a Windows update that fixed the issue I do not know, but it does seem like something has changed for the better. I also never changed the RAM I was running (it’s the 32 GB 5600 MT/s Crucial kit), so at least in my case that doesn’t appear to have been the problem.

Support has now suggested to me that my RAM is the problem. I’m running 2x Kingston Fury Impact 5600MHz CL40 DDR5 sticks (KF556S40IB-16). Support says that those sticks are XMP RAM and aren’t supported. Unfortunately, I don’t have any other RAM to try, but I see others in this thread with the same sticks (although I see plenty of people elsewhere saying they work fine, eg https://www.reddit.com/r/framework/comments/18frka2/framework_13_7640u_kington_fury_impact/). Not sure where to go from here.

Don’t think that is correct (ie. that the RAM is only 5600 using XMP profile). The datasheet for your RAM is clear that it has 5600-40-40-40 JEDEC:

Also, I have the 64GB equivalent and no BSODs.

1 Like

With both the RAM my DIY kit included and the same Kingston Fury I upgraded to, my outcome was exactly the same, which for my experience anyway, would indicate it’s not the Kingston Fury RAM that’s the issue

But that doesn’t stop the RAM from being faulty. Time to drop a support request on the RAM supplier.