Helpdesk: "FS01's nightly Windows Server Backup failed again. Last night it said 'There is not enough disk space to create the volume shadow copy on the storage location,' the night before it was 'Windows Backup failed to get an exclusive lock on the EFI system partition (ESP),' and the backup disk still has 1.2 TB free. A forum thread says to delete every shadow copy, run wbadmin delete catalog, and reinstall the Windows Server Backup feature. Can we just do that tonight?"
Don't run any of that yet. "Windows Server Backup failed" is a wrapper, and the line underneath it tells you which layer actually broke. Microsoft's own troubleshooting article for Windows Server Backup says it plainly: "Windows Server Backup relies on multiple layers in the operating system to function. It can show errors when any of those layers report an error." Deleting shadow copies, wiping the catalog, and reinstalling the feature all hit the wrong layer for most of those errors, and two of them throw away things you may not get back. Work through it as a chain: the exact message, the hex code, the event ID, and which job failed → the job history and the Backup events (wbadmin get versions, Get-WBJob, the Microsoft-Windows-Backup log) → the backup target: is it there, writable, and big enough? → the source volumes and their shadow copy storage, including the small hidden partitions → the VSS writers and the services behind them → access denied and the EFI system partition lock → network share targets → the backup engine, the schedule, and the catalog. wbadmin, Get-WBSummary, Get-WBJob, Get-WBPolicy, Get-WinEvent, vssadmin list writers, vssadmin list shadowstorage, Get-Volume, and Get-Partition are the sources for that chain. Reinstall the feature and the next run fails the same way, only now without the old backup history.
If the failing item is a Hyper-V virtual machine and the error comes from the Hyper-V VSS writer or a checkpoint, read Hyper-V Checkpoint Operation Failed after this one; it covers guest VSS, the integration service, and restarting VSS and its provider in depth, so this post doesn't repeat that. If a SQL Server on the same box is involved, SQL Server Transaction Log Full (Error 9002) covers the log-backup side. This post covers "a Windows Server Backup job (scheduled, one-time, system state, or bare metal) fails with 'failed to create shadow copy,' 'not enough space,' 'failed to get an exclusive lock on the EFI system partition,' 'access is denied,' 'the device is not ready,' or 'there are no more files,' and you need a read-first path through the events, the target, shadow copy storage, the VSS writers, permissions, network shares, and the backup engine before you delete shadow copies, delete the catalog, or reinstall anything."
TL;DR
- The first error isn't always the cause. Microsoft's method: check the Backup events, then "Identify which application or layer caused the issue," then read that layer's own events, and repeat until you reach the root cause.
- "Not enough space" usually means a source volume, not the backup disk. Microsoft's minimums for shadow copy creation: "For volumes less than 500 megabytes, the minimum is 50 megabytes of free space. For volumes more than 500 megabytes, the minimum is 320 megabytes of free space." Small hidden partitions are the usual suspects (our reading).
-
One failed writer fails the whole job. Microsoft: "If any of the VSS writers encounter an error, the entire backup job will fail." Run
vssadmin list writersright after a failure. - An EFI lock is usually another program on the ESP. Microsoft's Azure Backup page: the EFI system partition lock "can be due to system partition access by a third-party security or back up software."
- Network shares keep one copy. Microsoft: back up the same computer to the same remote shared folder again and "you will overwrite your previous backup."
-
Deleting is permanent. Microsoft: "Deleting a shadow copy is permanent." And after
wbadmin delete catalog, you can no longer reach that computer's backups from the snap-in.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact message, hex code, event ID, job type, and target written down | "Backup failed" with nothing else |
| 2. Job history and events | Last success known; the failing layer named in the events | Event 517 or 521 with a code nobody looked up |
| 3. Backup target | Target online, writable, and big enough | "No target could be found"; "the device is not ready"; space on the target |
| 4. Source volumes and shadow storage | Every volume in the backup has room for its shadow copy | "Not enough disk space to create the volume shadow copy" with a mostly empty backup disk |
| 5. VSS writers | Every writer stable; VSS services can start | "Failed to create shadow copy"; 0x807800A1; a writer in [9] Failed
|
| 6. Access and the ESP | Elevated, right group, SYSTEM on System Volume Information, ESP not held | "Access is denied"; "failed to get an exclusive lock on the EFI system partition" |
| 7. Network share target | Share reachable, writable, not overwritten mid-job |
0x80070012 "There are no more files"; network target not writeable |
| 8. Engine, schedule, catalog | Engine service starts; schedule exists; catalog readable | Engine could not be contacted; schedule not found; WSB won't start after a restore |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Shadow copies gone, catalog gone, still failing |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| The exact message, word for word | "Not enough space" and "access is denied" each have several different sources (Steps 3, 4, 6) |
| The hex or decimal error code | Microsoft's tables map codes like 0x807800A1 to a layer (Step 2) |
| The event ID and log | 517, 521, 5, 49, 50, and 564 each point at a different step |
| Which job | Scheduled, one-time, system state, or bare metal (-allCritical). Each touches different volumes |
| The target type | Dedicated disk, volume, or remote shared folder. Network targets have their own rules (Step 7) |
| Every night, or now and then? | Every run reads as a configuration or space problem. Random runs read as a lock, a timeout, or contention (our reading) |
| What changed? | New AV or EDR agent, new app with a VSS writer, disk swap, BIOS-to-UEFI move, a restore, a new share |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
"A Volume Shadow Copy Service operation failed" or 0x807800A1
|
VSS or a writer. Microsoft's message says to check the "VSS" and "SPP" application logs | Steps 2, 5 |
| "There is not enough disk space to create the volume shadow copy" | A source volume is short on free space for its shadow copy. Microsoft says it "applies to both the backup storage destination and volumes included in the backup" | Step 4 |
| "Backup failed as required space was not available on the backup target" (event 50) | The target itself is full | Step 3 |
| "Failed to get an exclusive lock on the EFI system partition" | Something else is holding the ESP during the snapshot | Step 6 |
| "Access is denied" with no ESP wording | Elevation, group membership, System Volume Information, a writer's own access, or the share | Steps 5, 6, 7 |
| "The device is not ready" or "no target could be found" | The target disk went offline, slept, or was swapped | Step 3 |
0x80070012 "There are no more files" to a share |
The share target and the SMB client cache | Step 7 |
| "System writer is not found in the backup" | The System Writer itself, usually permissions (Microsoft KB) | Step 5 |
| Engine could not be contacted; WSB won't start after a bare metal restore | The engine service or the catalog | Step 8 |
Step 2: Read the job history and the Backup events (read-only)
Start with what Windows Server Backup already knows. Microsoft: Get-WBSummary returns "the next scheduled backup, details of the last backup, and details of the last successful backup," and Get-WBJob -Previous 10 "gets the status of the last 10 backup or recovery jobs from the backup events in the event manager."
# Read-only, elevated, on FS01. What ran, what failed, what's scheduled
Get-WBSummary
Get-WBJob -Previous 5
Get-WBPolicy
# Read-only. Backups the catalog knows about, and where they live
wbadmin get versions
One trap: Microsoft says wbadmin get versions with no parameters "lists all backups of the local computer, even if those backups are not available." A version in that list isn't proof the disk is attached or the files are readable (our reading). Add -backupTarget:E: to read the target itself.
If a job is running now, wbadmin get status shows it. Microsoft: "This command doesn't stop until the backup or recovery operation is finished." Press Ctrl+C to leave it; don't use wbadmin stop job to get your prompt back, because "Canceled operations can't be restarted."
Then the events. The Application log carries Microsoft-Windows-Backup events (Microsoft's KB samples show 517 and 521 there), and Microsoft's DPM article shows event 5 in a log named Microsoft-Windows-Backup:
# Read-only. Backup failures in the Application log, last 14 days
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = 'Microsoft-Windows-Backup'
StartTime = (Get-Date).AddDays(-14)
} -ErrorAction SilentlyContinue | Where-Object LevelDisplayName -eq 'Error' |
Select-Object TimeCreated, Id, Message | Format-List
# Read-only. The Backup operational channel (log name from Microsoft's DPM sample)
Get-WinEvent -LogName 'Microsoft-Windows-Backup' -MaxEvents 30 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
# Read-only. Turn a decimal code from the message into hex (our helper)
'{0:X}' -f 2155348129
That last line prints 807800A1, the code in Microsoft's own table below (our arithmetic). Microsoft's error-list tables give codes in both forms, so either one works for the lookup.
Microsoft's Windows Server 2008 operations page lists the Backup events. It's old, but later Microsoft KBs and Microsoft Q&A threads on Windows Server 2022 still show the same 517 and 521 IDs:
| Event | Microsoft's message (trimmed) | Read it as |
|---|---|---|
| 4 | "Backup finished successfully." | The good one. Your confirm in Step 9 |
| 5 / 517 | "Backup started at '%1' failed with following error code '%2' (%3)." | Generic failure. Read the code and the text in brackets |
| 9 / 521 | "failed as Volume Shadow copy operation failed for backup volumes" | VSS. Go to Step 5 |
| 17 / 544 | "failed because Windows Backup engine could not be contacted" | The engine service (Step 8) |
| 18 / 545 | "failed because the schedule settings was not found" | The schedule (Step 8) |
| 20 / 518 | "failed as another backup or recovery is in progress" | Overlap with another job or product |
| 21 / 528 | "Scheduled backup configuration conflicts with group policy settings" | A Backup policy setting (Step 8) |
| 49 / 561 | "Backup failed as no target could be found." | Target missing or offline (Step 3) |
| 50 | "Backup failed as required space was not available on the backup target." | Target full (Step 3) |
| 52 / 564 | "Backup task failed as the configured network target is not writeable." | Share permissions (Step 7) |
Microsoft's layered method, from the Windows Server Backup VSS troubleshooting article: read the Backup failure event, "Identify which application or layer caused the issue," check that application's own events, and "Repeat step 2 and step 3 until you get to the root cause of the problem and then correct the problem." Its sample walks from a Backup event to a VSS event to the Hyper-V VMMS log and finally to a "not enough disk space" VSS event inside one guest. The backup error on the host said none of that.
| Code (Microsoft's tables) | Microsoft's message | Layer |
|---|---|---|
0x807800A1 |
"A Volume Shadow Copy Service operation failed. Please check "VSS" and "SPP" application event logs for more information." | VSS (Step 5) |
0x8078008a |
"The read operation from the volume shadow copy on one of the source volumes failed." | A source volume (Steps 4, 5) |
0x800423F3 |
"The writer experienced a transient error. If the backup process is retried, the error may not reoccur." | A writer, retry first |
0x800423F4 |
"The writer experienced a non-transient error. If the backup process is retried, the error is likely to reoccur." | A writer, find which one |
0x80042319 |
"A writer did not respond to a GatherWriterStatus call." | A stuck writer |
0x81000101 |
"The creation of a shadow copy has timed out. Try this operation again." | Timing or load (Step 5) |
The text log Windows Server Backup writes for system state jobs is also worth a look. Microsoft's KB shows C:\Windows\Logs\WindowsServerBackup\SystemStateBackup_Error <DateTime>.log as the list of files that failed.
Step 3: The backup target (read-only)
# Read-only. Disks Windows Server Backup can see right now
wbadmin get disks
Get-WBDisk
# Read-only. Where the policy sends backups
$policy = Get-WBPolicy
Get-WBBackupTarget -Policy $policy
# Read-only. Free space on the target volume (E: here)
Get-Volume -DriveLetter E | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining, Size
# Read-only. Backups actually stored on that target
wbadmin get versions -backupTarget:E:
Microsoft: Get-WBDisk "gets a list of internal and external disks that are online for the local computer." A scheduled target that isn't in that list explains events 49 and 561 (our reading).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
Target disk missing from wbadmin get disks
|
Offline, unplugged, or swapped. "The device is not ready" usually lands here | Reconnect or replace it, then re-read |
| A USB target that fails only some nights | Power management or a flaky enclosure | Check the System log for disk events at backup time |
| Target present, event 50 | The target really is full | Step 9: space or retention on the target |
-backupTarget points at a volume that's also in the backup |
Microsoft: a critical-volume target "can't be any of the volumes that are included in the backup" | Pick a different target |
| A system state backup to the system volume | Microsoft's KB 944530 (Windows Server 2008 and 2008 R2) blocks it by default and needs "twice the amount of free space as the size of the system state backup" if you allow it | Use a separate volume |
Step 4: Source volumes and shadow copy storage (read-only)
This is where most "not enough space" tickets end. The VSS message Microsoft quotes is "There is not enough disk space to create the volume shadow copy on the storage location," and Microsoft adds: "This applies to both the backup storage destination and volumes included in the backup." Its minimums:
| Volume size | Microsoft's minimum free space for shadow copy creation |
|---|---|
| Under 500 MB | 50 MB |
| Over 500 MB | 320 MB |
| Over 1 GB | "It is recommended that least 1 gigabyte of free disk space on each volume" (sic) |
A bare metal or all-critical backup includes the small partitions too: the EFI system partition, a recovery partition, or a System Reserved partition. Those are the volumes that run short of 50 or 320 MB, while C: and the backup disk look fine (our reading). Read them all, with sizes:
# Read-only. Every partition with its size and free space, including the hidden ones
Get-Partition | ForEach-Object {
$v = $_ | Get-Volume -ErrorAction SilentlyContinue
[pscustomobject]@{
Disk = $_.DiskNumber
Partition = $_.PartitionNumber
Type = $_.Type
Letter = $_.DriveLetter
SizeMB = [math]::Round($_.Size / 1MB)
FreeMB = if ($v) { [math]::Round($v.SizeRemaining / 1MB) } else { $null }
FS = $v.FileSystem
}
} | Format-Table -AutoSize
# Read-only. Which volumes the scheduled backup includes, and which ones Windows calls critical
Get-WBVolume -Policy (Get-WBPolicy)
Get-WBVolume -CriticalVolumes
The join and the selected properties are ours. Microsoft's Get-WBVolume page: it can show "volumes included in the WBPolicy object, all critical volumes, all volumes, or volumes in the WBDisk object."
Then the shadow copy storage itself. Microsoft: "A shadow copy storage association links a volume that has shadow copies to the volume that stores those copies, and reports the disk space that storage uses."
# Read-only. Where shadow copy storage lives, its used/allocated/maximum size, and existing copies
vssadmin list shadowstorage
vssadmin list shadows
vssadmin list volumes
What Microsoft's VSS overview says about that storage (the "diff area"):
| Question | Microsoft's answer |
|---|---|
| Where can it live? | "it must be located on an NTFS volume that has enough space to store it" |
| How is the location chosen? | An existing shadow copy's location first, then a manual association, then free space |
| What happens when it runs out? | "Shadow copies for the volume are deleted, beginning with the oldest shadow copy." |
And the system event Microsoft quotes when a backup can't grow that storage: "There was insufficient disk space on volume C: to grow the shadow copy storage for shadow copies of C: due to this failure all shadow copies of volume C: are at risk of being deleted."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| A recovery or System Reserved partition under 50 MB free (or under 320 MB on a larger one) | Below Microsoft's minimum for that size | Step 9: free or grow that partition, or exclude it if it isn't critical |
| C: nearly full; the backup disk empty | The source, not the target | Step 9: free space on C: |
list shadowstorage shows a small maximum, nearly all used |
The diff area is capped too low for the night's changes | Step 9: resize after a read |
| Many old shadow copies on a source volume | Previous Versions or another tool keeps its own copies. They share the diff area | Find the owner before you delete any |
| The failure is inside a Hyper-V guest | Microsoft's sample traces it to free space in the guest | Read the Hyper-V checkpoint post Steps 3 and 5 |
Step 5: VSS writers and the services behind them (read-only)
Microsoft's VSS overview names four parts: the VSS service, the requester (here, Windows Server Backup), writers ("The component that guarantees you have a consistent data set to back up"), and providers. Then the timing that matters in a busy window: "The application freeze isn't allowed to take longer than 60 seconds," and "The shadow copy creation period lasts no more than 10 seconds." Past either limit, Microsoft says the shadow copy creation can be aborted.
Run these right after a failure, before anything restarts:
# Read-only, elevated. Writer state and last error, providers, and the services VSS needs
vssadmin list writers
vssadmin list providers
Get-Service -Name VSS, swprv, EventSystem, SENS, RpcSs, CryptSvc, wbengine |
Select-Object Name, DisplayName, Status, StartType
# Read-only. VSS events around the failure, last 2 days (read SPP and the System log's VolSnap the same way)
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = 'VSS'
StartTime = (Get-Date).AddDays(-2)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, LevelDisplayName, Message -First 20 | Format-List
Microsoft's Azure Backup system state page lists the services Windows Server Backup depends on:
| Service | Startup type (Microsoft) |
|---|---|
| Remote Procedure Call (RPC) | Automatic |
| COM+ Event System (EventSystem) | Automatic |
| System Event Notification Service (SENS) | Automatic |
| Volume Shadow Copy (VSS) | Manual |
| Microsoft Software Shadow Copy Provider (SWPRV) | Manual |
VSS and swprv showing Stopped between jobs is normal for Manual services (our reading). Disabled is not.
Then read the writer list. Microsoft's own sample output shows the two states that matter, State: [1] Stable and State: [9] Failed, with a Last error line under each.
| Writer finding | What Microsoft says | Next |
|---|---|---|
| The SQL Server writer failed, SQLWRITER and SQLVDI errors in the Application log | KB 2615182: "Usually, the problematic SQL Server instance will be named in the first recorded SQLVDI error." | Find the instance and database first (Step 9) |
System Writer missing from the list; "System writer is not found in the backup" |
KB 2009272: "The system writer fails because permissions to files in the %windir%\winsxs\filemaps\ or %windir%\winsxs\temp\PendingRenames directories are incorrect." Look for CAPI2 event 513 | Step 9, after you confirm the event |
System Writer still missing; VSS event 8213 names NETWORK SERVICE |
Same KB: the writer's host process "does not run under a user with sufficient access rights" | The VssAccessControl value in Step 9 |
Microsoft Hyper-V VSS Writer failed |
The VM layer. Microsoft's sample traces it into one guest | The Hyper-V checkpoint post |
Writer error 0x800423f2, "the writer's time-out expired between the Freeze and Thaw events." |
Azure Backup page: "VSS writer is unable to complete in time due to lack of CPU and memory resources on the machine" or "Another backup software is already using the VSS writer" | Move the window or stop the overlap |
| Third-party writer failed | Microsoft's VSS FAQ, for non-Microsoft backup software that fails with a VSS error: check that company's support site for a product update. The same habit fits a vendor's writer (our reading) | That vendor's guidance |
| Every writer stable, backup still fails at the snapshot | Not a writer. Look at space (Step 4) and providers |
vssadmin list providers for a SAN or vendor provider |
One rule from Microsoft's SQL KB is worth keeping for any writer: "the first step would be to test the backup with that SQL Server instance stopped." In other words, prove the writer is the cause by taking it out of one test run (our generalization). For restarting VSS and swprv themselves, the Hyper-V post's Step 9 has the -WhatIf forms.
Step 6: Access denied and the EFI system partition lock (read-only)
"Access is denied" has at least five different owners in Windows Server Backup:
| Where the denial comes from | What Microsoft says | Check |
|---|---|---|
You, running wbadmin
|
Members of Backup Operators or Administrators, and "you must run wbadmin from an elevated command prompt" |
whoami /groups; an elevated window |
| System Volume Information | "Ensure that the Local SYSTEM has full control on the System Volume Information folder located in the volume where Windows is installed." and "Windows Server backup can fail if the permissions above aren't set correctly." | Read the ACL (below) |
| The System Writer | CAPI2 event 513: "BeginFileEnumeration() failed. System Error: Access is denied." | Step 5 |
| A network share | Event 564: "Please ensure user '%3' has write permissions on the target." | Step 7 |
| The EFI system partition | "System state backup operation failed as the EFI system partition is locked." | This step |
# Read-only. Your groups, and the ACL on System Volume Information (display only)
whoami /groups | Select-String -Pattern 'Administrators|Backup Operators'
icacls 'C:\System Volume Information'
# Read-only. The EFI system partition: present, sized, and on which disk
Get-Partition | Where-Object Type -eq 'System' | Select-Object DiskNumber, PartitionNumber, Size, GptType
# Read-only. When the ESP lock failures happen, and what else ran then (517s with ESP text)
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Microsoft-Windows-Backup'; Id = 517 } -MaxEvents 20 -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'EFI' } | Select-Object TimeCreated, Message
The icacls read and the Type -eq 'System' filter are ours. On a GPT disk the ESP is usually the partition Windows labels System (our reading).
The ESP lock. Microsoft's Azure Backup troubleshooting page gives the cause: "This can be due to system partition access by a third-party security or back up software." Its fixes are to have the security vendor allow the backup, and if another backup product is running, "wait for it to finish and then retry backup." Microsoft Q&A threads describe the same error as intermittent on Windows Server 2022, logged as event 517 (community threads, not a Learn reference page). One accepted answer says "a workaround from MS has been applied": a scheduled task that reruns the backup when event 517 appears.
| ESP finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Fails every night | Something holds the ESP on a schedule: an EDR scan, another backup agent, a disk tool | Find it, then exclude or reschedule (Step 9) |
| Fails once or twice a month, retry works | The intermittent pattern in the Q&A threads | A retry task is a workaround, not a fix. Keep watching |
Step 7: Network share targets (read-only)
Windows Server Backup to a share has rules a local disk doesn't:
- One copy. Microsoft: "If you save your backup to a remote shared folder, and then perform another backup to the same computer and the same remote shared folder, you will overwrite your previous backup." And: "If your backup operation fails, you can end up without a backup because the older backup is overwritten, but the newer backup isn't usable."
-
One location.
wbadmin enable backup: "You can only specify one shared folder as a storage location at a time." -
Credentials. The
-useryou supply needs write permission to the folder. With-noInheritAcl, only those credentials, Administrators, or Backup Operators on the file server can read the backup.
# Read-only. Can this server reach and list the share, as the account you're logged on with?
Test-Path -Path '\\NAS01\WSB'
Get-ChildItem -Path '\\NAS01\WSB\WindowsImageBackup' -ErrorAction SilentlyContinue | Select-Object Name, LastWriteTime
# Read-only. SMB client cache and session timeout values (names from Microsoft's tuning page and DPM KB)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters' -ErrorAction SilentlyContinue |
Select-Object DirectoryCacheLifetime, SessTimeout
Test-Path runs as you, not as the backup account, so a pass here doesn't prove the backup's credentials can write (our note).
| Share finding | Source | Next |
|---|---|---|
Event 517 with 0x80070012 ("There are no more files") on a share target |
A Microsoft Japan Windows support team blog post (May 2025) ties it to a stale SMB client directory cache, and reports that setting DirectoryCacheLifetime to 0 plus a restart avoided it |
Step 9, on the backed-up server only |
0x8078015B "Windows Backup encountered an error when accessing the remote shared folder." with SMB client event 30809 |
Microsoft's DPM article: "This issue occurs if the input/output (I/O) latency is greater than the standard SMB time-out (60 seconds)." Written for DPM and Azure Backup Server shares | Look at the file server's storage latency first |
| Event 52 or 564 | Microsoft's event text: the network target "is not writeable" | Share and NTFS permissions for the backup account |
| Old backup gone after a failed run | The overwrite rule above | Subfolders per run, with Microsoft's "twice the space" note |
Microsoft's tuning page lists DirectoryCacheLifetime as "Directory cache timeout in seconds," default 10. It's a client-wide SMB setting, so it affects every share that server uses, not just the backup (our reading).
Step 8: The engine, the schedule, and the catalog (read-only)
The engine is the wbengine service. Microsoft: "The WBENGINE service is used by Windows Backup to perform backup and recovery operations." Its default startup type is Manual, so it's often stopped between jobs (our reading of Microsoft's services table).
# Read-only. Feature installed? Engine service state? Schedule task present?
Get-WindowsFeature -Name Windows-Server-Backup
Get-Service -Name wbengine | Select-Object Name, Status, StartType
schtasks /query /tn "\Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup" /v /fo list
# Read-only. Backup policy settings from Group Policy, if any GPO sets them
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Backup\Server' -ErrorAction SilentlyContinue
The task path comes from the Microsoft Q&A threads in Step 6. The policy registry path is our reading. Microsoft's policy location is Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Backup\Server.
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| Events 17 / 544, engine could not be contacted | The engine service didn't answer. Microsoft's 544 text: "Please check if engine service is installed and enabled." | Check wbengine isn't Disabled |
| Events 18 / 545, schedule settings not found | Microsoft: "Please re-configure scheduled backup." | Re-create the schedule from the read in Step 2 |
| Events 21 / 528, conflict with Group Policy | A Backup policy setting forbids what the schedule asks for | Change the schedule or the GPO, not both |
| WSB won't start after a bare metal restore on UEFI | KB 2961238: Wbengine.exe "does not handle cases correctly when the EFI system partition location is changed during the restore" | The catalog rebuild in Step 9 |
wbadmin get versions errors, other targets still hold good backups |
A damaged local catalog (our reading) |
wbadmin restore catalog from that target before you delete anything |
Get-WBJob errors as an unknown command |
Microsoft's Azure page: reinstall the Windows Server Backup feature | The one case where a reinstall is Microsoft's step |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
vssadmin delete shadows /all "to free space" |
Microsoft: "Deleting a shadow copy is permanent." You lose Previous Versions and anything else that depends on them, and the real shortage may be a 300 MB partition | Step 4: find the volume that's short, and who owns the copies |
wbadmin delete catalog first |
Microsoft: after you delete it, "you'll no longer be able to get to any backups created for that computer using the Windows Server Backup snap-in." Microsoft says to use it only when the catalog is corrupted and can't be restored | Step 8: wbadmin restore catalog from a target that still has backups |
| Reinstalling the Windows Server Backup feature | Doesn't touch VSS, space, the ESP, or the share. Microsoft's reinstall step is for a missing Get-WBJob
|
Steps 2-7 |
-vssFull while another product backs up SQL or Exchange on that server |
Microsoft: "Don't use this parameter if you are using a product other than Windows Server Backup to back up apps that are on the volumes included in the current backup." It can break that product's log chain | Keep the default -vssCopy
|
fsutil usn deletejournal on System Reserved because a forum said so |
Microsoft's caution: deleting the change journal "impacts the File Replication Service (FRS) and the Indexing Service" and forces a complete rescan of the volume | Step 4: read the partition's free space and its contents first |
/MaxSize=UNBOUNDED on every volume |
Shadow storage can then grow until the volume is full (our reading of "no limit" in Microsoft's syntax) | A sized maximum on a volume with room |
| Disabling VSS | Microsoft: "you shouldn't do this. Disabling VSS adversely affects any software you use that depends on it, such as System Restore and Windows Server Backup." | Fix the failed writer or the space |
| Turning off AV or EDR for every backup | Leaves the server unprotected every night, and the ESP lock may come from another program | Step 6: find what holds the ESP, then a vendor-documented exclusion |
| A retry task with nobody watching | Hides a real, repeating failure behind a second run (our reading) | Keep it only for the intermittent ESP pattern, and keep reading events |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1-8 point at. Most of these tools have no dry-run switch, so the read in Steps 2-8 is your dry run. Export a registry key before you change it:
# Low-risk write. Save the VSS and SMB client keys before you change them (our habit)
reg export HKLM\SYSTEM\CurrentControlSet\Services\VSS C:\Temp\vss-before.reg /y
reg export HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters C:\Temp\lanmanws-before.reg /y
A source volume short on space (Step 4). Free space on that volume first. For the shadow copy storage itself, Microsoft's command, after vssadmin list shadowstorage:
# Change. Cap shadow storage for C: on C: at 20% (Microsoft's example form). No dry-run switch
vssadmin resize shadowstorage /For=C: /On=C: /MaxSize=20%
Microsoft's warning: "Resizing the storage association may cause shadow copies to disappear." Read vssadmin list shadows first and decide whether you can lose them. For a hidden recovery or System Reserved partition under Microsoft's minimum, growing it means repartitioning, which is its own change window (our reading). If it isn't a critical volume, excluding it from a volume backup is the smaller change.
Delete only the copies you've identified (Step 4). Microsoft's form targets one ID, after you confirm it with vssadmin list shadows:
# Change. Permanent. One client-accessible shadow copy, by ID
vssadmin delete shadows /for=c: /shadow=<ShadowID>
Microsoft: "You can only delete shadow copies with the client-accessible type." Copies outside that context need diskshadow, and they usually belong to some other product (our reading).
A failed SQL writer (Step 5). Microsoft's KB test: run one backup with the named instance stopped, in a window where that's acceptable. The service name below is an example:
# Change, in a maintenance window. Dry-run first; MSSQL$FINANCE is an example instance
Stop-Service -Name 'MSSQL$FINANCE' -WhatIf
If the backup completes with it stopped, Microsoft says to "examine the SQL Server error log files and the event logs" for that instance. Fix the database, then start it again. Don't leave it stopped as the "fix."
System Writer missing, CAPI2 513 confirmed (Step 5). Microsoft's KB 2009272 resolution, unchanged:
Takeown /f %windir%\winsxs\temp\PendingRenames /a
icacls %windir%\winsxs\temp\PendingRenames /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\temp\PendingRenames /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\temp\PendingRenames /grant "BUILTIN\Users:(RX)"
Takeown /f %windir%\winsxs\filemaps\* /a
icacls %windir%\winsxs\filemaps\*.* /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\filemaps\*.* /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\filemaps\*.* /grant "BUILTIN\Users:(RX)"
net stop cryptsvc
net start cryptsvc
Then vssadmin list writers should show System Writer. If it's still missing and VSS event 8213 names NETWORK SERVICE, the same KB sets NT AUTHORITY\NETWORK SERVICE (REG_DWORD) to 1 under HKLM\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl. The PowerShell form is ours, with a real -WhatIf:
# Change. Dry-run first; export the VSS key above before you run it for real
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl' -Name 'NT AUTHORITY\NETWORK SERVICE' -Value 1 -Type DWord -WhatIf
The ESP lock (Step 6). Work through it in this order: find the program that holds the ESP, then apply that vendor's documented exclusion or move its schedule away from the backup. Microsoft's Azure page also says to let a running third-party backup finish first. If it's still intermittent after that, the Microsoft Q&A workaround is a task that reruns the backup when event 517 appears. It's community-posted, so test it on one server and keep reading the events:
schtasks /create /F /RU SYSTEM /RL HIGHEST /SC onevent /EC Application /MO "*[System[Provider[@Name='Microsoft-Windows-Backup'] and (EventID=517)]]" /TN "Microsoft\Windows\Backup\Retry_Backup" /TR "schtasks /run /tn \"Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup\""
The thread also enables "Allow task to be run on demand" on the Microsoft-Windows-WindowsBackup task first. Our caution: event 517 is also the generic failure event, so this task reruns every kind of failure, not just the ESP one.
A share target (Step 7). For overwrites, give each run its own subfolder, sized for Microsoft's "twice the space" note, or move to a dedicated disk. For the 0x80070012 pattern, the Microsoft Japan support blog's workaround is a client-wide SMB change, so apply it to the backed-up server only, then restart:
# Change, on FS01 only. Dry-run first; Microsoft's tuning page default is 10 seconds
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters' -Name DirectoryCacheLifetime -Value 0 -Type DWord -WhatIf
For 0x8078015B against a DPM or Azure Backup Server share, Microsoft's KB adds SessTimeout = 1200 under the same key and restarts the server or the Workstation service. Our reading: fix the file server's storage latency first, and use the timeout only for that DPM case.
The catalog after a bare metal restore (Step 8). Microsoft's KB 2961238 resolution: run wbadmin delete catalog from an elevated prompt, then restart the Windows Server Backup service or the computer. That's the documented case. Anywhere else, try wbadmin restore catalog from a target that still holds backups first, and take a new backup right after, as Microsoft's delete catalog page recommends.
Then prove it with one run. With no parameters, wbadmin start backup uses the scheduled backup's settings, so it tests the same job that failed. For a domain controller's system state, Microsoft's command:
# Change (it writes a backup). Rerun the scheduled job's settings now
wbadmin start backup
# Change (it writes a backup). A DC system state test to a separate volume
wbadmin start systemstatebackup -backupTarget:E: -quiet
Read-only confirm afterwards:
# Read-only. Last job result, the new version, writer state, and the success event
Get-WBJob -Previous 1
wbadmin get versions -backupTarget:E:
vssadmin list writers
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Microsoft-Windows-Backup'; Id = 4 } -MaxEvents 3 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message
Watch one full scheduled night too. Event 4 ("Backup finished successfully."), a new version on the target, every writer [1] Stable, and nothing new from VSS or VolSnap. Then restore one file from the new version with wbadmin get items -version:<VersionIdentifier> and a test recovery. A backup that has never been restored is a guess (our view).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Hidden partition under Microsoft's free-space minimum | Free or grow that partition in a change window; exclude it if it isn't critical | Deleting every shadow copy on the server |
| Shadow storage capped too low |
vssadmin resize shadowstorage after reading list shadows
|
UNBOUNDED on a nearly full volume |
| SQL writer failing | Test with that instance stopped, then fix the database | Leaving SQL stopped, or -vssFull next to another product |
| System Writer missing, CAPI2 513 | Microsoft's KB 2009272 permissions, then VssAccessControl if 8213 |
Reinstalling the feature |
| ESP lock every night | Find the program holding the ESP, then a vendor exclusion | AV off every night |
| Share target overwritten | Subfolders or a dedicated disk | Same folder every night |
0x80070012 to a share |
DirectoryCacheLifetime 0 on the backed-up server only |
Changing it fleet-wide |
| WSB won't start after a UEFI bare metal restore |
wbadmin delete catalog per KB 2961238, then a new backup |
Deleting the catalog for any other error |
FAQ
Why does Windows Server Backup fail to create a shadow copy?
Usually one of three things: a source volume without enough free space for its shadow copy (Microsoft's minimums are 50 MB on volumes under 500 MB and 320 MB on larger ones), a VSS writer in a failed state, or a timeout under load. Run vssadmin list writers right after the failure, read the VSS events, then check free space on every partition in the backup, including the hidden ones.
Why does Windows Server Backup say not enough space when the backup disk has plenty?
Because the message is usually about the source. Microsoft says the shadow copy space rule "applies to both the backup storage destination and volumes included in the backup." Check every partition with Get-Partition and Get-Volume, and check shadow storage with vssadmin list shadowstorage. Event 50 is the one that means the target itself is full.
How do I fix "Windows Backup failed to get an exclusive lock on the EFI system partition"?
Find what else is touching the ESP during the backup. Microsoft's Azure Backup page names third-party security or backup software. Get a documented exclusion from that vendor, or move the other job's schedule. If it stays intermittent, Microsoft Q&A threads describe a task that reruns the backup on event 517. Treat that as a workaround and keep reading the events.
Where are the Windows Server Backup logs and event IDs?
The Application log, source Microsoft-Windows-Backup (517 for a failure with a code, 521 for a VSS failure, 4 for success), plus the Microsoft-Windows-Backup channel. System state jobs also write text logs under C:\Windows\Logs\WindowsServerBackup. Then read the layer the event names, in that layer's own log.
Can Windows Server Backup keep multiple versions on a network share?
Not in one folder. Microsoft: another backup of the same computer to the same remote shared folder "will overwrite your previous backup," and a failed run can leave nothing usable. Use subfolders, sized for about twice the space, or a local backup disk, which doesn't carry that overwrite rule (our reading of Microsoft's remote-folder remarks).
Related posts
- Hyper-V Checkpoint Operation Failed (guest VSS, the Hyper-V VSS writer, and restarting VSS and swprv when a VM is the failing item)
- SQL Server Transaction Log Full (Error 9002) (the log-backup side when a backup product and SQL disagree about who truncates logs)
- Retention Is Not Backup (the restore-drill habit that proves a backup works before you need it)
Free checklist
A backup nobody has test-restored is a change nobody piloted. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=windows-server-backup-failed
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: Get-WBSummary, Get-WBJob, Get-WBPolicy, Get-WBBackupTarget, Get-WBDisk, Get-WBVolume, wbadmin get versions / get disks / get status, Get-WinEvent, vssadmin list writers / providers / shadows / shadowstorage / volumes, Get-Volume, Get-Partition, Get-Service, Get-WindowsFeature, whoami /groups, icacls (display only), Test-Path, Get-ChildItem, Get-ItemProperty, and schtasks /query. reg export writes local files. Resizing shadow storage, deleting shadow copies, stopping SQL Server, the KB 2009272 permission changes, VssAccessControl, DirectoryCacheLifetime, SessTimeout, retry tasks, deleting or restoring the catalog, and running a backup are deliberate changes. Change one layer at a time, test on one server first, and check current Microsoft Learn for version-specific behavior.
Top comments (0)