Wer eine Radeon-Grafikkarte mit AMDs Adrenalin-Software betreibt, sollte einen Blick auf die Schreibaktivität seiner SSD werfen. Auf manchen Systemen schreibt der Radeon-Treiber über den Prozess atieclxx.exe, das „AMD External Events Client Module“, pausenlos Daten auf das Systemlaufwerk – auch dann, wenn der Rechner gar nichts zu tun hat. Nutzer berichten in AMDs Community-Forum von 0,3 bis 2 MByte pro Sekunde, auf Reddit ist von bis zu 5 MByte/s die Rede. AMD hat den Fehler schon am 21. Oktober 2026 als echtes Problem anerkannt. Breit bekannt wurde er aber erst Anfang November durch einen Warnhinweis im Reddit-Forum r/pcmasterrace und die anschließende Berichterstattung.

Welcher Dienst schreibt und welche Treiber betroffen sind

Der Prozess gehört zum Windows-Dienst „AMD External Events Utility“, der mit dem Grafiktreiber installiert wird und aus einem Server- (atiesrxx.exe) und einem Client-Teil (atieclxx.exe) besteht. Nach der Beschreibung eines Nutzers im AMD-Forum reagiert der Dienst unter anderem auf das An- und Abstecken von Monitoren und setzt monitorbezogene Einstellungen um; eine ausführliche Beschreibung von AMD selbst haben wir nicht gefunden.

Die ersten ausführlichen Berichte im AMD-Forum stammen von Anfang Juli 2026 und betreffen den Treiber 26.6.4. Seitdem melden Nutzer das Verhalten auch für 26.7.1, 26.8.1, 26.9.1, 26.9.2 und 26.10.1 – unter Windows 10 wie Windows 11 und auf Karten von der RX 580 bis zur RX 9070 XT. Ein Nutzer gibt an, mit 26.2.2 sei das Problem nicht aufgetreten, ein anderer nennt 25.12.1 als unauffällig. Ein Teilnehmer zeichnete mit Process Monitor in zehn Minuten rund 600 MByte geschriebene Daten auf, also etwa 1 MByte/s. Nicht jedes Radeon-System ist betroffen. Auffällig: Mehrere Nutzer berichten, dass die Last verschwindet, sobald sie Resizable BAR (bei AMD „Smart Access Memory“) im BIOS abschalten.

Am 21. Oktober meldete sich AMDs Community-Betreuer im Forum-Thread zum Treiber 26.10.1. Er installierte die Version nach eigenen Angaben selbst unter Windows 11, sprach anschließend von einem „genuine issue“ (echten Fehler) und schrieb, AMD untersuche ihn mit dem Ziel, ihn in einer künftigen Treiberversion zu beheben. Die Release Notes des Treibers 26.10.2 vom 30. Oktober erwähnen das Problem nicht. Anfang November äußerte sich ein weiterer AMD-Mitarbeiter auf Reddit: Laut Tom's Hardware schrieb er, der Fehler sei hoffentlich in der nächsten Version behoben. Hardware Busters berichtet unter Berufung auf VideoCardz, er habe als Ursache ein Zusammenspiel der External Events Utility mit Microsofts PCIe-Filtertreiber genannt, und nennt Adrenalin 26.11.1 als Ziel für die Korrektur. Wccftech gibt die Aussage vorsichtiger wieder: Die Korrektur könnte den Stichtag für den nächsten Treiber verpasst haben. Einen Termin hat AMD nicht veröffentlicht.

Ganz neu ist der Dienst als Störenfried nicht. Im November 2025 berichtete Tom's Hardware über Nutzer, bei denen die External Events Utility bei jedem Verschieben oder Vergrößern eines Fensters eine Protokolldatei im Ordner C:\Windows\System32\AMD\EEUDumps neu schrieb. Jetzt geht es dagegen um einen dauerhaften Datenstrom im Leerlauf.

Symbolbild: M.2-SSD vom Typ Samsung 990 Pro in ihrer Verpackung

Symbolbild: Wie stark eine NVMe-SSD unter der Dauerlast leidet, hängt von ihrer garantierten Schreibmenge ab. Bild: Dinkun Chen / Wikimedia Commons, CC BY-SA 4.0

Wie stark leidet die SSD? Eine Beispielrechnung

Die folgende Rechnung ist unsere eigene. Sie setzt voraus, dass die jeweilige Rate durchgehend anliegt, und rechnet mit 1 MByte = 1 Million Byte:

  • 0,3 MByte/s ergeben rund 26 GByte pro Tag oder 9,5 TByte im Jahr.
  • 1,5 MByte/s ergeben rund 130 GByte pro Tag oder 47 TByte im Jahr.
  • 5 MByte/s ergeben 432 GByte pro Tag oder knapp 158 TByte im Jahr.

Als Maßstab dient die vom Hersteller garantierte Schreibmenge (TBW). Kingston gibt für seine Einsteiger-SSD NV3 320 TByte bei 1 TByte Kapazität und 640 TByte bei 2 TByte an. Liefe ein PC mit der 1-TByte-Version rund um die Uhr bei 5 MByte/s, wäre die Garantiegrenze allein durch den Treiber nach gut zwei Jahren erreicht, bei acht Stunden Betrieb am Tag nach etwa sechs Jahren. Bei 1,5 MByte/s und acht Stunden täglich wären es rund 20 Jahre, bei 0,3 MByte/s spielt die Last für die Lebensdauer praktisch keine Rolle.

Die Rechnung hat Grenzen. Die Werte beschreiben, was Windows an die SSD schickt. Wie viel davon tatsächlich als Verschleiß im Flash-Speicher ankommt, hängt vom Controller ab – von Zwischenspeicher, Wear Leveling und Schreibverstärkung – und lässt sich von außen nicht genau sagen. TBW ist außerdem eine Garantiegrenze, kein festes Ablaufdatum: Kingston koppelt die Garantie an den SMART-Wert „Percentage Used“, der bei Erreichen der Grenze 100 zeigt. Die Angabe eines Reddit-Nutzers, der Treiber habe 16 Monate lang jeden Monat einen Prozentpunkt „SSD-Gesundheit“ gekostet, hat niemand unabhängig geprüft. Rechnerisch entspräche ein Prozentpunkt pro Monat bei 320 TBW rund 3,2 TByte im Monat oder dauerhaft etwa 1,2 MByte/s – das liegt im Bereich der gemeldeten Raten.

Unterm Strich droht kein akuter Datenverlust. Die Last ist aber unnötiger Verschleiß, der sich über Jahre summiert – vor allem bei kleinen, günstigen SSDs mit niedriger TBW-Angabe und bei Rechnern, die rund um die Uhr laufen.

So prüfst du, ob dein PC betroffen ist

  1. Drücke Win + R, gib resmon ein und wechsle im Ressourcenmonitor in den Reiter „Datenträger“.
  2. Sortiere die Liste der Prozesse mit Datenträgeraktivität nach der Spalte „Schreiben (B/s)“. Taucht dort über Minuten atieclxx.exe oder atiesrxx.exe mit dauerhaft hohen Werten auf, obwohl der PC nichts tut, ist dein System betroffen.
  3. Genauer misst Process Monitor aus Microsofts Sysinternals-Sammlung: Filter auf „Process Name is atieclxx.exe“ und „Operation is WriteFile“ setzen, einige Minuten aufzeichnen und unter „Tools“ › „File Summary“ die geschriebenen Bytes pro Datei ablesen.
  4. Über längere Zeit hilft der SMART-Zähler der SSD: Notiere in einem Werkzeug wie CrystalDiskInfo die bisher vom System geschriebene Datenmenge („Host Writes“ bzw. „Host-Schreibvorgänge“) und vergleiche sie nach 24 Stunden normaler Nutzung.

Ob der Dienst installiert ist und läuft, zeigt PowerShell:

Get-Service -DisplayName "AMD External Events*" | Select-Object Name, Status, StartType

Was du jetzt tun kannst

Die sauberste Lösung ist ein Treiber, der den Fehler behebt. Lies beim nächsten Adrenalin-Update die Release Notes und miss danach erneut. Wer bis dahin nicht warten will, hat drei Möglichkeiten, alle mit Nebenwirkungen:

  • Dienst abschalten: In services.msc die „AMD External Events Utility“ beenden und den Starttyp auf „Deaktiviert“ setzen. Laut Nutzerberichten endet die Schreiblast damit. Als mögliche Folgen nennen Berichte Probleme mit FreeSync, Adrenalin-Tastenkürzeln und Anzeigefunktionen.
  • Resizable BAR abschalten: Mehrere Nutzer berichten, dass die Last ohne ReBAR beziehungsweise Smart Access Memory verschwindet, aber nicht bei allen. In manchen Spielen kostet das Leistung.
  • Älteren Treiber installieren: Nutzer nennen Versionen aus dem Winter 2025/26 (25.12.1, 26.2.2) als unauffällig. AMD empfiehlt für ein Downgrade das AMD Cleanup Utility. Dafür verzichtest du auf Fehlerkorrekturen und Spieleanpassungen neuerer Versionen.

Per PowerShell (als Administrator) sieht das Abschalten des Dienstes so aus. Notiere vorher den Starttyp aus dem Befehl oben, damit du ihn nach dem Fix wiederherstellen kannst:

# Dienst anhalten und deaktivieren
Get-Service -DisplayName "AMD External Events*" | Stop-Service
Get-Service -DisplayName "AMD External Events*" | Set-Service -StartupType Disabled
# Nach dem Treiber-Update: vorherigen Starttyp setzen (hier: Automatic) und starten
Get-Service -DisplayName "AMD External Events*" | Set-Service -StartupType Automatic
Get-Service -DisplayName "AMD External Events*" | Start-Service

Wer nur testen will, ob die Schreiblast verschwindet, hält den Dienst im Task-Manager im Reiter „Dienste“ an, ohne den Starttyp zu ändern – beim nächsten Windows-Start läuft er dann wieder.

Quellen

Bildnachweis