[VSS] Why catalog is corrupted, and how to repair the corrupted Catalog?

Question

[VSS] Why catalog is corrupted, and how to repair the corrupted Catalog?

zihming 40

According to libvshadow document, the VSS volume header is stored at offset 0x1E00 and it contains catalog offset. The catalog contains information about the individual stores, serving as an another way to analyze shadow copies. However, we found that the data stored at catalog offset might not be a valid catalog. In our case, the data became a store header (identified by the header type field). We are not sure whether the problem lies in the outdated catalog offset or a process incorrectly writing data to the catalog offset. Even more surprisingly, the command vssadmin list shadows still works, and the system directory System Volume Information still contains a catalog file (allocated space starting from the catalog offset obtained from the VSS volume header) and shadow copy files.

We wonder why catalog is corrupted while the system executes normally, and how to fix this type of problem. Does Windows provide a method similar to chkdsk to check integrity of VSS formatted data in the volume?

0 comments

Answer accepted by question author

Jack Dang (WICLOUD CORPORATION) 18,970 Microsoft External Staff Moderator

Hi @zihming ,

Thanks for reaching out.

Windows does not provide a supported tool that repairs the internal VSS catalog in the same way that chkdsk repairs file system metadata. chkdsk can help confirm whether the NTFS volume itself is healthy, but it does not validate or rebuild VSS-specific on-disk structures such as the catalog, store metadata, or provider-maintained shadow copy data.

If the existing shadow copies are needed for investigation or recovery, preserve a full disk image before deleting anything, because the supported Windows remediation recreates VSS metadata rather than repairing the existing catalog in place.

The supported way to handle this kind of VSS metadata problem is to treat the affected shadow copies as disposable and recreate them. Before doing that, it is a good idea to check the underlying volume and the VSS state from Windows itself:

chkdsk C: /scan
vssadmin list writers
vssadmin list providers
vssadmin list shadows
vssadmin list shadowstorage

If chkdsk reports file system issues, repair those first, for example with chkdsk C: /f during a maintenance window if the volume needs to be locked or checked at reboot. After the file system is confirmed healthy, delete the affected shadow copies and let Windows or the backup application create new ones.

For client-accessible shadow copies, you can use:

vssadmin delete shadows /for=C: /oldest

or, if it is acceptable to remove all existing shadow copies for that volume:

vssadmin delete shadows /for=C: /all

If vssadmin reports that the snapshots are outside the allowed context, use diskshadow instead, since some shadow copies cannot be removed by vssadmin:

diskshadow
list shadows all
delete shadows all
exit

It is also worth checking the System and Application event logs for VSS and VolSnap events, confirming that the system is fully patched, and checking the storage layer for disk, controller, or SAN issues. Known VSS corruption patterns are typically addressed through Windows updates or storage fixes rather than by manually editing the VSS metadata.

One important note: the on-disk VSS format used by tools such as libvshadow is useful for analysis, but it is not a documented or supported on-disk contract for Windows, and its interpretation may not match how the VSS provider actually manages metadata. Windows does not rely solely on the catalog offset described in reverse-engineered formats, and it can enumerate shadow copies using provider-managed metadata and internal mechanisms. That is why a third-party parser may see data that looks inconsistent while vssadmin can still list or manage shadow copies through supported APIs. For production systems, the safe and supported recovery path is to verify the volume, remove the affected shadow copies, and recreate them.

Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Jack Dang (WICLOUD CORPORATION) 18,970 Reputation points Microsoft External Staff Moderator

2026-06-09T09:07:11.5666667+00:00

Hi @zihming ,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.
zihming 40 Reputation points

2026-06-10T02:51:20.1833333+00:00
Hi @Jack Dang (WICLOUD CORPORATION) ,

Thanks so much for getting back to me. We conducted several experiments and found some interesting behaviors.

First, attempted to reproduce the environment by modifying several fields in the Catalog header, such as the record type and current offset. We found that,

There are Volsnap events with ID 16, which recorded that shadow copies stored in the victim volume were aborted.

The command vssadmin list shadowstorage didn't list the victim volume.

The command vssadmin list volumes still listed the victim volume.

However, after several minutes, when we tried to create a shadow copy of the victim volume, the command succeeded. The command vssadmin list shadowstorage listed the victim volume, and vssadmin list shadows displayed the created shadow copy.

What surprised us most was that the Catalog header itself was not repaired. The fields still contained the wrong values, but the Catalog entries followed by the header were correct. All the offsets recorded by the Catalog entry pointed to the corresponding Store component, such as block list and bitmap.

Based on this behavior, it appears that modifications to the Catalog header are detected and may cause VSS to temporarily dismount or invalidate shadow-copy-related metadata for the volume. However, when creating a new shadow copy, VSS is still able to create a new Store and Catalog entry without accessing certain fields in the Catalog header, such as the record type and current offset.

We then investigated another scenario: modifying the 16-byte VSS GUID, which is stored at the beginning of each VSS block. The result was particularly interesting. After modifying this GUID, we observed that the Catalog offset stored in the VssVolumeHeader changed. VSS appeared to allocate a new location for the Catalog rather than reusing the existing one.

Our current inference is that VSS does not validate all fields in the Catalog header when processing shadow copies. Some fields appear to be critical and trigger recovery or relocation behavior when modified, while others can be corrupted without preventing VSS from creating and managing new shadow copies.

Could you provide any insights into which Catalog header fields are validated by VSS and which fields are considered non-essential during shadow copy creation and management?
Jack Dang (WICLOUD CORPORATION) 18,970 Reputation points Microsoft External Staff Moderator

2026-06-10T03:35:40.7766667+00:00
Hi @zihming ,

Thanks for sharing the additional test results.

Based on the behavior you observed, your inference is reasonable. However, Microsoft does not publish a field-by-field validation contract for the VSS on-disk Catalog header, so I cannot provide an authoritative list of which Catalog header fields are validated, ignored, or considered non-essential by VSS.

The supported VSS documentation describes VSS in terms of requesters, writers, providers, APIs, and administrative tools, rather than the internal on-disk Catalog layout:

Volume Shadow Copy Service documentation

Windows Server VSS overview

In general, the behavior suggests that fields used to identify or trust a VSS metadata block, such as the VSS block GUID/signature, are treated as more critical. If that identifier is changed, VSS may no longer trust the existing metadata and may allocate a new Catalog location instead. Other fields, such as the Catalog header record type or current offset, may not be required in the same way during the new shadow copy creation path, especially if VSS can create new provider metadata and valid Catalog entries.

That said, this should be treated as implementation-specific behavior, not a supported compatibility rule. A field that appears non-essential during shadow copy creation may still be checked during another operation, such as enumeration, deletion, reboot recovery, import, or provider cleanup. The supported creation and enumeration paths are through VSS APIs and tools such as vssadmin, diskshadow, and IVssBackupComponents::Query, not direct parsing or repair of Catalog header fields:

Shadow Copy Creation Details

IVssBackupComponents::Query

vssadmin

Diskshadow

In conclusion, VSS may tolerate or bypass some damaged Catalog header fields, but Windows does not document which fields fall into that category, and there is no supported method to classify or repair individual Catalog header fields. If the shadow copies are important for recovery or investigation, preserve a full disk image before making further changes.

If any part of the explanation helped address your question, I would greatly appreciate it if you could follow the instructions here. This can help other community members facing similar scenarios.

1 additional answer

Your answer

Jack Dang (WICLOUD CORPORATION) 18,970 Reputation points Microsoft External Staff Moderator

2026-06-09T09:07:11.5666667+00:00

Hi @zihming ,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.

Answer 1

Windows does not expose any public tool or API that validates or “repairs” the internal VSS on‑disk metadata (including the catalog) in the same way that chkdsk validates and repairs file system structures. VSS is designed so that normal backup and restore operations can proceed as long as the VSS infrastructure (writers, providers, requesters) and the underlying file system are healthy, even if individual shadow copies or their internal metadata become unusable.

Key points from the platform behavior:

VSS is a coordination layer over the file system
- VSS coordinates backup applications (requesters), applications being backed up (writers), and storage (providers) to create consistent point‑in‑time copies of data.
- The system provider uses a copy‑on‑write mechanism and a shadow copy storage area to maintain the logical point‑in‑time view of a volume.
- As long as the provider can maintain the copy‑on‑write data and the file system is consistent, VSS operations such as vssadmin list shadows can succeed, even if some internal metadata structures are not in the expected state for a third‑party parser.
Catalog and internal VSS metadata are not part of a public repair model
- The documented VSS model focuses on writers, providers, and requesters, not on direct manipulation or repair of the on‑disk VSS structures.
- There is no documented Windows utility that walks the VSS on‑disk format and repairs a “corrupted catalog” in the way chkdsk repairs NTFS metadata.
- If a particular shadow copy’s internal metadata is damaged, the supported remediation is to delete that shadow copy and create new ones, not to attempt in‑place repair.
Why the system can still operate when a catalog appears corrupted
- VSS shadow copies are exposed logically by the provider using the production volume plus the shadow copy storage area. The provider only needs its own internal structures to be sufficiently intact to reconstruct the snapshot view.
- A third‑party interpretation of the on‑disk format (for example, using an external specification) can disagree with what the provider actually uses internally or may encounter partially overwritten or reused regions that are no longer meaningful for analysis, even though VSS itself continues to function.
- Windows also includes in‑box VSS writers and uses VSS for features such as Windows Server Backup, Shadow Copies of Shared Folders, System Center Data Protection Manager, and System Restore. These features rely on the VSS APIs and provider behavior, not on external parsing of the VSS volume header and catalog.
Known corruption scenarios are handled via OS fixes, not user‑level repair tools
- When Microsoft has identified corruption patterns related to VSS (for example, issues where snapshots or backup data become inconsistent under certain volume‑extension patterns), the remediation has been delivered as OS updates to components such as volsnap.sys, not as a user‑run integrity checker for VSS metadata.
- In such cases, the guidance is to apply the relevant update and then recreate affected backups or shadow copies, not to repair the existing VSS structures.
Practical remediation for a suspected corrupted catalog Within the supported model, the only safe and supported actions are:
- Ensure the underlying file system is healthy by running chkdsk on the volume (this validates NTFS, not VSS structures).
- Delete affected shadow copies (for example, via vssadmin delete shadows) and allow Windows or the backup application to create new ones.
- Keep the system updated so that VSS components (volsnap.sys, swprv.dll) include all fixes for known corruption scenarios.

There is no Windows‑provided equivalent of chkdsk that inspects and repairs the internal VSS catalog or other VSS‑specific on‑disk metadata. Integrity is maintained by the VSS provider and the file system; when corruption is suspected, the supported approach is to remove and recreate shadow copies rather than repair them.

References:

Share via

[VSS] Why catalog is corrupted, and how to repair the corrupted Catalog?

1 additional answer

Your answer