Over two years ago, I installed Acronis True Image for Crucial to migrate my data to a new SSD. The software worked as intended—and like many users, I left it installed afterward, thinking: what harm could it possibly cause?
Turns out, quite a bit.
A Mysterious Slowdown
Recently, I noticed a strange issue: every time I plugged in or disconnected my external monitor, Explorer.exe would spike in CPU usage. The system would slow down significantly—sometimes for more than 15 seconds—before stabilizing. Curious, I grabbed an ETW (Event Tracing for Windows) trace and dug in.
What I found was surprising.
Note: I’ve worked directly with Acronis on this issue. They’ve offered a temporary workaround and confirmed that a fix is in development for a future release. (See the “Workarounds and Fixes” section.)
The Smoking Gun
In the trace, Explorer.exe consumed 44 seconds of CPU time over just 16 seconds. That’s excessive for what should be a routine hardware event.
Using Windows Performance Analyzer (WPA), I opened the CPU Usage (Sampled) view. After hiding the Thread ID and Name columns to group similar threads, I quickly identified the culprit:windows.storage.dll!CFSFolder::_GetOverlayInfo—responsible for over 20,000 of the 42,000 collected CPU samples.
Most of that time was spent inside a call to an unknown function within tishell64_26_0_39450.dll, a file I didn’t immediately recognize.
Peeling Back the Layers
Without debug symbols for tishell64.dll, I shifted focus to known Windows APIs being called:
CreateToolhelp32SnapshotProcess32NextW
These are used to enumerate all running processes on the system—an operation typically reserved for system utilities, not shell extensions.
I set a conditional breakpoint on CreateToolhelp32Snapshot in Visual Studio, allowing it to count how many times the function was called without halting execution. Results varied, but with three Explorer windows open, the function was hit 1,200 to 3,000 times each time I connected or disconnected my monitor.
Even with no Explorer windows open, there were 44 calls to this function—still excessive. The behavior suggests that the Acronis shell extension is looping through all system processes thousands of times simply because a display was added or removed.
Who Owns tishell64.dll?
Digging deeper with WPA, I examined all loaded DLLs in Explorer.exe. Out of 370 loaded libraries, 11 were missing version metadata—a red flag.
Among them was tishell64.dll, located in:
javaКопіюватиРедагуватиC:\Program Files (x86)\Acronis\TrueImageHome
Running sigcheck confirmed it was published by Acronis International GmbH. So yes, this performance issue was caused by Acronis True Image—specifically, by a poorly optimized shell extension.
Just How Bad Is It?
In my tests, tishell64.dll consumed:
- 26 seconds of CPU time in a typical trace
- Over 60 seconds in a “torture test”
All of this occurred simply by unplugging a monitor. The cost scales with the number of Explorer windows open and visible icons (e.g., in Downloads folders), and worsens if the system is already under heavy load.
The Process32NextW() function—used to iterate through the list of processes—is inherently expensive. But that’s beside the point. It shouldn’t be called 3,000 times in the first place.
Fixes and Workarounds
To their credit, Acronis responded after I reported the issue. They confirmed the behavior and shared debug symbols to aid my investigation. A proper fix is planned for a future release.
In the meantime, you can disable the offending shell extension by deleting the following registry key:
КопіюватиРедагуватиHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Explorer\ShellIconOverlayIdentifiers\ AcronisDrive
Note: Yes, there are five spaces at the beginning of that key name.
Acronis has already fixed some related performance issues in newer versions of True Image, but the version provided by Crucial remains outdated and problematic. In my tests, even the latest download from Crucial’s website still included all the performance bottlenecks.
Crucial’s initial response?
“We have not encountered any customers experiencing issues with the Acronis free version available on the Crucial website.”
After further follow-up, they added:
“Our team is looking into this matter, and we will provide any relevant updates as soon as possible.”
My Solution: Uninstall It
Ultimately, the best fix was the simplest one—I uninstalled Acronis True Image.
If you’re using an OEM-provided version like the one from Crucial, I strongly recommend removing it unless you actively need it. Leaving it installed can result in wasted battery life, sluggish performance, and unnecessary CPU load—even when you’re not using the software.
A Final Word on Missing Metadata
Many of the DLLs in question were also missing key metadata fields like Product Name and File Version, even for Microsoft-published files. This isn’t just a curiosity—it hampers debugging and trace analysis. There should be automated checks to ensure such metadata is always included in production software.
As for Acronis, the missing metadata is the least of their concerns. They need to fix the logic that causes their shell extension to iterate through every running process thousands of times for basic system events.
Conclusion
A shell extension bundled with Acronis True Image was silently causing massive CPU spikes on my system, triggered simply by plugging in or removing an external monitor. The root cause: repeated, unnecessary enumeration of all running processes.
The issue wasted dozens of CPU seconds, taxed system performance, and burned battery—without providing any value to the user.
If you’ve got Acronis True Image installed “just in case,” it’s time to reconsider. It may be doing far more harm than you realize.
