Follow-up post for the R9700 thread. Written in the operator’s voice, no em dashes.
Quick follow-up.
I thought it was the motherboard, I mean I guess it could still be….. I disabled CSM, disabled USB4, no change. Swapped in a brand new ASUS WRX90: same fault. Last ditch, moved everything over to an
Three motherboards across two vendors, identical issue, so I stopped thinking it was the moterboard and put my first first ASUS WRX90 back in.
I rewatched @wendell video to see if I could find any clues to what version of the driver he was running with the 4x R9700s on Windows, so I took a shot in the dark and installed 26.3.1, roughly around the time his video was release
It’s been stable ever since. Neither R9700 has dropped to code 31. Currently sitting at 20+ hours of uptime with both compute cards headless and idle, which is the condition that used to kill them inside 20 minutes.
At this point I’m waiting for AMD to release a newer driver than 26.7.1 to see if that resolves the issue. I’m also thinking of reaching out to AMD through some of my industry contacts but my pool is small there.
BELOW IS FROM THE ASSISTANCE WITH AI! (Claude)
Check the Driver Store version, not the marketing version. It’s what
(Get-CimInstance Win32_VideoController).DriverVersion
reports:
| Adrenalin | Driver Store version | Result |
|---|---|---|
| 26.7.1 | 32.0.31035.1003 |
|
| faults | ||
| 26.6.1 | 32.0.31019.2002 |
|
| faults | ||
| 26.5.1 | 32.0.31007.1017 |
|
| hard crash 14 minutes after install | ||
| 26.3.1 | ||
32.0.23033.1002 |
||
| 20+ hours clean, identical config |
26.3.1 is the last release of the 230xx branch. 26.5.1 is the first of 310xx. There is no
310xx
release I’ve tried faults, including the230xx
release is fine.Same machine, same board, same BIOS, same headless topology, same USB4 state for all of these. The
only variable that moved was the driver.
Five full bugchecks in C:\Windows\Minidump
, every one naming amdkmdag.sys
:
0x116 VIDEO_TDR_FAILURE
x30xA0000001
x2That second code is the vendor-defined range, which means AMD’s driver called KeBugCheckEx
itself, deliberately, having decided something was unrecoverable. Windows doesn’t do that on a
driver’s behalf.
The livedumps are VIDEO_MINIPORT_FAILED_LIVEDUMP (0x1b0)
with STATUS_UNSUCCESSFUL
. That’s the
display miniport failing to bring up a device that is provably healthy: a card sitting in code 31
still reports PCIe x16 5.0 @ x16 5.0
and answers config space reads.
Worth noting which sub-code you get, because it isn’t the same on every version:
Arg1 = 1, Add device failed
Arg1 = 2, Start device failed
Same NTSTATUS, one PnP phase apart. On 26.5.1 the driver gets past attaching to the device node and
dies at IRP_MN_START_DEVICE
instead. One defect showing up at two adjacent points in the same
device bring-up sequence.
And one of those 26.5.1 dumps fired 11 seconds into a boot. That’s normal boot enumeration, not
idle. So I’d stop calling this an idle bug. It looks more like a device bring-up defect that idle
happens to expose, because idle forces a re-start that boot would otherwise only do once.
Five kernel level records, five naming AMD’s code. It isn’t ambiguous.
The fair qualifier is that it’s AMD’s driver on Windows specifically. The fault lives where their
driver meets dxgkrnl
’s PnP and power model. Linux has no dxgkrnl
, which is exactly why the same
silicon ran ROCm for weeks without a hiccup. Microsoft owns half the interface, but the code that
fails is AMD’s.
The release notes are no help. 26.5.1 lists two game fixes and nothing else. AMD doesn’t document idle or power management internals.
But look at the driver package:
amdkmdag.sys 112,456,720 bytes
That’s 112 MB, which is not a kernel driver’s worth of code. On Windows AMD embeds the GPU’s own firmware inside amdkmdag.sys rather than shipping separate blobs the way Linux does in
linux-firmware/amdgpu
. There are no mes_*.bin
or smu_*.bin
files anywhere in the package because they’re compiled in.So changing Adrenalin version also changes the microcode loaded onto the card at init. What differs between 26.3.1 and 26.5.1 may not be driver code at all.
The piece I’d look at is MES, the MicroEngine Scheduler, the on-GPU firmware that manages queue scheduling and hands off to power management. AMD has publicly acknowledged an RDNA4 MES firmware bug causing abnormal idle behaviour after compute workloads, with a Linux side workaround and new firmware promised. That firmware ships per driver release. My fault is an RDNA4 card, idle, after compute work, failing to come back. Same shape.
Candidate, not proof. I can’t disassemble firmware out of a 112 MB signed binary and neither can anyone outside AMD.
Adrenalin 26.3.1, and block Windows Update from replacing it:
Settings > System > About > Advanced system settings > Hardware > Device Installation Settings > No.