Radeon atieclxx SSD Write Bug: Open-Source Fix Without Disabling AMD Services

That distinction matters because earlier workarounds involved compromises: disabling the service could interfere with display-related functions, while disabling Resizable BAR could reduce gaming performance. The new utility promises a narrower intervention—but a community workaround requiring administrator privileges still deserves scrutiny, not a reflexive double-click.

What changed—and what remains unresolved​

ComputerBase reported the underlying write problem on November 9, 2026, then covered Necandi’s utility on November 11. TechPowerUp subsequently reported the community release and identified Adrenalin 26.11.1 as AMD’s planned fix, describing that driver as unreleased at the time of its report. Treat that version as a reported target, not confirmation that a corrected package is available or that its effectiveness has been established.

The immediate development is therefore not an AMD driver repair. It is a tool designed to detect the known behavior, block its destination-file writes, and maintain that protection across driver changes. According to its README, the tool can also reverse its changes and attempt to remove protection automatically after detecting a corrected driver.

The useful distinction is mitigation versus correction. Blocking an unwanted copy operation can address its storage consequences without repairing the code that keeps requesting the copy. That makes verification and eventual cleanup part of the job, rather than optional housekeeping.

What the SSD write bug actually does​

The project’s developer says Windows Event Tracing revealed atieclxx.exe, associated with AMD External Events Utility, repeatedly copying its own executable from the driver directory to this location:

C:\Windows\System32\config\systemprofile\AppData\Local\AMD\atieclxx.exe

The copied file is approximately 660 KB, with the operation occurring about once per second on affected installations. The project estimates roughly 56 GB of writes per day under continuous operation. This is the developer’s documented finding, not an independently published AMD root-cause analysis.

TechPowerUp reports broader user observations ranging from 0.3 MB/s to 5 MB/s. At a sustained 5 MB/s, the arithmetic reaches 432 GB over 24 hours. That headline-sized number assumes uninterrupted activity at the reported upper rate; it is not a measurement that applies to every Radeon computer. Nor should it be substituted for the developer’s smaller, specific self-copy estimate.

An important consequence of the described mechanism: repeatedly overwriting a file is not the same as accumulating hundreds of gigabytes of additional files. The concern is unnecessary write traffic, not necessarily disappearing free space. That distinction follows from the overwrite behavior documented by the project.

The README also says the service subsequently searches for installation files associated with the amdkmpfd filter driver and Smart Access Memory. The developer offers this as an explanation for why disabling Resizable BAR helps some machines. It remains the project’s explanation, rather than proof that every reported write pattern has the same cause.

Who should investigate?​

Not every Radeon installation is affected. ComputerBase says the triggering driver version cannot be precisely isolated and describes reports extending beyond the latest releases. Its coverage also includes AMD CPU and chipset-driver configurations, meaning the presence of an Nvidia or Intel graphics card does not automatically settle the question.

That does not justify treating every AMD-equipped PC as faulty. It means observed behavior is more useful than a hardware-brand checklist.

The utility explicitly distinguishes among three outcomes:

• The known self-copy operation at the expected destination.
• Writes occurring somewhere else.
• No detected instance of the problem.

The README warns that other driver versions may behave differently. A tool designed around one destination cannot be assumed to fix every source of AMD-related disk activity.

For readers, the practical boundary is simple: establish that the suspicious activity exists before changing services, firmware settings, or file permissions.

How the targeted protection works​

Necandi’s recommended option, labeled “Gezielter Schutz” in the German interface, adds a deny rule for the Windows SYSTEM account on the single copied executable. The project says subsequent overwrite attempts fail while the service remains active, preserving FreeSync, frame pacing, and Radeon hotkeys. Those functionality claims come from the developer; they should not be mistaken for independent compatibility testing across Radeon hardware.

Microsoft’s documentation helps explain the mechanism more precisely. The Windows icacls utility can modify file access-control lists, and its /deny option creates an explicit deny entry. The permission codes used by this project cover writing data, appending data, changing extended attributes, changing attributes, and deleting the file. This is therefore broader than simply checking a file’s read-only box, although its intended scope is still just one file.

That is also why copying the permission idea onto an entire AMD directory—or the Windows system profile—would be a poor improvisation. The narrow target is integral to the proposed workaround, not an incidental detail.

The project says it neither modifies the driver nor bundles AMD files, and that it makes no network connections or downloads. Its source resides in the repository’s Skript folder under an MIT license. These disclosures make inspection possible; they do not constitute a security audit.

A cautious route from diagnosis to verification​

For someone considering the utility, the sensible sequence is measure, decide, apply, then measure again.

1. Establish whether there is a problem​

ComputerBase recommends opening Windows Resource Monitor, locating atieclxx.exe, and observing its write activity. Look for the persistent pattern being reported, rather than treating the process’s mere presence as evidence of a fault.

The tool adds more specific detection. Its README says it uses the NTFS USN change journal to recognize the self-copy operation. When needed, it falls back to a short Event Tracing for Windows recording, capped at 64 MB, which it deletes afterward. The developer explains that ordinary file timestamps are unsuitable for this check because the copy operation preserves timestamps from the source.

2. Understand the prerequisites​

The documented package is Radeon-atieclxx-SSD-Fix.zip, distributed through the necanditool/Radeon-atieclxx-SSD-Fix repository’s Releases section. Applying the workaround requires administrator privileges, and the interface is German. The README also warns that the program will not start where company policy permits only signed PowerShell scripts.

On a managed work computer, stop here and involve IT. A policy restriction is not an invitation to weaken the policy.

3. Follow the documented startup procedure​

For users who understand and accept the unofficial nature of the tool, the project documents this sequence:

1. Obtain the release ZIP from the identified project.
2. Extract the archive completely.
3. Run START.cmd.
4. Approve the administrator-rights prompt only if the package and its requested changes are acceptable.
5. Let the analysis establish which write pattern, if any, is present before selecting a mitigation.

The README anticipates a Windows SmartScreen warning and describes overriding it. That should not become a blanket recommendation to dismiss Windows security prompts. If the origin or contents are uncertain, do not proceed.

4. Choose the narrow intervention​

For the recognized self-copy behavior, the project recommends “Gezielter Schutz.” Its separate “Dienst deaktivieren” option disables the service instead; selecting that option forfeits the central benefit of keeping the service running. “Alles rückgängig” reverses the protection, automation, and service-disable changes.

5. Confirm the result​

The supplied PRUEFEN.cmd performs a status check and a 10-second measurement without administrator rights. Use the tool’s result alongside another observation of the process’s disk activity. Success means the targeted recurring writes have stopped—not that every legitimate write on the PC disappears. The project also provides ENTFERNEN.cmd to reverse its changes and remove its program folder.

If the analysis identifies a different write destination, do not expand the permission block by guesswork.

The scheduled task deserves attention​

Targeted protection installs a Task Scheduler entry named Radeon-atieclxx-SSD-Fix. According to the README, it runs as SYSTEM three minutes after startup and every 30 minutes thereafter. Its responsibilities include restoring protection if a driver update replaces the file and checking after driver changes whether the unwanted behavior has been corrected.

The developer says the task can lift protection automatically once it detects a fix. That is useful functionality, but it remains another developer claim to verify on the actual machine.

Events are logged to:

C:\Program Files\Radeon-atieclxx-SSD-Fix\protokoll.txt

The project says logging occurs only when events happen. It also notes that Windows Home lacks the msg.exe functionality used for its automated notification windows, so those notifications are unavailable there even though events remain in the log.

For administrators, the takeaway is that this is not merely a one-time diagnostic. It installs persistent, privileged automation. Record that change and retain a removal plan.

Why its historical-write estimate needs caution​

The utility estimates accumulated unnecessary writes from the measured rate and assumed operating time since the AMD graphics installation. ComputerBase explains that the actual beginning of the fault may be unknowable. Where SSD operating-time information is unavailable, the estimate assumes eight hours of use per day.

That creates several limits:

• A present-day write rate does not establish the rate throughout the installation’s history.
• Installing an AMD graphics driver does not prove the bug started that day.
• An assumed daily operating time may differ substantially from actual use.

Accordingly, treat the output as an estimate of possible write volume, not a measured lifetime record, a warranty determination, or proof of a specific amount of physical damage. ComputerBase’s account explicitly identifies the calculation’s uncertain starting point and usage assumptions.

The numbers can help prioritize investigation. They cannot turn incomplete historical data into a forensic report.

Alternatives and the route back to normal​

ComputerBase documents the broader service workaround as follows: press Win+R, enter services.msc, find AMD External Events Utility, open its properties, stop it, and change its startup type to Disabled. The publication cautions that this can impair FreeSync or frame pacing and may not resolve every case.

Disabling Resizable BAR in firmware is another reported alternative, with possible gaming-performance costs. ComputerBase likewise does not present it as universally effective. The community utility explains this option but cannot change the BIOS setting itself.

Neither broader option should be the first response to an unverified suspicion. If you do change a service or firmware setting, record its original state so the temporary measure does not become an unexplained permanent configuration.

The eventual goal remains an AMD driver correction, not indefinite reliance on blocked file operations. TechPowerUp’s 26.11.1 target provides a version to watch, but a planned fix is not the same as a confirmed result on your PC.

Once a corrected driver is available, the sensible completion test is normal operation with temporary restrictions removed and the unwanted writes absent. Until then, Necandi’s utility offers a documented, reversible approach for the recognized self-copy case. Its strongest argument is precision; its biggest limitation is that it remains an unofficial workaround whose detection, compatibility, and automatic cleanup still need verification on the machine using it.