Subject: Re: PSA: Windows shadow storage can silently consume all free disk space

On Sun, 2/22/2026 2:24 PM, Maria Sophia wrote:

PSA: Windows shadow storage can silently consume all free disk space

This is a public service announcement for anyone running Windows 10/11, especially on systems where Windows Update and System Restore are disabled
or rarely used, particularly if they're already also low on disk space.

I have had the same drive for over a decade, and while it has been tight on space for a long time, it always had at least a few GB free.
That was fine. Until today.

Today, I ran into a failure mode that can fill an entire disk without warning, without any obvious large files, and without the user having any direct control over it until the system is already out of space.

I checked all the normal places to clean up disk space. Anything I deleted kept the disk below limits for only a few minutes. Then the disk filled up again. I looked in all the usual spaces for the usual culprits (which I cal list separately in a followup article so others also know where to look).

Finally, I found the real cause.

ÿÿ C:\> vssadmin list shadowstorage /for=C:
ÿÿÿÿÿÿÿÿ Used Shadow Copy Storage space: 5.32 GB
ÿÿÿÿÿÿÿÿ Allocated Shadow Copy Storage space: 5.65 GB
ÿÿÿÿÿÿÿÿ Maximum Shadow Copy Storage space: 931 GB (100%)

Windows uses "shadow storage" for the Volume Shadow Copy Service (VSS).
Even with System Restore turned off, VSS is still active because Windows
uses it internally for NTFS metadata, snapshots, indexing & rollback mechanisms.

Under normal circumstances, shadow storage has a reasonable size limit. However, on some systems (especially ones with updates disabled), the
maximum size can get set to 100 percent of the drive. In my case, the
maximum shadow storage size was the full 931 GB.

This does *not* mean VSS was using 931 GB. It means Windows had permission
to reserve that much space for internal metadata. When the disk got tight, NTFS and VSS began reserving space aggressively, and the system eventually hit 0 bytes free.

At that point the system behaved as if the disk were completely full.ÿ
My first clue was that I could not save a 100-line text file in gVim.
Those last few gigabytes that had been stable for years were suddenly gone. After checking all the usual suspects and finding nothing of import, the problem eventually turned out to be a misconfigured VSS maximum size.

The fix was simple once I knew what to look for:

ÿÿ C:\> vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5GB

This forces Windows to cap shadow storage at a sane size and releases the reserved space immediately. After running it, the system recovered several gigabytes instantly, and returned to normal behavior.ÿ
Since it took longer to find the problem than to fix it, I am investing the energy to write up this PSA so as to post to Usenet in case it saves
someone else time.ÿ If your disk fills up mysteriously, and you cannot find any large files & all the usual cleanup steps fail, you might want to run:

ÿÿ C:\> vssadmin list shadowstorage /for=C:

If the "Maximum Shadow Copy Storage space" is set to 100 percent of the drive, you have found the culprit.

This is not user error. It is a Windows configuration quirk that can appear on long-running systems, especially when various common Microsoft services (updates, restore points, indexing, etc.) are disabled (as mine are).

For anyone tempted to reply with "you should have known" riddles or "this
is obvious" power plays, it was not obvious to me & I saw no warnings, and the behavior is not documented in any clear way that I am aware of.
We just have to know it.

If investing my valuable time into writing this post helps even one person avoid the same confusion, it has done its job, and I feel that I helped.

Note: this behavior is not limited to Windows 10. Windows 11 and recent Windows Server versions use the same VSS subsystem and can show the same failure mode if the shadow storage maximum size is misconfigured. --ÿ
This PSA is invested to pass along what I learned today, in case it helps.

vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Shadow Copy Storage association
For volume: (C:)\\?\Volume{0bd6166a-0836-4041-891c-792df2c72abd}\
Shadow Copy Storage volume: (C:)\\?\Volume{0bd6166a-0836-4041-891c-792df2c72abd}\
Used Shadow Copy Storage space: 0 bytes (0%)
Allocated Shadow Copy Storage space: 0 bytes (0%)
Maximum Shadow Copy Storage space: 2.37 GB (2%) <===

Shadow Copy Storage association
For volume: (H:)\\?\Volume{bd4d69bc-6fbb-4f12-b804-f32c6b9e828c}\
Shadow Copy Storage volume: (H:)\\?\Volume{bd4d69bc-6fbb-4f12-b804-f32c6b9e828c}\
Used Shadow Copy Storage space: 29.8 MB (0%)
Allocated Shadow Copy Storage space: 320 MB (0%)
Maximum Shadow Copy Storage space: 6.45 GB (5%) <===

I can see no contribution from File History to VSS, one way or another.

*******

https://forum.acronis.com/forum/acronis-true-image-2017-forum/questions-volume-shadow-copies?ckattempt=1

"Dang, I'm glad I read this. I disabled system protection long ago and didn't
think to even check. Like Karl, after the Windows creator update, system protection
was enabled and set to 100% and remains there. Luckily, it's not really using
much space at the moment, but am glad that I know to turn it off again.
"

That's a possible mechanism for the setting to be abnormally high. And that would
have happened a long time ago.

Some Windows features were removed, and whatever engineering went on there, is unlikely to be an issue today. Something was set at "30%" long ago, but
that may have been in Windows 8 era or so.

Generally, it's considered "bad" to create a control and then ram it
to the firewall. Usually some "reasoned" value is applied.

There are some aspects of shadow copies that don't work well,
and that would be "slow COW". Some people manage to have a
lot of shadows and apparently Acronis can do that. There was one
other backup program that did something similar.

Windows Server allows shadow copies to be moved to other disks, so
they're not on the same disk as the disk they cover. The desktop
clients don't have that feature code.

Paul

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)