An Azure backup service that provides built-in management at scale.
Restart COM+ System Application, verify that Distributed Transaction Coordinator (MSDTC) runs as Network Service, and then trigger a new backup; these are Microsoft’s specific remediation steps for ExtensionSnapshotFailedCOM. ^1^
1. Repair the COM+/MSDTC service path
Perform this during a maintenance window because restarting these services can affect applications that use distributed transactions.
- Open
services.msc. - Open Distributed Transaction Coordinator:
- Confirm Log On As is
Network Service. - If it is not, open Properties → Log On, select This account, enter
NT AUTHORITY\NetworkService, clear both password fields, and apply the change. - Start or restart the service.
- Confirm Log On As is
- Open COM+ System Application and start or restart it.
- Alternatively, start both from an elevated command prompt:
sc qc MSDTC
net stop MSDTC
net start MSDTC
net stop COMSysApp
net start COMSysApp
- In the Azure portal, go to Recovery Services vault → Backup items → Azure Virtual Machine → the VM → Backup now.
- Monitor Recovery Services vault → Backup Jobs and confirm that Take Snapshot completes.
Azure Backup uses the VM Snapshot extension for application-consistent snapshots, so a COM+/MSDTC failure inside the guest can block snapshot creation even when the agent and extension have been reinstalled successfully. ^2^
2. Reinstall MSDTC only if its service cannot start or restart
This changes the MSDTC configuration and can affect transaction-dependent applications. Record any application-specific MSDTC settings first and perform the work during downtime.
From an elevated command prompt:
net stop MSDTC
msdtc -uninstall
msdtc -install
net start MSDTC
net start COMSysApp
Then reboot if Windows reports a pending restart and trigger another manual backup. Microsoft documents MSDTC reinstallation specifically as the fallback when the service cannot be restarted. ^1^
3. If COM+ and MSDTC are healthy, check VSS
The snapshot extension depends on Windows Volume Shadow Copy Service (VSS). ^3^
Run this from an elevated command prompt immediately after a failed backup:
vssadmin list writers
sc query VSS
sc query COMSysApp
sc query MSDTC
- Every VSS writer should report State: [1] Stable and No error.
- For any writer in another state, identify its owning service in Event Viewer → Windows Logs → Application, then restart that service during a maintenance window.
- Also inspect the Application and System logs at the exact failure time for sources such as
VSS,COM+,DistributedCOM, orMSDTC. - If the VSS service itself is unhealthy, restart Volume Shadow Copy and retry the backup. The Azure troubleshooting guide provides separate remediation for bad VSS writer and VSS service states. ^1^
4. Check extension evidence before escalating
Since reinstalling the VM Agent and VMSnapshot extension did not resolve this, do not repeat those actions. Instead:
- In the Azure portal, open VM → Settings → Extensions + applications.
- Confirm every extension reports Provisioning succeeded; another failed extension can interfere with backup. ^4^
- Review logs under:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot
C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot
- If Event Viewer records
IaaSBcdrExtension.exeas the faulting application, antivirus interference is specifically indicated. Add exclusions for those two directories and retry; do not disable protection broadly unless your security process permits a controlled test. ^4^
If the failure remains, open an Azure support request and include the failed job ID and timestamp, VMSnapshot logs, vssadmin list writers output, relevant Event Viewer entries, and MSDTC/COMSysApp service configuration. This allows support to distinguish a remaining guest COM+/VSS problem from a service-side backup failure without another eight-hour diagnostic run.
References