Radeon AI PRO R9700 x2 — card drops to Code 31

AMD's Radeon AI PRO R9700 x2 graphics cards fail with Windows error Code 31 under Adrenalin drivers 26.5.1, 26.6.1, and 26.7.1, but remain stable for over 20 hours with driver 26.3.1, according to a Level1Techs forum user. The user tested three motherboards from two vendors, including ASUS WRX90, and five bugchecks in C:\Windows\Minidump all name amdkmdag.sys, indicating AMD's driver is at fault. The issue appears to be a device bring-up defect in AMD's Windows driver, not an idle bug, as one dump fired 11 seconds into boot.

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 https://forum.level1techs.com/u/wendell video https://www.youtube.com/watch?v=zcwGcbLNVJU&t=673s 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 the 230xx 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 x3 0xA0000001 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.