After migrating a Windows 10 desktop to a new domain, it was throwing multiple VSS errors every day during the Veeam backup:
Log Name: Application
Source: VSS
Date: 10/29/2019 1:30:54 AM
Event ID: 8193
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DESKTOP01.internal.custdomain.com
Description:
Volume Shadow Copy Service error: Unexpected error calling routine CreateVssExamineWriterMetadata. hr = 0x80042311, The given XML document is invalid. It is either incorrectly-formed XML or it does not match the
schema.
——————————————————————————–
Log Name: Application
Source: VSS
Date: 10/29/2019 1:30:57 AM
Event ID: 8228
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DESKTOP01.internal.custdomain.com
Description:
Fail to parse XML file.
Reason An invalid character was found in text content.
Line 0x000001c9, None of the authorized entity elements in the SCCD matched the app being installed; either the PFNs don’t match, or the element’s signature hash doesn’t validate.
Position 0x00000a14
Errorcode 0xc00ce508
Problem text <WRITER_METADATA xmlns=”x-schema:#VssWriterMetadataInfo” version=”1.2″><IDENTIFICATION writerId=”4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f” instanceId=”152a6000-6a60-4852-a034-5383ecc0b763″ friendlyName=”Shadow Copy Optimization Writer” usage=”USER_DATA” dataSource=”OTHER” majorVersion=”0″ minorVersion=”0″/><BACKUP_LOCATIONS><EXCLUDE_FILES_FROM_SNAPSHOT path=”C:\Users\MyAdmin\AppData\Local\Packages\Microsoft.Office.Desktop_8wekyb3d8bbwe\LocalCache\Local\Microsoft\Outlook” filespec=”*.oab” recursive=”yes”/>
…
I’ve truncated the second error because it contains lots of logon names. Basically it is a list of all possible paths to *.oab and *.ost files under C:\Users on the local machine. What is instructive, however, are the bogus characters in some of the paths:
As far as I know, there should be no Asian characters and no EOT characters in file system paths.
This article references the same errors but from a slightly different cause—a service that didn’t get fully uninstalled.
This issue happened in a crunch time so I’ve been trying to reconstruct how I solved it in order to document it here. It looks like I eventually traced the issue back to the profile paths stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList]. For example, here is the path stored in one of the profiles:
My hunch is that the tool that I used to migrate profiles from one domain to another (ForensIT Profwiz) had somehow left behind corrupted references to paths in the old domain. Fortunately, the registry key names begin with a domain number, so it was easy to identify and delete all the profiles belonging to the old domain:
As best I can recall, it was deleting those registry keys that fixed this error.