Your graphics driver shouldn’t be the thing killing your SSD. And yet here we are, with an AMD driver SSD bug that has apparently been grinding away at Radeon owners’ drives for more than a year, while the PC sat there doing absolutely nothing.
The culprit is a little background service called the AMD External Events Utility. It ships with every Adrenalin driver package, it handles things like hotkeys and display events, and according to a pile of user reports it also likes to write to your system drive. Constantly. Around 5 MB per second on one machine, with the desktop idle.
Do the maths and it gets ugly fast. 5 MB/s is roughly 18 GB an hour, 432 GB a day, close to 13 TB a month. One Radeon owner says the thing “eats up 1% of my SSD health every month for 16 months”. That number isn’t independently verified, and host writes don’t translate one-to-one into NAND wear because the controller caches and wear-levels, but even if reality is a fraction of that, it’s wear you never signed up for.
AMD driver SSD bug: what we know
The story resurfaced on 8 November when a Reddit user bundled the scattered reports into a PSA on r/pcmasterrace, and Tom’s Hardware picked it up the next day. The interesting part is that AMD already knew. On 21 October, a company rep on AMD’s own community forum answered a thread about it with a tidy “Yes. We’re looking into it with the aim to resolve it in a future driver release.” On Reddit, another AMD rep offered a “hopefully fixed in the next one.”
Hopefully. Nine days after that forum reply, AMD shipped Adrenalin 26.20.2, and the release notes don’t mention the issue at all. Reports also cover 26.19.2 and older drivers, so this isn’t a fresh regression from one bad build. It’s been around, quietly, and nobody at AMD thought it deserved a line in the known-issues list.
I’ll be fair: AMD didn’t deny it, didn’t hide behind “we can’t reproduce”, and I’ve seen worse from GPU vendors. But “we’re looking into it” with no date, for a bug that physically wears out hardware, is not the same thing as a fix. And it’s a sequel: last November it was AMD’s chipset driver filling a log file endlessly. Different component, same genre.
How to check your own PC
Takes thirty seconds. Hit Win+R, type resmon, open the Disk tab and sort by write activity. If atieclxx.exe or atiesrxx.exe sits near the top while you’re doing nothing, congratulations, you’re affected. You can cross-check with CrystalDiskInfo: look at the host writes total and ask yourself whether your SSD has really seen that many terabytes.
Two workarounds are floating around, neither of them clean. The first is to open services.msc, find “AMD External Events Utility” and either stop it or set it to Disabled. The writes stop, but you also lose a few driver features like certain hotkeys and multi-monitor event handling. The second is odder: one user reports that turning off Resizable BAR in the BIOS kills the disk activity without touching the service. ReBAR gives you free frames in a lot of games, so that’s a real trade-off, and it also hints that the bug depends on the hardware combo, not just the driver.
Which brings me to the annoying part: AMD hasn’t said which GPUs, boards or configurations trigger it. Some people see 5 MB/s, a commenter says about 1% health per five months, another counted 69 TB written over roughly 900 days. Linux users seem unaffected, for once.
What I’d do: check resmon tonight, and if the writes are there, disable the service until a driver actually lists this as fixed. A modern 1 TB drive is rated for 600 TB or so of writes, so you’re not going to lose it next week, but there’s no reason to donate a chunk of its lifespan to a utility you’ve never heard of.
The GPU was supposed to render pixels, not write your SSD’s obituary.
Discover more from TechPassion
Subscribe to get the latest posts sent to your email.
