TL;DR: Numbered folders such as C:\ClusterStorage.000 or C:\ClusterStorage.001 next to the normal C:\ClusterStorage folder are leftover copies of the CSV namespace root. They are usually harmless, but deleting one that is still referenced can take virtual machines or platform components offline — so leave them in place until you have proved nothing points at them.

Recommended action:

Removing these folders is optional. A leftover root that nothing references is cosmetic, has no effect on cluster health or performance, and can be left in place indefinitely. Cleaning it up is housekeeping, not remediation — there is no deadline and no benefit that justifies rushing it. Several of these accumulating over many months, one per solution update, each holding only a small breadcrumb of a few hundred bytes, is the most common shape in the field and is benign on its own.

What is worth doing is checking whether anything still references one, particularly as part of update readiness. That check is read-only, runs online, and needs no maintenance window. If it finds a reference, that reference needs to be corrected regardless of whether you ever remove the folder — a stale path is what breaks a solution update later.

If you do decide to remove one, every condition below must hold first. Microsoft publishes the detection and cleanup commands, and maintains them, in its official troubleshooting guide: Troubleshoot ghost CSV mount points. Use that as the authoritative procedure.

  1. The numbered folder is not the live namespace. Every active Cluster Shared Volume must report a path under C:\ClusterStorage. If an active CSV reports a path under a numbered root instead, that folder is not a leftover — it is the namespace currently in use, and it must not be touched.

  2. Nothing inside the folder redirects to a real volume. A leftover root can still contain mount points that resolve to live storage, which is the difference between deleting an empty shell and detaching a production volume. The reliable test is the ReparsePoint file attribute, checked recursively rather than at the top level only — a mount point can sit nested inside an ordinary-looking leftover folder, and a top-level check would misclassify it as inert files. The LinkType and Target properties do not populate consistently for volume mount points, so a folder that really does front live data can easily look like inert leftovers.

  3. No virtual machine has a disk pointing at the numbered path — checked on every node, not only the one you happen to be signed in to, and following each disk's full parent chain. An attached disk can sit on a healthy CSV while one of its checkpoint or differencing parents is still on a numbered root. Deleting that root breaks the chain and the child disk becomes unusable, so checking attached paths alone can report clean on a cluster that has a blocking reference.

  4. No virtual machine has its configuration, checkpoint, or smart paging path pointing at the numbered path. A VM can have entirely healthy disks and still be anchored to a leftover root by one of these three properties, since each is recorded independently.

  5. No machine holds an open file handle under the numbered path. An open handle from another host indicates something is actively using the location right now.

  6. No cluster resource references the numbered path. This one is cluster-wide rather than per-node, and it is the check most often skipped. Per-node inspection only sees virtual machines currently resident on that node, so a clustered VM owned by a different node, or a role that is powered off, can hold a reference that every per-node pass misses.

  7. The contents are ordinary leftovers, not live platform data. Inventory what is actually inside the folder first, and look at what the content is rather than only where it sits. An Infrastructure_1 folder inside a numbered root is expected and is not on its own a reason to contact support — a cluster that has taken several updates commonly accumulates one small, stale breadcrumb per root. What does warrant support is real platform working data: any virtual hard disk (.vhd, .vhdx, .avhd, .avhdx, .vhds, .vhdpmem), or a MocArb, ImageStore, or WorkingDirectory folder. A reference from any earlier condition that points under Infrastructure_1 is likewise a support case rather than a self-service cleanup.

  8. The checks were repeated immediately before acting. Cluster state changes, particularly if a solution update or a failover occurred in between. A clean audit from yesterday is not a clearance today.

  9. Every check actually completed. Treat a check that could not run as a reference, not as a pass. A node that was unreachable, a query that failed, a virtual disk whose parent chain could not be read — each of these means coverage is incomplete, and an incomplete audit cannot clear a folder for deletion.

If any of these conditions fail, the folder is in use. Leave it alone until whatever references it has been repointed at the correct CSV path. If a reference involves the reserved infrastructure volume or platform components, or if you are unsure which situation applies, contact support rather than proceeding — the cost of asking is minutes, and the cost of deleting a referenced root is an outage.

Why:

Cluster Shared Volumes are presented to every node through a single common namespace on the system drive. C:\ClusterStorage is an ordinary directory that the Cluster service owns and fills with one mount point per CSV.

When a CSV is brought online on its owner node, the Cluster service initializes that namespace root. If the initialization fails because another process is holding an open handle on the directory at that exact moment, the Cluster service does not fail the operation. Instead, it renames the directory it could not use out of the way to the next free numbered name and creates a fresh C:\ClusterStorage to work with. The usual culprits holding that handle are antivirus, endpoint protection, and filter-driver products, along with backup and monitoring agents.

The result is a cluster that keeps working, so nothing obviously breaks at the time, plus an old directory that survives on disk under a numbered name. Anything that recorded an absolute path while the old directory was the live root is now pointing at a stale location.

This is filesystem and cluster state on each node's system drive. It is not a hardware fault, and no OEM, BIOS, or firmware action is required to resolve it.

Why deleting them without verification is dangerous:

A numbered root that nothing references is cosmetic clutter. The risk comes from what may still be pointing at it, and from what may still be inside it:

  • The folder may still redirect to live storage. Numbered roots can retain mount points that resolve to a real volume, and a recursive delete follows those redirections into production data.

  • Virtual machines may still resolve their storage through the stale path. Disks, configuration, checkpoints, and the smart paging file are each recorded as absolute paths and can be anchored independently of one another.

  • Platform operations can break rather than a single VM. Where the stale reference involves the reserved infrastructure volume, a solution update can fail part-way through, or Arc Resource Bridge can fail to start or redeploy.

  • Differencing disk chains can break. Having more than one mount point for what should be a single CSV means a virtual disk's parent locator can resolve through the wrong one, which surfaces later as a failed checkpoint merge or a missing parent disk.

  • The resulting failure will not point back at the deletion. Errors caused by this condition name a path, not a cause, which makes the connection between a cleanup and an outage days later very easy to miss.

  • Wildcard filters are hazardous here. A pattern such as ClusterStorage.* also matches the live root C:\ClusterStorage, because Windows treats the part after the dot as an optional extension. Any command written against these folders needs to match a literal dot followed by digits, or it will target the production CSV root along with the leftovers.

Going forward:

  • Exclude the CSV path from antivirus, backup, and monitoring agents on every node. This is the single most effective prevention, because a scanner holding a handle on the CSV root is the common trigger. Microsoft publishes the required exclusions, including %SystemDrive%\ClusterStorage, in its recommended antivirus exclusions for Hyper-V hosts. Apply the same thinking to any other agent that walks the filesystem, not to antivirus alone.

  • Check before and after every solution update. Folding this into update readiness catches a stale reference while it is still cheap to fix, rather than mid-update.

  • Investigate recurrence instead of repeatedly cleaning up. If new numbered roots appear after each update or restart, something is still holding an open handle when the Cluster service re-establishes the namespace. Identify which agent is running at that moment and exclude the path.

  • Keep VM storage on the canonical path. When creating or importing a VM, target C:\ClusterStorage\<volume>\... explicitly rather than accepting a recorded absolute path from another system.

  • Do not create your own folders next to the CSV root using a numbered name, as both this guidance and cluster tooling will treat them as leftovers.

Optional details:

This condition is invisible in most of the places an administrator would normally look. The numbered folders do not appear in Failover Cluster Manager, which shows CSVs by friendly name and state rather than the filesystem layout of the system drive. They do not appear in Windows Admin Center or in the Azure portal either — the only indirect portal signal is a failed solution update, which does not name the folder.

There is also no dedicated Windows event that records the rename. CSV trouble often shows Events 5120 and 5142, but those are I/O availability events: their presence is not proof that a numbered root exists, and their absence is not proof that none does. Inspecting the system drive directly is the only definitive test.

The creation timestamp on a numbered root usually lines up with the update or restart that produced it, which is the quickest way to correlate the condition with the operation that caused it.