>I'm not suggesting Acronis is bad, it's worked OK in my limited experience. I'm just trying to isolate apps, services or processes that may hook the file system with a possible performance hit.
>

Guessed in that direction, but to see them singled out by name prompted post. Have been saving to their .tib files since early nineties, as they were one of the first to allow backup of running OS in WinNT, but started soon to use their boot discs as standard. Crucial bundling a special version with their MX500 was one of the reasons deciding on them to add/replace for the whole family machine park with 1 and 2 TB SSD around Easter - even if I myself still will not use their Windows offering ;-)

Paragon ok/nice for other disk stuff, but for pure backup Acronis was always faster/more compact.

>I've already suggested pretty much all of my troubleshooting suite with this issue. Do you have any other ideas?

You already attacked a lot of points from the OS side. I would probably have started trying to identify failing component/driver/whatever sooner by playing around with the code AND installation of the app.

As I have no idea on code/data size, complexity, installation needs of that app, this is awkward - as my very first hint of detailed logging went nowhere. As all my important stuff is in source/version control, even code void of any previous logging could be enabled by programmatic sprinkling of basic logging code at each function/method start and most identified returns. Running with coverage might give the same info (unless coverage file grows too large, programm might run for loger stretches) - too many unknowns.

As disc usage is already suspect: One of my personal goals with vfp apps is to have them installation/xCopy portable, so running the app not from SSD but the internal HD ( or an USB3-connected external SSD) is easy for me to argue as I allow control of data and temp files in config file (unless in directory of exe), but might be problematic with the existing code. Another approach might utilize a XP or Win7 VM, where the VM could be run on different discs/machines.

While pure HW/disc error probably would have shown up in OS error logs, perhaps this way failing components could be identified. As VM usage here is rampant, I would have no problem - no idea if Cyril uses them a lot.