App-V Client Service Error 575

Windows could not start the Microsoft App-V Client on <machinename>.  For more information review the System Event Log.  If this is a non-Microsoft service, contact the service vendor, and refer to service-specfic error code 575.

This occured in some seemingly normal deployment collection change in SCCM.  Machines were moved from one collection where the package had already been targeted due to an upgrade, to another collection intended to be used for the specific version deployment.  The expected behaviour was that the SCCM client would detect the package was already applied and report "Already compliant" for the deployment stats.  That didn't happen........

The App-V clients were affected - in a bad way.

The app involved had the C:\ProgramData\Microsoft\AppV\Client\Catalog\Packages\{PackageGUID}  folder deleted then the service started fine.

Ran the Application Deployment Evaluation Cycle on the client and the SCCM client resurrected the package from the SCCM cache within a minute.

Root Cause - unknown.  Suspected corruption of the XML files in the catalog folder

Thanks to
http://blog.notmyfault.ch/?p=207

It was possible to do a mass correction / repair operation by deploying a powershell script to automate the above repair actions.

ATI 2018 recovery failure workaround

While attempting to recover a partition from a disk image backup, the recovery failed during several attempts, each time at a different disk sector.  The recovery was being carried out by booting from the bootable recovery media previously generated from the Windows Acronis True Image (ATI) Software onto a USB key.  The target drive was a Samsang EVO 840 500Gb SSD where the backup had been made from previously.

The error text is:

Acronis True Image
Failed to write data to the disk <sector number> of hard disk <number>
Failed to write to the snapshot manager drive. (0x1000DA)
Unknown status. (0x9)
The request could not be performed because of an I/O device error (0xFFF0)
Retry / Ignore / Ignore All / Cancel





















Some of the recovery job did proceed until the failure, each time at a different disk sector.  The suspicion was that the drivers for the SSD drive being written to were crashing out causing the failure.

To work around the problem, the latest bootable recovery media was downloaded from the Account area on the Arconis website.  A further problem then occurred.  The downloaded bootable recovery media was linux based and could not read the external USB 3.0 drive containing the disk images.  As the computer was still bootable from another drive and OS, the disk image was copied to an internal drive which the linux bootable recovery software could see.

The recovery then completed as expected without issue.

keywords recovery restore ATI Acronis True Image 2018