Reports are mounting that some Windows PCs with Radeon graphics are seeing continuous SSD writes tied to AMD's "AMD External Events Utility" service. Users report write speeds of roughly 0.7MB/s to 5MB/s, and some posts say I/O continues even with Adrenalin 26.10.2. Some users report that stopping the service helped, but the cause, the affected configurations, and the timing of a fix have not been made clear.
A problem involving the same service previously generated large numbers of file-change notifications. However, the number of file-change notifications, a process's write speed, and the physical wear on an SSD's NAND flash are different measures. Judging how much this issue affects SSD lifespan requires keeping them separate.
From 0.7MB/s to 5MB/s: write reports vary by system
In a Reddit post, RodroG reported continuous writes of about 0.7MB/s on a PC with a Radeon RX 7900 XTX, a Core i9-12900K, and 32GB of RAM. The system uses Adrenalin 26.9.2 and Windows 11 26H2. Because this configuration uses an Intel CPU, the reported symptoms are not limited to PCs with AMD processors. In the same thread, videoismylife also reported disk usage reaching 90–100% on a system with a Radeon RX 580, a Ryzen 7 5700X, Adrenalin 26.5.2, and Windows 11 26H2. However, disk usage and write speed are different measures, so the amount of data written cannot be compared directly from these figures.
In another report by Spardax_117, writes of about 5MB/s were observed on a PC with a Radeon RX 9070 XT and a Ryzen 9 7900. The system uses a Kingston NV3 2TB SSD, a B650 motherboard, and 32GB of RAM. The 0.7MB/s and 5MB/s figures were observed by different users in different environments, so they do not represent a range of write speeds measured under uniform conditions.
Spardax_117 said that after disabling AMD External Events Utility and monitoring the system for several hours, the audio and overall game stuttering in CONTROL: RESONANT disappeared, and texture-loading problems in Gears of War: E-Day were also resolved. However, the user also states that they cannot confirm whether the service is the direct cause of the symptoms or whether all AMD users are affected. The change in symptoms before and after stopping the service is a clue, but this report alone does not prove causation.
How do the earlier logging issue and the current SSD writes differ?
AMD External Events Utility had previously been flagged for generating large numbers of file changes. In an earlier Reddit post, Takia_Gecko monitored the "EEUDumps" folder and reported that hundreds of change notifications occurred as windows were moved or resized, and that they stopped when the service was disabled. The PC used a Ryzen 7 7800X3D and a GeForce RTX 4070 Super, with AMD Chipset Software 7.06.02.123 installed. According to the poster, the service in question was included in the chipset software.
"ReadDirectoryChangesW," the function used in that investigation, is a Windows API that detects changes within a specified directory. According to Microsoft's official documentation, it can retrieve information when changes are made to files or directories. However, a large number of change notifications does not necessarily mean the SSD received the same number of physical writes.
To understand the current issue, it helps to distinguish the following three measures.
| Measure | What is observed / unit | What it tells you and its limits |
|---|---|---|
| File-change notifications | Change information detected in a monitored folder. Unit: number of notifications | Shows how often files change, but not write speed or the actual amount written to NAND |
| Process write speed | Write I/O generated by a specific process. Unit: MB/s, etc. | Shows write speed at the time of observation, but cannot be converted directly into notification counts or NAND wear |
| NAND writes / wear | Amount written to the SSD's internal flash memory and the resulting wear on the memory cells | Evaluating actual wear requires information such as the write amplification factor and SSD health data |
This table organizes the differences between measures based on public reports and technical documentation. It is not the result of a before-and-after comparison on the same PC or an independent replication. It also has not been confirmed whether the earlier file-change notification issue and the current continuous writes stem from the same bug in the same program. The fact that the symptoms share some features is not enough to conclude that the earlier problem has "recurred."
If 5MB/s continues, that's 432GB a day. What does it mean for SSD lifespan?
If writes at 5MB/s continued uninterrupted for 24 hours, the calculated total would reach 432GB. However, this is an estimate assuming a constant reported speed, not the result of an actual 24-hour measurement. Using decimal MB and GB and the formula "write speed (MB/s) × 3,600 seconds × hours ÷ 1,000," the results are as follows.
| Assumed write speed | If sustained for 8 hours | If sustained for 24 hours |
|---|---|---|
| 0.7MB/s | About 20.2GB | About 60.5GB |
| 5MB/s | 144GB | 432GB |
The 8-hour scenario assumes a PC used for a certain period of time. Actual write volume depends on how long the symptoms persist and how the write speed fluctuates. The figures in the table also assume writes from the host side and are not necessarily the same as the amount actually written to the SSD's internal NAND flash.
On page 6 of Kingston's technical document "Flash Memory Guide", it is explained that NAND flash has a limit on the number of program/erase cycles. Inside an SSD, more data than the host requested may be written to NAND, and the measure of this relationship is the "Write Amplification Factor (WAF)." A higher write amplification factor increases the number of NAND rewrites and can affect SSD lifespan.
However, for the PCs in these reports, no changes in write amplification factor or SMART data, and no actual NAND wear figures, have been presented. If 5MB/s continued for long periods, the volume written could become non-negligible, but the 432GB estimate alone cannot determine how much SSD lifespan would be shortened. Nor does it provide grounds for predicting when an SSD might fail.
Disabling the service helps in some reports, but watch for effects on features
One workaround users currently report is stopping AMD External Events Utility. However, whether writes decrease and whether needed features keep working correctly must be checked separately. RodroG reported that changing the service's startup type to "Disabled" or "Manual" improved the symptoms, and that FreeSync and Resizable BAR continued to work in their environment. At the same time, they were concerned that hotkeys might stop working, and another user reported problems such as game profiles not being saved. Which features are affected may vary depending on the GPU, driver, and settings.
In the same Reddit thread, the account AMD_Vik also mentioned a method of disabling Resizable BAR. However, videoismylife reported that disabling Resizable BAR made no difference to the symptoms. Changing the Resizable BAR setting therefore cannot be said to be an effective workaround in every environment.
To check whether your own PC shows similar symptoms, you can use Windows Resource Monitor. Open the "Disk" tab in Resource Monitor and check whether writes by "atieclxx.exe" are continuing. If you record the OS, GPU, and driver version along with the observation time and write speed, it is easier to compare before and after settings changes or driver updates.
If you try stopping the service, it is important to record the original settings, then check both write volume and the features you normally use after the change. If any problems occur, you should restore the original settings. There is also no need to disable the service across the board on PCs that are not showing the symptoms. Knowing the state before any change is also useful for tracking future fixes.
Is AMD preparing a fix? What to check in the next driver
In a Reddit post, the account AMD_Vik mentioned the relationship between AMD External Events Utility and Microsoft's PCIe filter driver and said the issue is being investigated. The account later said a colleague had submitted a fix, that it considers the risk low, and that it hopes for an early release. However, these are statements from a Reddit account and do not mean the cause of the problem has been confirmed or that AMD has officially announced a fix.
In another Reddit post, in reply to a report that I/O of around 600KB/s continued even with Adrenalin 26.10.2, AMD_Vik said they hope it will be fixed in the next version. But this is not a commitment to a specific release date or driver version, and it cannot be said for certain that the next update will fix it.
The release notes for Adrenalin 26.10.2, which AMD updated on October 30, 2026, contain no mention of continuous SSD writes by AMD External Events Utility under either fixed issues or known issues. However, the absence of a mention in the release notes alone is not grounds for concluding that the problem remains unfixed in every environment. The release notes for AMD Chipset Software 8.09.28.1124 also include bug fixes, but they do not explicitly state that any address this write issue.
What to watch for in upcoming driver updates is whether AMD explicitly lists this issue as a fix target and whether the continuous writes actually go away. Setting the same idle conditions and observation time before and after an update, then comparing write speed and total volume, allows a more accurate judgment of any improvement. If you had disabled the service as a workaround, restore the original setting and then check both write activity and the operation of the features you use regularly. At this stage, the affected environments and the actual impact on SSD lifespan remain unclear, and AMD's disclosure of what its fix changes, along with verification results under identical conditions, will be the basis for future judgments.