I ordered my FW13 7840u at the end of December and received it the other day. While waiting for the laptop to acclimatize (winter), I came upon this thread. It upset me greatly as the machine my FW13 replaces has been having a similar DPC watchdog violation (though it is on boot, causing boot to hang). The machine being replaced is a Ryzen 5 3500 or something similar. It’s an Asus Vivobook.
I turned on my FW13 today and made note of something. I wonder if anyone has tried regressing their drivers back to the original installed version. While we don’t have the OEM driver (the date on first boot for the AMD driver is either 9/24 or 9/27), I wonder if rolling back to the last WHQL drivers from this time period (that’s 8/2 by my eye) would change anything? They are available under “Previous drivers” on AMD.
I have yet to get a BSOD with a few hours uptime on OEM and bundle drivers from the KB. I am installing 11/1 WHQL drivers from AMD now (driver only install) and will report back on stability after 5 days, I guess. I also installed GRC’s InControl to suspend feature updates in Windows 11 for the time being. In fact, I bypassed the online Windows setup and paused updates before configuring my WiFi. So as far as I know, there have been no Windows updates on my machine.
Edit: I have also not updated the BIOS although the unit seems to have shipped with 3.03.
Support asked me to remove the AMD drivers and re-install the Framework driver pack - the issue still persists, if anything, is more frequent than it was before.
They asked me to remove expansion cards, remove the SSD and remove the memory in slot 1, enter the bios and report back whether or not it hung. It didn’t hang.
There is clearly an issue here affecting a lot of AMD users. I am really disappointed they have not acknowledged this issue for the sake of transparency and so consumers can make informed choices before choosing AMD with Framework.
I’m waiting to see what Support say, but I’ve lost waaaay too much time to this now and will probably ask for my money back. It’s such a shame, I really want Framework to succeed, but they need to be more transparent with their customers.
It might be helpful if we document what we were doing when the crashes occured. For example, crashes while gaming are less worrisome than crashes while idling on the desktop, or crashes while web browsing. Plus it could have some future value in trying to track down the source of this issue. Just my two cents.
Best of luck all. I have yet to see the DPC watchdog violation, and in fact Event Viewer seems to have quieted down entirely, generating just an error or two on boot. I don’t see any critical events in event viewer, save one unclean shutdown due to Windows Update hanging.
I just had a crash with my fw13 amd7640 on Fedora 39.
2x32GB RAM and 1TB SSD.
Suddently I had my mouse/keyboard stopping working, the screen which turned black and back. I had to force a reboot. First time it happened since I received my Framework 2 weeks ago.
For me, the crashes have exclusively happened under low workloads. The ones I can recall have been:
Using Firefox, just browsing, not watching videos with a handful of tabs
Using VS Code with Docker running in WSL (most frequent activity when BSODs occur)
Editing a tiny vector graphic in Affinity Designer
Like I say, all lightweight workloads where the system isn’t being pushed. In my experience, Framework’s driver pack seems a lot more volatile than AMD’s provided drivers.
Support have asked me to run the laptop on one stick of RAM, 8GB for me, very painful haha
One thing that I find somewhat encouraging is that I have yet to see this issue reported at all under linux. If it really is the case that one driver set is less stable than the other, these two things in combination seem to suggest that it might be an issue with the Windows drivers.
Of course, open source AMD “drivers” in the mainline linux kernel don’t have feature parity with the closed source drivers, so it’s also feasible that the offending hardware is not in use at all on a stock linux installation.
Are you running the latest drivers from AMD on your machine? It could also be useful to compare which driver version we’re running. Perhaps one is more stable than the others? I have only been using my FW13 a few days, but the 11/1 WHQL set (drivers only, no Adrenalin) seems to be working for me so far. I’m not much of a good sample at the moment.
Hopefully you can get your machine back to full spec soon.
Another FW13 AMD user here with persistent, frequent BSODs / random freezes. I’ve not looked into what’s going on because it’s the first Windows machine we’ve had in the house since, uh, about Win 2k. It’s freezing under fairly low load conditions (running Libre office, editing a single page document, scrolling). It’s reached the point of making the laptop nearly unusable, since today it’s frozen twice in a 5 minute period (freeze - hard reboot - BSOD - reboot and apparently working…).
Framework really need to respont to this, urgently. My wife’s not into computers and bought into the framework concept coming from the Mac ecosystem and she is not happy right now.
Through extensive testing and process of elimination with support, I believe a single stick of RAM is faulty in my laptop. I am still testing as I want to ensure that slot 0 and slot 1 of the mainboard do not have an issue and it’s just a specific stick of RAM.
Some helpful tools
View reliability history - This is quicker/easier to show history of crashes/errors than digging through Event Viewer on Windows
Interestingly neither Memtest86 or Windows Memory Diagnostic found any issues. Memtest86 does not work well with the screen, if left alone for long enough it will auto run and you can later examine the file written back to the USB drive to see the result.
Edit: To clarify, I’ve been running the system for 5 days on a single stick of ram, with the “bad” stick removed, swapping which slot the “good” stick is in 2 days ago. I have had no crashes, using the normal workloads. Drivers are the Windows 11 and Framework Driver bundle. Bios is 3.03
Well then, let’s see what RAM everyone is using.
7840u
Crucial 5600 2x16 CT2K16G56CS5
windows 11 22631.2861
AMD 23.12.1
Slot 1: USBC
Slot 2: HDMI
Slot 3: USBA
Slot 4: USBC
Haven’t used the laptop much this week, so no blue screens for me, but am starting to narrow down my audio issues. Seems to be a sleep problem (thinking drivers) as when I hibernate, it fixes them.
Unrelated, but does anyone else find it funny that when you install AMD’s driver package and go to search it by bringing up start (win key) and searching “amd” the only thing you get is “AMD bug report tool”? I had to manually add a shortcut to radeonsoftware.exe to be able to bring their software up in windows search.
Suffered from this issue and removed my HDMI expansion card and replaced it with another USB-C passthrough. Right now I am rolling 3 USB-C expansion cards and a USB-A card.
Since I removed the HDMI expansion card – I have not experienced a blue screen yet. It has been around a week since I removed it. Keeping my fingers crossed.
I am running
Kingston Impact Fury 5600 2x32 KF556S40IB-32
Windows 11 Version 10.0.22631 Build 22631
AMD 23.12.1
My issue was completely resolved upon installing a supported kit, i tried it with the 8gb hynix kit to confirm which is like $26 on ebay. It you want to roll the dice on that i learned my ram was the issue after testing it in another laptop. Good Luck guys!
Just a note on DPC_WATCHDOG_VIOLATION specifically. As you can see from the assortment of debug paths and resolutions from this thread, we haven’t seen any single root cause, but rather a catchall in Windows for any of a number of possible root causes. If you are running into this, please reach out to support.
Note that because there isn’t a single root cause, this makes the debug process require more steps with support than most other types of issues. We start with the least burdensome steps (which are also the ones that generate the least waste), and then go by process of elimination through each possible cause. This means we start with software and driver checks, then checking reseating memory and testing with one stick at a time to determine if one is bad or a socket on the mainboard is bad. The last step if none of those were the root cause is a Mainboard swap.
Hey NRP. This is the first time anyone from Framework has said anything outside of support about this very obvious issue. Across Reddit, Microsoft Answers and this community, countless people are having this issue and quite a lot are yet to reach out to support.
Do you not feel that it’s time Framework made a proper public acknowledgement of this issue? Even if it’s to say “listen, we know this is a thing, we don’t know yet what is causing it, but we’re working on it”
Consumers deserve all the information they need to make informed purchasing decisions before choosing an AMD configuration, and many, me included, aren’t too happy with essentially being beta testers. My work commitments don’t afford me this luxury and I use my Framework laptop for work purposes.
I’m fully behind Framework and your mission, but transparency is key and only fair.
In my cases, all has happened under smallish loads. Browsing, Microsoft Word, Discord and when using Microsoft Phone Link to do some business expense claims
Can’t say if that is a cause or not since that’s the main use cases for the laptop is browsing, word documents, social use, or maybe web/photo editing and media consumption for when I’m on the move.
I haven’t used the laptop this weekend, it has been sat on sleep, so I’ve no updates since last post.
Of course, given the nature of my problem, (aka no consistent steps to reproduce) I managed to trigger it again today, with just my “good” stick of ram in the system. I am going a bit crazy on this issue, to the point that I broke out WinDbg and cracked open the memory.dmp from this latest crash.
SYMBOL_NAME: amdacpbus+6c53a
MODULE_NAME: amdacpbus
IMAGE_NAME: amdacpbus.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 6c53a
FAILURE_BUCKET_ID: 0x133_DPC_amdacpbus!unknown_function
OS_VERSION: 10.0.22621.1
BUILDLAB_STR: ni_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {79fc37ef-989d-4595-4c29-e34964a8cc54}
Followup: MachineOwner
---------
3: kd> lmvm amdacpbus
Browse full module list
start end module name
fffff800`8f190000 fffff800`8f753000 amdacpbus (no symbols)
Loaded symbol image file: amdacpbus.sys
Image path: \SystemRoot\System32\DriverStore\FileRepository\amdacpbus.inf_amd64_22f1166a5ad4ea7f\amdacpbus.sys
Image name: amdacpbus.sys
Browse all global symbols functions data
Timestamp: Sun Aug 6 23:14:42 2023 (64D08BD2)
CheckSum: 005CCADE
ImageSize: 005C3000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
3: kd> dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK fffff8004a71d340
Symbol nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK not found.
3: kd> dt Wdf01000!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK fffff8004a71d340
+0x000 Signature : 0xaebecede
+0x004 Revision : 1
+0x006 Size : 0x10
+0x008 DpcWatchdogProfileOffset : 0x88a8
+0x00c DpcWatchdogProfileLength : 0x8200
The driver that appears to to have been involved in the chain is loaded by AMD Audio CoProcessor. (Thanks Device Manager for finally having a View by Driver option).
At the time of this crash I had an HDMI expansion card installed. No external devices installed. On battery power. Watching video via Firefox.
As requested by @nrp , I do have a ticket going with support going (and it’s getting long). I do want to keep providing others in the thread updates about my findings (especially final resolution) as this one seems rather tricky.
Edit:
For @lane_ftw
7840U
Ram: Framework 16gb DDR5-FRANRM0002 / 0016G-BFW
Windows 11 22631.2861
AMD 22.40.80.03
Slot 1: USB C
Slot 2: USB A
Slot 3: USB C
Slot 4: HDMI
