Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error 0x80042313

0x80042313 and 0x80042314: VSS freeze and thaw timeouts on busy servers

11 min read Updated October 4, 2026 Windows Server: RDS, Hyper-V & Clustering

Fix it now

The snapshot was abandoned because the server could not be brought to a quiet point inside the time VSS allows. The freeze may not exceed 60 seconds and the provider has no more than 10 seconds to commit, and on saturated storage neither happens. Move the window and reduce what runs in it.

Run these in an elevated Command Prompt to rule out a stuck writer first

vssadmin list writers
vssadmin list shadowstorage
  1. Establish exactly when the failure happens and what else is running then. Compare the backup start time against every other scheduled job on the server.
  2. Measure disk latency across that window with the PhysicalDisk counters Avg. Disk sec/Read and Avg. Disk sec/Write, rather than reasoning from a daily average.
  3. Move the backup to a genuinely quiet period, and stagger it so no other snapshot-taking product runs at the same time.
  4. Stop optimisation work from overlapping: scheduled defragmentation, deduplication jobs and full antivirus scans.
  5. Reduce the number of volumes frozen together in a single snapshot set, so fewer writers have to reach a consistent state at once.

Look for a volume larger than 64 TB in the set before spending a night on scheduling. VSS is not supported on volumes above that size, and a backup with shadow copies enabled on one will fail however quiet the server is.

If the job completes on its new schedule and keeps completing for a week, you can stop here. The next section explains the two time limits that decide this.

Why it happens

Taking a shadow copy involves a brief but genuine pause. VSS asks the writers to quiesce, then holds incoming writes to the file system while the copy-on-write mechanism is armed. During that hold, applications wait, which is why the limits are short.

There are two limits and they cover different stages. The application freeze is not allowed to take longer than 60 seconds. The shadow copy creation period, during which all write I/O to the file system stays frozen, lasts no more than 10 seconds. Shadow copy creation is aborted if the writers are held frozen for longer than 60 seconds, or if the provider takes longer than 10 seconds to commit.

On a healthy server both complete with room to spare. The trouble starts when the disk subsystem is already at its limit: queued writes cannot be flushed inside the window, the file system never reaches a quiet point, and the operation is abandoned. That makes the failure a timing failure, which is why the same job succeeds at the weekend and fails on Monday night, and why the two codes here are worth much less than the clock.

Two products are snapshotting the same server at once

You have this one if Failures only on the nights both jobs are scheduled, and each product blames the other.

  1. List every product on the server that takes snapshots, including any host-level backup if this is a virtual machine.
  2. Stagger the schedules so only one requestor is active at a time, with a real gap between them.
  3. Where a guest is protected by both the host and an in-guest agent, choose one.
  4. Re-run both jobs on the new schedule and confirm neither fails.

The storage is saturated at the moment of the freeze

You have this one if Latency counters in the hundreds of milliseconds during the window, often with storage reset or retry events in the same period.

  1. Move the window to a genuinely quiet period rather than a nominally quiet one.
  2. Reduce concurrency: back up one volume set at a time instead of everything at once.
  3. Check the System log for Storport events 129 and 153 in the same window; a saturated or failing array causes far more than failed snapshots.
  4. Where the workload never goes quiet, split it across more storage or fewer roles per server.

Maintenance jobs overlap the backup

You have this one if Failures on a predictable day of the week, matching an optimisation or scanning schedule.

  1. Move scheduled defragmentation and optimisation clear of the backup window.
  2. On deduplicated volumes, check when optimisation and garbage collection run and separate them from the backup.
  3. Move antivirus full scans to a different day.
  4. Re-run and confirm the failure pattern breaks.

Rewriting jobs are worse than they look: work that rewrites whole files rather than editing them fills the shadow copy storage area as well as consuming I/O.

The volume cannot be shadow copied at all

You have this one if The failure is immediate and consistent rather than load dependent, and moving the window changes nothing.

  1. Check the volume’s size. VSS is not supported on volumes larger than 64 TB, and a backup with shadow copies enabled on one is outside support.
  2. Confirm the volume type is one the provider supports; network locations and some removable and non-NTFS volumes are not valid snapshot targets.
  3. Remove that volume from the backup set to confirm the diagnosis, then decide how its contents are protected instead.

Full reference

What is competing for the volume

Competing activity How it shows up
Another backup product taking its own snapshot Failures on the nights both jobs run
Host-level backup of a virtual machine Guest freeze failures with nothing wrong inside the guest
Scheduled defragmentation Heavy write churn against the same volume
Deduplication optimisation or garbage collection Sustained load on file server volumes
Antivirus full scan Read saturation across every volume at once
Database maintenance or index rebuilds One volume pinned at maximum latency
Replication catching up after an outage Load that appears on no schedule you keep

The two clocks, and which one you are missing

Stage Limit What exceeding it means
Application freeze 60 seconds A writer could not reach a consistent state in time; look at the application and its own load
Shadow copy commit, writes held 10 seconds The provider could not commit; look at storage latency and what else is writing

Neither is a value you tune. What you change is everything around them: when the snapshot is taken, how much is happening at that moment, how many volumes are frozen together, and how fast the storage underneath is. Chasing a registry value to lengthen the pause is the wrong instinct, and on a busy production server it would be the wrong outcome even if it worked – the pause is visible to users and to clustered applications while it lasts.

Reducing what has to happen at once

  • Split large backup sets so fewer volumes are frozen together. A set that covers three volumes has to quiesce three at the same moment.
  • Separate the workloads that keep the volume busy from the ones being backed up, where the server hosts several roles.
  • Where a database is involved, check whether a long-running transaction or an index rebuild overlaps the window – the writer cannot reach a consistent state while one is in flight.
  • Confirm the shadow copy storage area has room. A snapshot that is abandoned for space looks very like one abandoned for time, and the association figures tell you which.

Sizing the problem honestly

Faster storage does fix this, because the failure is queued writes that cannot be flushed in time. That is worth knowing before you spend a week rearranging schedules on storage that is genuinely at its limit. It is equally worth knowing that a different backup product will not: every backup product on Windows uses the same freeze, and a product that appears to succeed where another failed is usually taking a crash-consistent copy instead, which is a different guarantee rather than a better one.

On the codes themselves

None of the four codes on this page has a published meaning, and the fifth entry, event 8224, has no published message text either. What Microsoft does publish is the mechanism: the 60-second and 10-second limits, the abort condition, and the guidance that where a timeout is caused by limited storage throughput the answers are to spread the load across disks, move the job to a quieter time, or use faster storage. Work from that rather than from the number, and treat any confident published-sounding gloss on these codes as somebody’s inference.

When a licence is the actual fix

Rescheduling a backup and moving an optimisation job cost nothing, and for most servers that is the whole fix. A purchase only enters the picture when the honest answer is that one machine is being asked to do too much at once and no window exists in which it is quiet enough to snapshot. Splitting the busiest role onto its own instance gives the backup a volume it can actually freeze, and that instance needs a licence: Windows Server Standard covers two virtual machines plus one Hyper-V host per licence, Datacenter covers unlimited virtual machines plus one Hyper-V host. Arco supplies Windows Server 2025 Standard and will check what your current licences already entitle you to run first.

Every code this article covers

Code What it points at Source
0x80042313 Seen where a snapshot is abandoned at the quiesce stage. Microsoft publishes the flush-writes timeout condition under a symbolic constant but not this hexadecimal value, so diagnose from the 60-second and 10-second limits rather than from the code not published by the vendor
0x80042314 The companion failure at the same stage. Microsoft publishes the matching message – the shadow copy provider timed out while holding writes to the volume, probably because of excessive activity – without attaching this hexadecimal value to it not published by the vendor
0x8004230C Reported where the volume cannot be shadow copied at all rather than merely not in time. Microsoft documents the unsupported-volume condition under a symbolic constant, but does not publish this hexadecimal value not published by the vendor
0x80780049 A Windows Server Backup failure recorded when the snapshot stage did not complete. No published meaning; read the accompanying VSS events for the reason not published by the vendor
Event ID 8224 Logged by the VSS service. Microsoft publishes no message text for this ID, so do not read a fault into it on its own; it is only interesting if it appears in the middle of a backup window not published by the vendor

Confirm the fix worked

  1. The backup completes on its new schedule and the snapshot stage passes.
  2. Disk latency during the window stays inside the range your storage vendor considers normal.
  3. No other snapshot requestor runs in the same window.
  4. vssadmin list shadowstorage shows the associations had room throughout.
  5. A full week of scheduled runs completes, since one successful night does not settle a timing failure.

Questions people ask about this

Can I extend the freeze window?

It is not a setting you should be looking for. The limits are short because applications are paused while they run, and lengthening the pause would trade a failed backup for a visible stall in production. Reduce the load instead.

Why does it work at the weekend and fail on weekdays?

Because it is a load problem. The same job, the same configuration and the same storage behave differently when the server is busy, which is the clearest single signal that you are looking at contention rather than a fault.

Would faster storage fix it?

Usually, yes. The freeze fails when queued writes cannot be flushed in time, and Microsoft’s own guidance where throughput is the constraint is to spread the load across disks, move the job to a quieter time, or move to storage that can serve more I/O.

Does buying a different backup product help?

No. Every backup product on Windows uses the same VSS freeze and meets the same limits. A product that appears to succeed where another failed is usually taking a crash-consistent copy, which is a different guarantee, not a better one.

The volume is 80 TB. Is that relevant?

Very. VSS is not supported on volumes larger than 64 TB – that covers enabling it, creating writable snapshots, shadow copies for shared folders, backups with shadow copies enabled, and chkdsk. No amount of scheduling changes that.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Event ID 1511 and 1515: RDS users land in a temporary profile every logon License Error HTTP 502.5 and 500.30: ASP.NET Core apps fail to start behind IIS Free Fix RD Web Access broken: HTTP 500.100, HTTP 404.17 and Event ID 1309 explained License Error Event ID 25 and 0x80780119: shadow storage runs out and snapshots vanish
← Back to Knowledge Base