RX 9070 XT: Vereinzelte Driver Timeouts nach behobenem RAM-Defekt – Hardware oder Software?

[Leif2602]

1. Nenne uns bitte deine aktuelle Hardware:
(Bitte tatsächlich hier auflisten und nicht auf Signatur verweisen, da diese von einigen nicht gesehen wird und Hardware sich ändert)

• Prozessor (CPU): AMD Ryzen 7 9800X3D
• Arbeitsspeicher (RAM): Patriot Viper 32 GB (2×16 GB) DDR5-6000 CL30 (läuft aktuell mit JEDEC 4800 MT/s, EXPO deaktiviert)
• Mainboard: MSI MAG B650 Tomahawk WiFi
• Netzteil: Corsair RM850x
• Gehäuse: Lian Li LANCOOL 216 RGB
• Grafikkarte: ASUS Prime Radeon RX 9070 XT OC White
• HDD / SSD: WD Black SN850X 1 TB
• BIOS: nicht aktuellste Version
• AMD-Treiber: 25.10.30.02-250925a-420529C
• AMD-Chipsatztreiber: 8.05.04.516
• Betriebssystem: Windows 11 Home 25H2
• BIOS Version: BIOS E7D75AMS.1O0 (Build 24.06.2025)

2. Beschreibe dein Problem. Je genauer und besser du dein Problem beschreibst, desto besser kann dir geholfen werden (zusätzliche Bilder könnten z. B. hilfreich sein):

Hallo zusammen, Ich hoffe, ihr könnt mir bei der Einordnung meines Problems helfen.


Ende Mai habe ich meinen PC neu zusammengebaut. Anfang/Mitte Juni traten einmalig kurze Artefakte beim Laden in Escape from Tarkov sowie beim Aktivieren von Raytracing in Silent Hill 2 Remake auf. Beide Spiele liefen danach sofort wieder normal und die Artefakte sind nie wieder aufgetreten.


Direkt danach habe ich einen ca. 30-minütigen OCCT-VRAM-Test mit ca. 92 % VRAM-Auslastung durchgeführt. Der Test verlief ohne Fehler.


Am 19.06. erhielt ich in DOOM: The Dark Ages beim Ändern der Grafikeinstellungen einen AMD Driver Timeout. Danach lief das Spiel wieder normal.


Anfang Juli bekam ich einen MEMORY_MANAGEMENT_BSOD. Die Windows-Speicherdiagnose meldete einen Hardwarefehler und es stellte sich heraus, dass mein RAM defekt war.


Am 09.07. habe ich den RAM gegen ein neues Kit ersetzt. Seitdem sind keine MEMORY_MANAGEMENT-BSODs mehr aufgetreten.


Am 24.07 erschien im Zuverlässigkeitsverlauf ein LiveKernelEvent Code 193 . Während der Nutzung ist mir dabei nichts aufgefallen.
Ich habe den Eintrag erst zwei Tage später beim Kontrollieren des Zuverlässigkeitsverlaufs entdeckt.


Am 30.07. erhielt ich beim ersten Start von Poppy Playtime während eines Alt-Tabs zu HWiNFO erneut einen AMD Driver Timeout. Im Zuverlässigkeitsverlauf erscheint dazu LiveKernelEvent Code 117. Die Minidump wurde mit WinDbg analysiert. Die Analyse zeigt VIDEO_TDR_TIMEOUT_DETECTED (117) mit Verweis auf amdkmdag.sys


Nach einer Neuinstallation des AMD-Treibers mittels DDU tauchten zusätzlich LiveKernelEvent 1A8 und 1B8 im Zuverlässigkeitsverlauf auf. Die beiden LiveKernelEvents traten im Zeitraum der Deinstallation und anschließend Neuinstallation des Grafiktreibers mittels DDU auf. Ob sie damit zusammenhängen, weiß ich allerdings nicht.


Seitdem konnte ich den Driver Timeout trotz mehrerer Versuche (Alt-Tab, HWiNFO usw.) nicht erneut reproduzieren.


Seit dem RAM-Tausch habe ich viele Stunden Cyberpunk 2077, Borderlands 4 und Escape from Tarkov gespielt. Dabei gab es keine weiteren Driver Timeouts, keine Artefakte und keine Bluescreens.

Nachtrag:
Heute ist zusätzlich ein LiveKernelEvent A1000001 aufgetreten, als der PC im Idle auf dem Desktop war. Ich war zu diesem Zeitpunkt nicht am Rechner, daher kann ich nicht sagen, ob es sichtbare Symptome (z. B. kurzer Blackscreen) gab. Der PC ist jedoch nicht neu gestartet und lief anschließend normal weiter.
Die zugehörige AMD_WATCHDOG-Dumpdatei wurde in WinDbg analysiert und zeigt:

• MODULE_NAME: amdfendr
• IMAGE_NAME: amdfendr.sys
• FAILURE_BUCKET_ID: LKD_0xA1000001_amdfendr!unknown_function

Mich interessiert vor allem eure Einschätzung, ob die bisherigen Symptome eher auf einen beginnenden GPU-Hardwaredefekt oder eher auf ein Software-/Treiberproblem hindeuten. Falls ihr weitere Test empfehlen könnt oder ich bestimmte Informationen nachreichen soll, mache ich das natürlich gerne

3. Welche Schritte hast du bereits unternommen/versucht, um das Problem zu lösen und was hat es gebracht?

RAM ersetzt (vorher durch Windows Memory Diagnostic als defekt bestätigt)

Windows Memory Diagnostic nach dem RAM Tausch erneut durchgeführt → keine Fehler

OCCT VRAM-Test (ca. 30 Minuten, 92% VRAM-Auslastung) → keine Fehler

AMD-Grafiktreiber mit DDU vollständig entfernt und neu installiert

SFC ausgeführt → ohne Fehler

Ereignisanzeige überprüft → keine WHEA-Logger-Einträge

Driver Timeout durch Alt-Tab/HWiNFO mehrfach versucht zu reproduzieren → bisher nicht gelungen

 

[Darkling71]

Meine Tipps:

• BIOS des Mainboards aktualisieren, Verbessert in der Regel die Kompatibilität mit dem Arbeitsspeicher, ggf. auch mit der Grafikkarte. Welche BIOS-Version ist denn installiert? Dies lässt mit CPU-Z oder HWiNFO auslesen.
• aktuellen AMD-Chipsatztreiber (8.07.16.1035) installieren ist heute am 30.07.2026 neu erschienen
• aktuellen Grafikkartentreiber installieren, zurzeit die Version 26.7.1, die korrekte Versionsnummer wird in der Adrenalin-Software oder in GPU-Z angezeigt.
• Wird ein Riser-Kabel verwendet, weil die Grafikkarte senkrecht eingebaut ist?

 

[Leif2602]

BIOS-Version ist 1.O0 vom 24.06.2025
Die Installierte AMD Chipset Software ist Version 8.05.04.516, ich werde auf die aktuelle 8.07.16.1035 aktualisieren.
Beim Grafiktreiber ist der aktuelle WHQL-Treiber 26.7.1 installiert.
Ein Riser-Kabel verwende ich nicht.

 

[Darkling71]

Das BIOS würde ich ebenfalls aktualisieren, bei einer folgenden Versionen taucht dieser Eintrag auf: "Optimized with AMD EXPO Technology: Featuring Ultra Low Latency."
Das könnte die Kompatibilität und Stabilität mit deinem RAM auch bei hohem Takt verbessern.

 

[LETNI77]

Falls die iGPU on ist - deaktivieren.

Evtl. auch RAM manuell auf 6000 stellen.

Oder sogar auf 5600.

 

[Alexander2]

Treibertimeouts, wenn man nen Spiel am Zocken ist, wo das Typischerweise halt nicht bekannt ist ... hört sich hart nach instabilem ram an.

 

[Leif2602]

@Alexander2 Der ursprüngliche RAM war tatsächlich defekt (die Windows-Speicherdiagnose hat Fehler gefunden). Ich habe ihn inzwischen ersetzt und betreibe den neuen RAM aktuell mit 4800 MT/s (ohne EXPO). Seitdem sind die Speichertests fehlerfrei und der MEMORY_MANAGEMENT-BSOD ist nicht mehr aufgetreten. Übrig geblieben sind nur einzelne Driver Timeouts bzw. LiveKernelEvents. Würdest du unter diesen Umständen den RAM trotzdem noch als wahrscheinlichste Ursache sehen?

 

[CSOger]

Bring doch erstmal das Bios vom Board auf die aktuellste Version.

 

[Leif2602]

@LETNI77 Danke für die Tipps. Der ursprüngliche RAM war tatsächlich defekt und wurde inzwischen ersetzt. Der neue RAM läuft aktuell ohne EXPO mit den Standardwerten (4800 MT/s). Würdest du unter diesen Umständen trotzdem empfehlen, die iGPU testweise zu deaktivieren oder den RAM auf 5600/6000 zu stellen?

 

[Alexander2]

Würdest du unter diesen Umständen den RAM trotzdem noch als wahrscheinlichste Ursache sehen?

Ja, das habe ich ja geschrieben, das du bereits nen total defekt hattest, wo der ramtest nen Fehler recht schnell gefunden hat habe ich ja gelesen.

@CSOger wie er schon schrieb, bring unbedingt das Bios auf die aktuellste Version. die Update bringen vorallem auch oft was wegen Speicherkompatibilität/stabilität.

 

[Bono35]

Die Ursache für die Treiber Timeouts ist überwiegend, entgegen der hier fälschlich immer gemachten Annahme, nicht der RAM oder "instabiler" Ram. Das Problem wäre ja dann gleichernaßen auf Nvidia Seite auch zu sehen. Es ist aber AMD spezifisch.

Das sind unbehobene Probleme im AMD Treiber und in der Display Engine die rückwirkend bis 2019 zu beobachten sind. Es ist meist das Zusammenspiel aus mehreren High Refresh Displays an einer Karte oder zwei Displays mit unterschiedlichen Refresh Raten über 144/165 hz. Hier hat die Display Engine schlicht Timingprobleme.

Will man bei AMD Karten Driver Timeouts zu 97% ausschließen ist das Folgende zu beachten:

1. Alle Hardwarebeschleunigung in Browsern, Discord und Games Launchern muss ausgeschaltet werden - im Idealfall läuft nur der Launcher der auch für das aktuelle Game benötigt wird - möglichst wenige Hintergrundprozesse die auf die GPU zugreifen

2. Freesync darf im Multi Monitor Betrieb nur auf einem Bildschirm aktiv sein

3. Im Idealfall findet bei Multi Monitor Einsatz beim Gaming kein Videoplayback statt

4. Im Idealfall ist beim Gaming sogar ein ggf. vorhandenes zweites Display aus (Erweiterung aus - Power Button aus)

5. Wenn mehrere Screens im Einsatz beim Gaming dann GLEICHE Refreshrate und nicht über 144hz/165 hz auf Beiden. Sonst kann es eben Timing Probleme geben.

6. Wenn HDR im Einsatz - im Idealfall nur ein Screen aktiv. HDR kann das Problem verstärken

Die Probleme sind ohne einen dedizierten Fix von AMD, welcher voraussichtlich erst mit RDNA 5 kommen wird, vollständig behebbar. Hier ist ein Mix aus Hardware-Eigenschaften und Treiberproblemen in der grundlegenden Architektur der Haupt-Auslöser - vor Allem eben bei Multi-Monitor-Betrieb.

Was NICHT hilft ist MPO abzuschalten oder irgendwelche Timings in der Registry manuell zu verändern. Auch hilft das Abschalten von EXPO bei wissentlich funktionalem RAM nichts. In seltenen Fällen kann Unvervolting das Problem lindern bei Reduktion der maximalen Taktrate (bei OC Karten) auf die AMD-Stock Werte - das aber auch nur bedingt.

 

[Alexander2]

Wie schon geschrieben, einmal kurz umhören ob es bei den Betroffenen Spielen bekannte probleme gibt → wenn nicht ist es mit höchster wahrscheinlichkeit nen RAM Problem, auch wenn @Bono35 das gerne Auf Treiberqualität schieben will.
Nur macht man ja deswegen der vergleich, ob da gerade Probleme bekannt sind...

Ergänzung (Heute um 14:11)

Im Idealfall findet bei Multi Monitor Einsatz beim Gaming kein Videoplayback statt

Mach ich andauernd überhaupt kein Problem.

Ergänzung (Heute um 14:11)

Im Idealfall ist beim Gaming sogar ein ggf. vorhandenes zweites Display aus (Erweiterung aus - Power Button aus)

Hab ich dauernd an den 2ten Moni, das ist überhaupt kein Problem.

Ergänzung (Heute um 14:12)

Das sind unbehobene Probleme im AMD Treiber und in der Display Engine die rückwirkend bis 2019 zu beobachten sind. Es ist meist das Zusammenspiel aus mehreren High Refresh Displays an einer Karte oder zwei Displays mit unterschiedlichen Refresh Raten über 144/165 hz. Hier hat die Display Engine schlicht Timingprobleme.

Hm, hab ich aktuell auch komplett Problemloß im Betrieb. 60Hz und 240Hz und alles läuft dufte.

Ergänzung (Heute um 14:13)

Wenn HDR im Einsatz - im Idealfall nur ein Screen aktiv. HDR kann das Problem verstärken

Hab ich sogar auch dauerhast an

Ergänzung (Heute um 14:15)

In seltenen Fällen kann Unvervolting das Problem lindern bei Reduktion der maximalen Taktrate (bei OC Karten) auf die AMD-Stock Werte - das aber auch nur bedingt.

Wenn das nötig wäre also beim undervolting und zum erfolg führt, dann hat man vermutlich ein Problem mit deinem Netzteil, wenn auf der anderen Seite ein zurückdrehen des Taktes zum Erfolg führt kann es ebenso vom Netzteil her rühren, oder auch einer defekten Grafikkarte.. kommt vor.


Ich schreib ja nicht, das die Treiber immer Bugfrei sind (egal bei welchem Hersteller) Aber die hier als so allgemein anzutreffenden Probleme - angeblich kann ich so garnicht nachvollziehen.

 

[Bono35]

Ich schiebe das nicht auf die Treiberqualität. Es sind bekannte Probleme die AMD seit Jahren hat. Das Einzige was eben machbar ist, ist das Beachten einiger Aspekte. Die Timeouts treten so oder so spontan auf - vor Allem eben bei Multi Monitor Betrieb. Das lässt sich nicht ohne Fix von AMD vermeiden. Das hat nichts mit "Qualität" der Treiber zu tun sondern schlicht von strukturellen Eigenarten des Konstruktes Display-Engine/Treiber. AMD macht hier hardwareseitig halt Dinge anders als Intel und Nvidia, was leider oft zu Lasten der Stabilität geht. Sämtliche AMD-Support-Foren sind voll mit den Timeout Problemen - auch stärker frequentierte Plattformen wie Reddit - und das seit RDNA1 Release 2019.

Da die Timeouts "Random" und teils auch anwendungsabhängig auftreten, kann es durchaus sein, dass in Einzelfällen diese weniger häufig auftreten. Was aber genrell falsch ist, ist hier pauschal auf den RAM zu verweisen. Dies ist schlicht fachlich nicht korrekt - da insbesondere DDR6 6000 mittlerweile bei Intel und AMD stabil laufen. Die Probleme treten ja nun aber auch mit noch stabilerem DDR4 auf. Von daher hat das mit dem Ram in 98% der Vorfälle eben nichts zu tun.

Es ist empfehlenswert sich hier in den AMD Support- und Developer-Foren einzulesen. Du kannst zudem bekannte und bestehende Probleme (vorrangige Gründe siehe meinen Post) aufgrund eines milden Einzelfalles bei Dir nicht wegdiskutieren. Man muss das global betrachten. Spiel mal mehrere Stunden am Stück Diablo 4- dann weisste was ich meine. Aber nicht erschrecken, wenn nach zwei Stunden die Screens schwarz werden. Die TImeouts habe ich mit dem Game noch auf jeder AMD RDNA GPU reproduzieren können. Und das hat nichts mit D4 zu tun - trotz bekannter Memory-Leaks. Besonders schlimm wirds dann mit der Unreal Engine 4 - das ist Hit or Miss mit AMD Karten - aber auch seit Jahren bekannt. UE5 ist milder - aber auch ein Kandidat für Timeouts.

Und Nein - AMD Karten sind nicht schlecht - wäre mein System jobseitig nicht Mission Critical hätte ich auch eine 9070XT - nur verhalten die sich halt mitunter zickig in einigen Szenarien.

 

[Alexander2]

Ok, Leute dann wechselt von Windows zu Linux, ixh kann kein einziges der Probleme mit AMD Radeon Grafikkarte nachvollziehen.

Ich bleibe dabei, es ist mit höchster warscheinlichkeit ein RAM instabilitätsproblem.

 

[Bono35]

Naja - KANN man machen - bedeutet aber Performanceverlust bis zu 20% und Einschränkungen in der Softwarekompatibilität - respektive alles mit Anti-Cheat kannste dann vergessen. Das ist keine Allerweltslösung leider.

Und ja - die treiberseitigen Probleme, welche die Timeouts angeht umgeht Linux in der Tat. Nur laufen dann eben keine Adobe oder Boris FX Programme, keine VST Plugins und kein Vegas Pro.....als Beispiel. Die meisten Audio Interfaces funktionieren unter Linux nicht -Streamdecks funktionieren nur eingeschränkt - das ist also nix für Jedermann.

 

[Alexander2]

Spiel mal mehrere Stunden am Stück Diablo 4

Das habe ich auch gemacht, viele Stunden, auch gerade mit meinem Bruder zusammen. viele Wochenenden. und absolut Problemloß. auch mit HDR (explizit im Spiel aktiviert zwischendurch)

Ergänzung (Heute um 14:28)

Performanceverlust bis zu 20%

Das ist so Falsch.
Mit Radeon mist du Pi mal Daumen auf Augenhöhe. gibt mal nen Titel, der Langsamer ist, mal nen Titel, der schneller ist.

Edit:
Ach und mein Bruder hatte zu der zeit noch unter Windows gezockt, mit der gleichen Radeon Karte, der hatte da 0 Probleme.

 

[Bono35]

Die Performance-Unterschiede kann man ja in jedem Benchmark Video zu dem Thema nachschauen. Da muss man bitte nix schönreden was eben Tatsache ist. Es sind 10-20% Verlust zu Windows. Das wäre zu vernachlässigen, wenn eben die Softwarekompatibilität und die Hardwarekompatibilität unter Linux identisch mit Windows wäre für kommerzielle Produkte. Das ist aber nicht der Fall. Leider. Ich hoffe das ändert sich noch. Denn AMD Karten laufen unter Linux stabiler als unter Windows. Solange Linux Windows in JEDEM Aspekt nicht vollständig ersetzen kann, ist das eben nur was für Edge Cases oder eben reine Gamer die nicht kompetitiv spielen oder Spiele ohne kernelbasierten Anti-Cheat spielen.

Meine Aussage zu D4 bezog sich auf Windows - nicht auf Linux.

 

[Alexander2]

VST Plugins

das ist übrigends falsch, hatte mich etwas gewundert, hab ich grad mal nachgeschlagen.
Adobe Software kannste knicken, das stimmt.

Ergänzung (Heute um 14:31)

Da muss man bitte nix schönreden

Richtig, das ist nicht nötig. nur Radeon ist eben nicht Nvida, da braucht man nichts schönreden.

Ergänzung (Heute um 14:32)

Meine Aussage zu D4 bezog sich auf Windows

Exakt, hab ich ja zu deinem verständnis Ergänzt. in #16, das edit.

Ergänzung (Heute um 14:33)

Es sind 10-20% Verlust zu Windows.

eben nicht, so pauschal ist die Aussage falsch.

Ergänzung (Heute um 14:34)

Solange Linux Windows in JEDEM Aspekt nicht vollständig ersetzen kann

Klar, du bis kein Linux Nutzer, aber du liegst halt auch Falsch in einigen Punkten und diese Anforderung ist komplett überzogen. Würde ich von Windows das selbe Fordern, das ich von Linux gewohnt bin ist es demnach ebenso unnutzbar.

 

[Bono35]

VST PLugins die eine Registratur brauchen wie Native Instruments oder Aplitube (Amp-Sim) laufen nicht unter Linux. Es gibt zudem keine brauchbare DAW unter Linux - nein - Reaper ist nicht brauchbar. Ich rede hier halt von Musikproduktion und nicht von Open Source Zeugs.

DIe Performanceverluste beziehe ich auf AMD UND Nvidia. Die sind global. Das liegt schlicht am Proton-Übersetzungslayer. Wie gesagt - 10-20% wären verschmerzbar für die Stabilität und die sind reproduzierbar - schau da mal bei den Profis von Hardware Unboxed rein. Das Nvidia treiberseitig unter Linux problematisch ist, ist mir bekannt. Unter Windows ist Nvidia dennoch stabiler - wenngleich ich deren Produkte nur ungern wegen derer Unternehmenspolitik unterstütze.

Wenn aber selbst ein Focusrite Interface nicht läuft - hilft das wenig. Und die laufen nicht unter Linux. Es gibt nichtmal brauchbare ASIO Treiber unter Linux. Das ist auch nur ein Beispiel.


Und natürlich bin ich Linuxanwender - nur hilft eben bei Mixed-Worflows mit kommerzieller Software und Hardware im Einsatz Linux wenig. Linux ist kein Allheilmittel wenn man mehr macht als nur Gaming mit dem Rechner. Es gibt schlicht Software und auch Hardware die schlicht unter Linux nicht funktioniert. Da bin ich wahrlich nicht der Einzige der damit zu kämpfen hat. Hat ja Gründe warum Windows über 90%& Marktanteil im Desktop-Segment hat.

Ich nutze Linux sehr gerne - u.a. fürs Homelab (TrueNas/HomeAssistant) oder für Laptops wo nur Internet und Office Workloads gebraucht werden respektive Remote Desktop Anwendungen. Nur für einen "Mission Critical" Rechner oder dann wenn z.b. aktuelle Streaming/Audio Hardware oder eben kommerzielle Plugins zum Einsatz kommen die eben eine Registratur-App benötigen (Siehe Native Instruments oder IK Multimedia als Beispiel) - hilft Linux halt nicht weiter. Selbst ein kleiner Freizeitstreamer würde hier mit Cachy OS oder Bazzite schon an die Grenzen kommen. Leider. Ich hoffe das sich das noch ändert.

Brücke wieder zu AMD Karten unter Windows: Man kann sie stabiler betreiben - wie gesagt zu 97% ohne die Timeouts - wenn man eben die von mir genannten Dinge im Ansatz beachtet. Sonst muss man eben damit leben, dass diese Timeouts random daher kommen - und auch von Treiberversion zu Treiberversion mal mehr mal weniger häufig auftreten. Ist kein Hardwaredefekt, kein Problem mit dem RAM - sondern schlicht eine Eigenschaft wie AMD Karten unter Windows funktionieren.

 

[Alexander2]

VTSP PLugins die eine Registratur brauchen wie Native Instruments oder Aplitube (Amp-Sim) laufen nicht unter Linux

Ah, jetzt kommt eine Einschränkung auf eine Spezifische eigenheit, nur vorher hast du geschrieben es gehen keine VST Plugins. das ist falsch.
Was auch immer diese Einschränkung bedeutet, ich stecke da nicht drin.

Es gibt zudem keine brauchbare DAW unter Linux - nein - Reaper ist nicht brauchbar.

wieder so nen alles oder garnichts argument (Edit: --offensichtlich ist dieses edit nicht für bono -- wer sich wirklich dafür interessieren sollte, der schaut sich halt einfach spezifisch danach um welcher DAWs gerade unter Linux verfügbar sind und ob die zusagen, Dieses ASIO Argument ist natürlich auch an den Haaren herbeigezogen und spricht für unwissenheit. es gibt Low Latency Audio für Linux, ggf bei bedarf einfach informieren)

DIe Performanceverluste beziehe ich auf AMD UND Nvidia.

Aha, alles ein Brei.. warum soll man noch gleich mit dir überhaupt argumentieren, wenn du nicht differenzieren kannst?

Natürlich gibt es kein ASIO unter Linux, das ist nen WIndows ding. Du machst dich schon etwas lächerlich.

Ergänzung (Heute um 14:44)

Also, nochmal zum eigentlichen Thema. Ich würde also entweder an den Rameinstellungen manuell anpassen und testen, oder anderen RAM Probieren.
Sich andren Ram zum testen Leichen zu können wäre natürlich zu bevorzugen statt direkt kaufen zu müssen