After installing Windows cumulative update KB5083769 (released 14 April 2026) - or the optional preview update KB5083631 - SyncBack profiles that use the Volume Shadow Copy Service (VSS) to back up open or in-use files start failing with one or more of the following:
- "The backup has failed because Microsoft VSS has timed out during the snapshot creation."
- VSS error code VSS_E_BAD_STATE.
- The snapshot phase hangs and is eventually aborted.
- vssadmin list writers shows one or more writers in a Failed or Waiting for completion state.
The same machine may have been running SyncBack profiles successfully for months or years before the update.
Cause
KB5083769 adds the kernel driver psmounterex.sys to the Microsoft Vulnerable Driver Blocklist. Once the update is installed, Windows Code Integrity refuses to load that driver under Policy ID {D2BDA982-CCF6-4344-AC5B-0B44427B6816}. The block addresses CVE-2023-43896, a privilege-escalation vulnerability in older versions of the driver.
psmounterex.sys is NOT part of SyncBack. SyncBackPro, SyncBackSE and SyncBackFree do not install, ship, or depend on this driver in any version. The file is supplied by Paragon Software and is bundled with several other backup products, most commonly:
- Macrium Reflect 8.x (and earlier)
- EaseUS Todo Backup
- AOMEI Backupper
- Other utilities that license the Paragon VSS provider or image-mounting driver
If any of these products are - or were previously - installed on the machine, the driver registers itself as a VSS provider and/or a filesystem filter. When Code Integrity then refuses to load it, the entire VSS subsystem on that machine becomes unstable. Backup software that has nothing to do with psmounterex.sys, including SyncBack, then sees snapshot creation time out or fail.
In short: a different vendor's driver is sitting in the VSS stack, Windows has just blocked it, and every VSS consumer on the machine is affected as a side effect.
STEP 1 - Confirm this is your problem
VSS timeouts can have many causes. Before applying the fix below, confirm that psmounterex.sys is actually the trigger. In an elevated PowerShell window, run:
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" -MaxEvents 500 |
Where-Object { $_.Id -in 3023,3077 -and $_.Message -match 'psmounterex' } |
Select-Object TimeCreated, Id, Message
If you get one or more events back, this article applies. If the result is empty, the VSS failure has a different cause - please contact 2BrightSparks support and include a SyncBack debug log so we can investigate.
STEP 2 - Locate the driver and identify its source
In the same elevated PowerShell window:
Get-ChildItem -Path C:\ -Recurse -Filter psmounterex.sys -ErrorAction SilentlyContinue |
ForEach-Object {
[pscustomobject]@{
Path = $_.FullName
Version = $_.VersionInfo.FileVersion
Vendor = $_.VersionInfo.CompanyName
Status = (Get-AuthenticodeSignature $_.FullName).Status
}
}
Note the path and the version. The path usually points at the install folder of the product that placed the driver there (e.g. C:\Program Files\Macrium\Reflect\), or at C:\Windows\System32\drivers\.
You can also see how the driver is currently registered:
vssadmin list providers
fltmc filters
sc query psmounterex
A Paragon, Macrium or similarly named VSS provider, a filter named psmounterex, or a service entry for psmounterex all confirm the driver is hooked into the system.
Workaround for SyncBack V12 (Advanced VSS)
SyncBack V12 introduced an Advanced VSS option on the profile's Copy/Delete > Advanced > Volume Shadow Copy page that lets you choose a specific VSS provider and exclude individual VSS writers. This may allow a profile to complete on an affected system, but it is a stop-gap — the underlying problem (a blocked kernel driver destabilising the VSS subsystem) remains, and other backup software on the machine will continue to fail. The fixes earlier in this article are still the correct long-term solution.
Try excluding the failing writer
1. Open an elevated Command Prompt and run:
vssadmin list writers
2. Look for any writer whose State is not Stable (e.g. Failed, Waiting for completion) or whose Last error is not No error. Writers belonging to the third-party backup product that installed psmounterex.sys are the most likely culprits.
3. In SyncBack V12, edit the profile and go to Copy/Delete > Advanced > Volume Shadow Copy.
4. Tick Use advanced VSS settings.
5. In the Excluded writers list, tick the writer(s) identified in step 2.
6. Save the profile and run it.
Try a different VSS provider
If excluding writers does not help, on the same page try selecting a different entry in the Provider dropdown. In most cases only the Microsoft Software Shadow Copy provider is available and useful; hardware providers and providers installed by the third-party backup product itself are unlikely to improve matters and may make things worse.
If neither workaround succeeds, the VSS subsystem on the machine is too compromised for SyncBack to work around in software. Return to the recommended fixes at the top of this article (update or uninstall the third-party product, then remove the orphaned driver).
Fix for all versions of SyncBack
APPLY THE FIX
Choose ONE of the following, in order of preference.
Option A (recommended) - update the product that installed the driver: If the source product is still installed, update it to a current build that does not depend on psmounterex.sys. For example, Macrium Reflect X no longer uses this driver. The vendor's current release will normally remove the old driver during install. Reboot, then test a SyncBack VSS profile.
Option B - uninstall the source product: If the product is no longer needed, uninstall it through Settings >Apps (or Programs and Features), reboot, and re-run the Get-ChildItem command from Step 2 to confirm the .sys file is gone.
Option C - remove an orphaned driver: If the source product has already been uninstalled but the .sys file or service is still present, run the following in an elevated Command Prompt:
sc stop psmounterex
sc delete psmounterex
pnputil /enum-drivers
In the pnputil output, find the oemNN.inf entry whose Original Name is psmounterex.inf, then:
pnputil /delete-driver oemNN.inf /uninstall /force
Replace oemNN.inf with the actual entry from your machine. Finally, delete any remaining psmounterex.sys file and reboot.
VERIFY
After rebooting:
vssadmin list providers
vssadmin list writers
list providers should show only Microsoft Software Shadow Copy provider 1.0 (plus any other legitimate provider you intentionally use). All entries in list writers should be in the Stable state with No error.
Run a SyncBack profile that uses VSS. It should complete normally.
WHAT YOU SHOULD NOT DO
Two workarounds are circulating online. We do NOT recommend either of them for SyncBack users:
- Do not uninstall KB5083769. The update contains other security patches unrelated to this driver block. Removing it re-exposes the machine to those vulnerabilities.
- Do not disable the Microsoft Vulnerable Driver Blocklist via registry edits. The same blocklist is one of Windows' primary defences against "bring-your-own-vulnerable-driver" ransomware techniques. Turning it off to fix a backup issue is a poor security trade-off.
The correct fix is to remove the vulnerable driver from the system, not to disable the protection that blocks it.