The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL or above. This could be caused by either a non-responding driver or non-responding hardware. This bug check can also occur because of overheated CPUs (thermal issue).
This is likely caused by a hardware problem, but there is a possibility that this is caused by a misbehaving driver.
This bugcheck indicates that a timeout has occurred. This may be caused by a hardware failure such as a thermal issue or a bug in a driver for a hardware device.
Read this article on thermal issues
A full memory dump will likely provide more useful information on the cause of this particular bugcheck.
Mine is never really under any kind of heavy load when it happens, in fact it seems like light workloads are the trigger somehow, maybe coincidence? Anyway, running long sessions of ZAP which is quite CPU intensive, or playing games, it’s fine. It’s only been editing word docs, working in VSCode or browsing my freezes have happened.
11 crash dumps have been found and analyzed. No offending third party drivers have been found. Consider using WhoCrashed Professional which offers more detailed analysis using symbol resolution. Also configuring your system to produce a full memory dump may help you.
Read the suggestions displayed in the bugcheck analysis above.
The analysis process took 0:00:08 (h:mm:ss).
Computer says no, unless I part with some dosh! Might be worth it to speed up the support process. Seems like support don’t know what’s going on so it might be useful.
I’ve noticed the same thing. I can’t seem to pin down any particular variable on my crashes other than it seems to be low workloads.
Maybe it has something to do with Windows ramping down the CPU to help with battery life, but it gets hung up on something or somehow ramps it too low that it can’t handle it?
The two things I can think of is some sort of power state issue, or maybe it undervolting to an unstable frequency, if that was the case. But then the mobo/bios should have factory configured settings that are set to stable voltages.
I can rule out thermals in my case. I have HWInfo in my taskbar monitoring those, and has never ran hot enough to even reach thermal throttling.
This hitting so many people, even as far back as Batch 3 would make me think either the firmware is buggy or the hardware quality isn’t up to scratch. The only thing unique so far is that everyone with these issues is getting the same BSOD and are all running AMD laptops. It’s not even a bad CPU in terms of performance or battery life, but so many issues will reflect on them. Had I known AMD Framework laptops are assumedly unstable, I would either have gone for an Intel one, or shopped around.
Interesting. How did you narrow it down to RAM? Did you do the whole running on one stick, swapping slot etc? It’s where I’m at with framework support right now
So I have 2 ddr5 sodimm laptops an xps 15 9520 and the framework. I got the framework to replace the XPS because of random hard freezes. I ran memtest on my xps countless times and it would not report any errors. I didn’t think it was the ram when I put the ram from my xps into my framework. So I was getting similar issues as my xps on my framework but I just choked it up to a new platform. A month goes by and I get in contact with support they say they can’t help because I didn’t have supported ram. I didn’t believe that was the issue because I had ran memtest on both machines at this point. Fast forward to two weeks from then and I receive the 8GB skhynix kit that they list in their supported section. Put it in my laptop 0 crashes ever since. Then I validated that by also putting it in my xps and I ran furmark for 24 hours without a crash before ending it myself(previous record is 2 hours). I then ordered the 32gb kit from framework and I have had 0 issues with both laptops since.
It’s just strange because I feel like there was an example of someone running into this on a prebuilt (which would imply it’s not unsupported RAM). It doesn’t quite make sense to me… Why would funky RAM be causing AMD drivers to hang like that…?
I also think that the fact it occurs more under light load than heavy load suggests “not RAM” - RAM should (generally) be more heavily utilized leading to more faults under heavy load. But it is the opposite, which suggests something about the drivers to me. Also, the fact that it doesnt seem to be occuring on Linux (though I wonder what the closed source amdgpu-pro is like on Linux…).
Another light workload crash, Firefox with the Proxmox webUI and some SSH open in windows terminal.
I had hoped the latest windows update had fixed this : /
I had ordered two sticks of Kingston Fury (2x16GB), and after reading @TossedTripod645 experience, I was hopeful it was a dodgy stick that was causing me issues too.
Turns out the DPC_WATCHDOG_VOOLATION still persists. Just happened watching a youtube video…
Looking in the Windows maintenance log I am still experiencing the odd ‘Hardware error’ but it’s not resulting in a BSOD. I suspect this is just driver or firmware related due to this being a relatively new platform and it will be ironed out over time.
I have 2x32GB modules that I got from Framework as part of my laptop order so I’m using supported modules. I’ve made the change to the PCI Express Link State Power Management a while back but just now I got two BSODs due to the DPC_WATCHDOG_VIOLATION in the space of 5 minutes. Both times I was working in Visual Studio after opening a solution so the machine had been working fairly hard for a bit while opening and then ramping down again as I was just typing in the editor. Somebody else suggested the root cause might be related to CPU power state management and that seems to fit.
Here’s the full list of symptoms I see with varying frequency:
Whole system freeze followed by BSOD with DPC_WATCHDOG_VIOLATION error
CPU speed gets stuck very low (500MHz) after coming out of sleep
TPM fails to initialize after coming out of sleep (events in System Event Log and sometimes Windows Hello failures, etc.)
System seemingly crashes while in sleep state (experience this as a full boot when hitting the power button in the morning and events in System Event Log about ungraceful shutdown)
This all happens while plugged into power (I almost never use it on battery).
Like others, I’m very disappointed. I love what Framework is doing and I genuinely hoped this would be the last laptop I buy in a long time thanks to the promise of upgradability and repairability but as it is it’s not fit for work. Really not acceptable for a nearly $2K investment.
The PCI Express link fix only makes the change while on battery, it doesn’t have any affect while you are plugged in.
Have you updated the AMD drivers for chipset, graphics, WiFi and Bluetooth? Also are you on BIOS 3.03?
One other change I have made is the graphics allocation setting in the BIOS which I have changed from Auto to ‘Game’ mode (or similar) to give the GPU more memory.
Installing Framework’s driver pack in a fresh Windows 11 install (following their own install instructions)
Installing AMD’s driver pack in a fresh Windows 11 install (again, following their own install instructions)
Swapping the wifi to an Intel AX210
Trying different RAM configurations
** Running single stick in slot 0
** Running the other single stick in slot 0
** Running single stick in slot 1
** Running the other single stick in slot 1
** Running a brand new set of Kingston Fury ram
** Tested in memtest without any issues found
Enabling ‘Game mode’ in the bios
Updating my SSD firmware and running an extended SMART test, pass!
Ensuring my BIOS is up-to-date
Changing to ‘Moderate power savings’
I was still experiencing this DPC_WATCHDOG_VIOLATION, with WhoCrashed giving the same thing for the minidump each time:
This is likely caused by a hardware problem, but there is a possibility that this is caused by a misbehaving driver.
This bugcheck indicates that a timeout has occurred. This may be caused by a hardware failure such as a thermal issue or a bug in a driver for a hardware device.
For what it’s worth, my pal testing my original Framework RAM in his AMD HP has worked flawlessly without any issues.
After 16 emails with support, over a month of crashes and god knows how much lost work, Framework have agreed to swap my mainboard. I think I’ve exhausted every last possibility so I’m pleased that something is finally happening.
I’m behind Framework and their noble ambition of revolutionising the laptop industry, but if it persists with the new board, I’m going to pursue a refund. It’s not what I want to do but my work has to come before my ethics on repairability. I’ll share how I get on when the new board is fitted. Have a great weekend!