Skip to main content
Hyper-V backups fail with PHOENIX54 error
Updated over 10 months ago

This article applies to:

  • OS: Windows

  • Product edition: Phoenix

Problem description

Hyper-V backups fail with PHOENIX54 error.

Scenario 1:

Traceback

Phoenix logs

[2019-04-17 14:43:48,198] [INFO] <_MainThread(MainThread)> roboSyncer: Sending log to Phoenix server with message : 'Backup operation failed.'
[2019-04-17 14:43:48,214] [INFO] <_MainThread(MainThread)> Enabled fault scheck for backup
[2019-04-17 14:43:48,214] [ERROR] <_MainThread(MainThread)> HypervAgent: Hyperv backup failed: Failed to take snapshot. (#100000036) (Error Code : PHOENIX54)
[2019-04-17 14:43:48,214] [ERROR] <_MainThread(MainThread)> Error <class 'inSyncLib.inSyncError.SyncError'>:Failed to take snapshot. (#100000036) (Error Code : PHOENIX54). Traceback -Traceback (most recent call last):

Windows Event Logs

WinEventLog.png

Resolution

This issue can be resolved either by changing the provider ID from Phoenix.cfg or by removing the orphan entries of the provider ID from the OS. However, this requires finding the provider ID as described below:

To find the provider ID:

  1. Check the Provider ID (as highlighted above) in the Windows event logs.

  2. Run the below command from the command prompt as an administrator to list the VSS provider IDs on the OS.

    vssadmin list providers
  3. Compare the Provider ID from the event logs with the output of the above command to identify the VSS owner name.

You can use any of the following resolution:

  • Change the VSS provider for the backups from Phoenix.cfg and remove the software for which VSS provider is present but not required.

  • Remove the provider ID from the registry if it is orphan

The resolution steps are provided as below:

  1. Change the VSS provider ID from Phoenix.cfg

    1. Stop the Druva Phoenix Agent Client service.

    2. Open the Phoenix.cfg file in a text editor. The Phoenix.cfg file in Windows 2012 and 2008 is available at: C:\ProgramData\Phoenix.

    3. Add the VSS_PROVIDER_ID parameter, and set its value to reflect the provider ID using the following syntax:

    4. VSS_PROVIDER_ID = '{Provider ID}'

    5. For example, if you obtained “f782463b-33bb-4043-ad8d-60b728d26a6c” as the provider ID, then VSS_Provider_ID parameter must like:

    6. VSS_PROVIDER_ID = '{ f782463b-33bb-4043-ad8d-60b728d26a6c}'

    7. Note: Ensure that there is no whitespace between the curly braces and the single quotation marks.

    8. Save the Phoenix.cfg file.

    9. Start the Druva Phoenix Agent Client service.

  2. Remove the orphan entries of the provider ID from the OS

    1. Open the registry editor using regedit

    2. Navigate to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\]

    3. Back up the key.

    4. Delete the key. For example, delete {f782463b-33bb-4043-ad8d-60b728d26a6c} from the provider ID value.

    5. Open the Windows Services management console (services.msc).

    6. Restart the ‘Microsoft Software Shadow Copy Provider service.

    7. Initiate a back up.

    8. If the backup still fails, restart the Hyper-V Host.

Scenario 2:

Cause:

  • VSS Writes inside the VM are not stable.

Traceback

Errors in Job Details

[2023-07-10 17:08:01,072] [ERROR] <_MainThread(MainThread)> SyncError: VSS writer has reported failure : [state = 8, result_code = 0x800423f3L], writer details are = [writer class id : {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}, writer name : Microsoft Hyper-V VSS Writer]
[2023-07-10 17:08:01,072] [INFO] <_MainThread(MainThread)> Error while attempting to take snapshot

On Hyper – V Server under Event Viewer > Hyper – V VMMS

Event ID - 10172 -VSS writers inside virtual machine 'VM' failed to perform BackupComplete to its shadow copy (VSS snapshot) set: A function call was made when the object was in an incorrect state for that function (0x80042301). (Virtual machine ID AC72F43B-3380-4144-84B1-586BA825234A

Resolution

  1. Restart the VM: Start by restarting the virtual machine to see if the issue was temporary and can be resolved with a simple reboot.

  2. Check VSS Writers: Use the "vssadmin list writers" command in the command prompt inside the VM to check the status of VSS writers. Look for any writers that are in a failed or unstable state.

  3. Verify Sufficient Disk Space: Ensure that there is enough free disk space on the volume(s) being backed up, as VSS requires space to create snapshots.

  4. Review Event Logs: Check the Event Viewer logs on the VM for more detailed error messages related to VSS failures. This might provide additional insights into the root cause.

  5. Update VM Integration Services: If the VM is running on a virtualization platform (e.g., Hyper-V), make sure the Integration Services are up to date.

  6. Check for Windows Updates: Ensure that the VM's operating system and VSS components are up to date with the latest Windows updates.

  7. Contact Support: If the issue persists and you're unable to resolve it, consider reaching out to Microsoft support or your virtualization platform's support for further assistance.

If the issue persists, please engage Hyper-V/System Admin to fix the issue.

See also

Did this answer your question?