"Failure to read": TI9/2337 conflict with Phoenix cME

After using TI for years with great success on a variety of machines, I've run into an incompatibility with a brand-new Systemax server, running a new Phoenix BIOS with CME support. This allows for quick system restore using data stored in a hidden, protected partition on the C: drive (named cME, and displayed by TI as FAT16).

This hidden partition (the Host Protected Area) can't be mounted, deleted, or altered by any operations other than BIOS internals, and generally behaves in a very antisocial manner. And when TI scans the drive, it sees it and reports "failed to read sector" errors for all the sectors contained in it. If you "ignore all" on the errors produced by this, TI will then proceed to image the actual C: partition properly, and the backup thus produced can be used to restore if needed. The problem is that there's no automated way to do backups in this case- you have to manually tell TI to ignore the spurious errors from the cME partition in order to get the backup to proceed.

After searching the site, I have filed a support request with Acronis using their web tool, with the log from the snapAPI drivers attached- so hopefully that will be seen and acted on. Google searching revealed that this problem has also been seen with the partition manager tool, so I think it might be endemic to Acronis products run on machines that have the Phoenix CME recovery setup. This will probably require some doing to work around on their part, but the deployment of systems that have this "feature" is likely to increase rather quickly- more and more new motherboards are using the Phoenix product, like the Biostar P4M800-M7A in the Systemax. More info on this development from Phoenix is located here: http://www.phoenix.com/en/Products/Core System Software/Phoenix FirstBIOS/Desktop Pro/ . Doesn't look like this problem is going to go away...

Hopefully, this might help someone else who is tearing their hair out over the fact that the normally-reliable TI is suddenly producing spurious errors on brand-new, known-good disks in their brand-new systems. Had I known of this incompatibility, I'd have bought a different system altogether....

 

Hello skodises,

Thank you for choosing Acronis Disk Backup Software.

Please accept our apologies for the delay with the response.

Could you please let us know your Acronis request # (e.g. [Acronis #123456]) which was sent to you in autoreply to your letter so we can track the correspondence? If you have not received an autoreply then please send us a Private Message containing your e-mail address.

Thank you.
--
Alexey Popov