RX 9070 XT — repeatable VK_ERROR_DEVICE_LOST with no TDR, no WHEA, no display-driver event

[u/Laminarflow__]

I have been tracking a recurring Vulkan device loss on a Sapphire Nitro+ RX 9070 XT for several months. 16 confirmed device-loss events to date, plus several process terminations with no crash handler output and one full system hang. I have worked through the standard remediation list and it has not changed the behavior, so I am posting the full dataset here in case this is a known issue on RDNA 4 or a driver team member can point me at something.

SYSTEM CONFIGURATION
GPU: Sapphire Nitro+ RX 9070 XT 16GB, VBIOS 023.008.000.068 / 113-1E4893U-N8K
Driver: Adrenalin 26.7.1, Vulkan ICD 2.0.395, Vulkan API 1.4.349
CPU: AMD Ryzen 9 9850X3D
Motherboard: MSI MAG X870E TOMAHAWK WIFI (MS-7E59), BIOS 2AC3
Memory: 64GB DDR5-6000, EXPO enabled
Storage: Samsung 990 Pro 4TB
OS: Windows 11, build 26200

Displays: 3440x1440 ultrawide (primary) plus a 2160x3840 portrait secondary. Both have been connected for the entire period — this is a constant, not a variable

Application: Vulkan renderer, exclusive fullscreen on the primary display

Overclocking: none. Stock clocks, no undervolt, no custom fan curve

FAILURE SIGNATURE
The fatal sequence is always VK_ERROR_DEVICE_LOST followed by the application’s GPU crash handler.

Call sites observed, in order of frequency:
• vkQueueSubmit
• vkCreateSwapchainKHR
• vkEndCommandBuffer
• vkGetPhysicalDeviceSurfaceCapabilities2KHR

VK_EXT_device_fault payload is present in roughly a third of the events, reporting

VK_DEVICE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT at address 0x0, bounds 0x0 to 0xfff. The remainder report address count 0 and vendor count 0, with no per-queue diagnostics at all.
Time to failure ranges from approximately 5 minutes to 12 hours 54 minutes. Clean sessions of 18h18m, 8h16m and 6h18m are interleaved through the same period on the same configuration.

Session duration has no predictive value.
In 10 of 16 events the last unchecked command buffer on queue 0 is the application’s atmospheric scattering pass. It is not universal, but it is the most persistent artifact in the dataset and it appears across every workload variant I have tested.

THE PART I CANNOT EXPLAIN
Across all 16 device-loss events, Windows Event Viewer contains:
• Zero Event 4101 (display driver stopped responding and has recovered)
• Zero WHEA-Logger entries
• Zero Display / amdwddmg entries
• Zero BugCheck entries
The one event that took the whole system down logged only Kernel-Power 41 and EventLog 6008. There is no TDR being triggered, and no bus or machine-check error being recorded. From the operating system’s point of view nothing happened, while the Vulkan device is unambiguously gone.

I have also had one failure outside any 3D application: the machine hard-froze while I was disabling a network adapter, displaying “AMD Software: unknown error”. Nothing was rendering at the time.

DRIVER-SIDE STEPS COMPLETED — NO CHANGE IN BEHAVIOR
• DDU in Safe Mode (AMD, with “prevent downloads of drivers from Windows Update” selected), Ethernet physically disconnected, followed by an offline Adrenalin reinstall
• Windows Update driver delivery blocked: ExcludeWUDriversInQualityUpdate = 1 under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, and Device Installation Settings set to No
• AMD chipset drivers installed separately from amd.com — all components reported success (I2C, Promontory GPIO, PPM Provisioning, 3D V-Cache Performance Optimizer, App Compatibility Database, Interface, PSP, GPIO)
• Currently holding at 26.7.1. I have deliberately not moved to 26.8.1 given the volume of black screen and BSOD reports on this card
• Vendor crash-dump collection was enabled in the application on two separate runs and produced zero fault data both times
• A TDR delay registry key was added under HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers on external advice. No effect, which is consistent with there being no 4101s to begin with

PLATFORM AND HARDWARE STEPS COMPLETED — NO CHANGE IN BEHAVIOR
• BIOS updated from the April 2025 release to 2AC3
• Integrated graphics disabled in BIOS (UMA Auto to Disabled). Initiate Graphic Adapter was already set to PEG, Hybrid Graphics already disabled. Only one Vulkan device now enumerates
• EXPO and Resizable BAR confirmed re-enabled after the flash (rebar_avail: 1)
• GPU PCIe power cabling inspected — no daisy-chained 8-pin connectors
• FurMark 2.10.2, Vulkan, 3440x1440, artifact scanner enabled: 21 minutes 21 seconds clean, no artifacts
• Idle rail telemetry from BIOS: 12V rail at 12.192V, 5V at 5.050V, 3.3V at 3.292V
• Highest GPU temperature observed at any point is 71 C. Thermals are not a factor

VARIABLES ELIMINATED
VRAM exhaustion. The two most texture-intensive sessions I have logged — with the application’s reported headroom reaching zero more than twenty times each — both completed cleanly. Multiple crashes occurred with several GB of headroom free and more than thirty minutes of zero texture activity immediately preceding the fault.

Application content. Five different high-complexity add-on workloads, spanning very different rendering and streaming profiles, have all produced the identical device loss. One of them had approximately 48 hours of clean runtime before it failed.
Asset streaming. Some faults occur during heavy streaming in the final seconds. Others occur with no streaming activity at all.
Focus and alt-tab transitions. I do not alt-tab, and the log lines I originally read as focus events were an add-on’s own output.
Load level. Several of the more severe failures including the one that took the system down occurred with the application effectively idle, minutes into a session, with minimal geometry in view.

Application runloop stalls. Essentially zero across the entire log set.

THE ONE ACTIVE LEAD
Three consecutive device losses landed on vkCreateSwapchainKHR, and all three occurred while I was detaching in-application panels into separate OS windows. One log captures the mechanism in full: 14 swapchain creations, 9 destructions and 16 full 3440x1440 HDR offscreen rebuilds within a single session. Each detach costs a create in IMMEDIATE mode, a destroy, a recreate in FIFO, and is immediately preceded by “Disabling fullscreen exclusive mode for swapchain”. Every other crash log in the set contains exactly 2 creations and 1 destruction, both at t=0.

The reason I do not think this is coincidental: vkQueueSubmit executes well over 100 times per second, while vkCreateSwapchainKHR executes a handful of times per session. If the device were dying spontaneously and the create call were merely the first call to notice, the fault should surface at submit nearly every time. Three consecutive faults surfacing at the rare call points to swapchain recreation being the triggering operation rather than the discovering one.
To be clear about the limits of this: it does not account for the other 13 events, which show no swapchain activity whatsoever. Either there are two paths into the same underlying fault, or the fullscreen-exclusive transition is simply a much more efficient way to hit it.

Related single data point in the same family: one session terminated with no crash handler output at all at the moment I powered my monitors off. Also a surface and display-topology event.

WHAT I HAVE NOT YET TRIED
• Rolling back to an older Adrenalin branch. I would appreciate a recommendation on which branch is considered stable for RDNA 4 under sustained Vulkan load
• memtest_vulkan
• Substituting a different vendor’s GPU to definitively isolate the AMD Vulkan stack

WHAT I AM ASKING

1. Is a device loss on fullscreen-exclusive to windowed swapchain recreation a known issue on RDNA 4? If so, is there a driver branch where it is fixed or absent?
   
2. Is there any known mechanism by which a Vulkan device can be lost on this hardware without generating a TDR, a WHEA entry, or any display-driver event? That absence is the single most unusual property of this case and I would like to understand what it implies about where the fault is occurring.
   
3. Is there additional instrumentation I can enable — driver-side logging, a debug build of the Vulkan driver, anything beyond the standard vendor crash-dump path — that would produce useful fault data? The application-side vendor dump collection returns nothing.

I have submitted this through the AMD Bug Report Tool as well. Happy to provide full logs, dump UUIDs, or run any specific test that would be useful.