# Radeon AI PRO R9700 x2 — card drops to Code 31 > Source: > Published: 2026-08-19 14:03:26+00:00 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.