From Newsgroup: alt.comp.os.windows-11

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Maria Sophia wrote:

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).

While this PSA describes a Windows shadow-storage setting that can quietly consume remaining disk space & how to correct it with a single command,
below is a list of the classic places to check for storage hogs (AFAIK).

These are ranked (by me) by likelihood & impact (risk for mass deletion):

Impact = how large it can get (which can be safely deleted, IMHO)
Risk = how dangerous it is to delete or modify (low, medium, high, IMHO)

HIGH IMPACT (can consume tens or hundreds of GB)
Windows Installer cache (MSI/MSP) [H]
C:\Windows\Installer

Windows Search index database [M]
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb

DriverStore (FileRepository) [H]
C:\Windows\System32\DriverStore\FileRepository

Hyper-V virtual disks [L]
%PUBLIC%\Documents\Hyper-V\Virtual Hard Disks

Docker / WSL2 virtual disks [L]
%LOCALAPPDATA%\Docker
%LOCALAPPDATA%\Packages\CanonicalGroupLimited*

VirtualBox VMs [L]
%USERPROFILE%\VirtualBox VMs

VMware VMs [L]
%USERPROFILE%\Documents\Virtual Machines

Paging file (pagefile.sys) [H]
C:\pagefile.sys

System memory dump (MEMORY.DMP) [L]
C:\Windows\MEMORY.DMP

MEDIUM IMPACT (can grow large)
Windows Update working folder [M]
C:\Windows\SoftwareDistribution

Windows Installer rollback backups [M]
C:\Windows\Installer\$PatchCache$
C:\Windows\Installer\*.rbs
C:\Windows\Installer\*.rbf

System Restore snapshots [M]
C:\System Volume Information

Windows Event Logs [M]
C:\Windows\System32\winevt\Logs

Hibernation file (hiberfil.sys) [H]
C:\hiberfil.sys

LOW IMPACT (common, small, safe to delete)
User temp files [L]
%temp%

System temp files [L]
C:\Windows\Temp

Extra temp folders [L]
%LOCALAPPDATA%\Temp
C:\Temp

Crash dumps (apps and services) [L]
%LOCALAPPDATA%\CrashDumps
C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps

Windows Error Reporting [L]
%LOCALAPPDATA%\Microsoft\Windows\WER
%PROGRAMDATA%\Microsoft\Windows\WER

Browser caches [L]
%LOCALAPPDATA%\Microsoft\Edge\User Data
%LOCALAPPDATA%\Google\Chrome\User Data
%APPDATA%\Mozilla\Firefox\Profiles

Windows Update download cache [L]
C:\Windows\SoftwareDistribution\Download

Delivery Optimization cache [L]
C:\Windows\SoftwareDistribution\DeliveryOptimization

Microsoft Store / UWP data [L]
%LOCALAPPDATA%\Packages

Package Cache (VS, .NET, etc.) [L]
C:\ProgramData\Package Cache

CBS and DISM logs [L]
C:\Windows\Logs\CBS
C:\Windows\Logs\DISM

Application logs [L]
C:\ProgramData\*\Logs
%LOCALAPPDATA%\*appname*\Logs

Windows.old (rollback) [L]
C:\Windows.old

Setup logs [L]
C:\Windows\Panther
C:\Windows\inf\setupapi.dev.log

WPR traces [L]
%LOCALAPPDATA%\Microsoft\Windows\WPR

Reliability Monitor [L]
C:\ProgramData\Microsoft\RAC\PublishedData

Media Player thumbnails [L]
%LOCALAPPDATA%\Microsoft\Media Player

Old .etl logs [L]
C:\Windows\System32\LogFiles\WMI
C:\Windows\System32\LogFiles\NetSetup

Delivery Optimization logs [L]
C:\ProgramData\Microsoft\Windows\DeliveryOptimization

Windows Defender history [L]
C:\ProgramData\Microsoft\Windows Defender

Prefetch [L]
C:\Windows\Prefetch

Crashpad dumps [L]
%LOCALAPPDATA%\Crashpad

Large app caches (Adobe, Unity, Steam) [L]
%APPDATA%\Adobe
%LOCALAPPDATA%\Unity
%LOCALAPPDATA%\Steam
%PROGRAMDATA%\Steam

Shader caches [L]
%LOCALAPPDATA%\Steam\htmlcache
%LOCALAPPDATA%\NVIDIA\DXCache
%LOCALAPPDATA%\NVIDIA\GLCache

Driver installer caches [L]
C:\NVIDIA
C:\AMD
C:\Intel

Useful commands

Disk Cleanup:
cleanmgr

Remove superseded updates:
dism /online /cleanup-image /startcomponentcleanup

Show largest folders under C:
powershell -c "gci C:\ -Directory | sort length -desc | ft name,length"

Show largest files on the entire drive
powershell -c "gci C:\ -Recurse -File -ea SilentlyContinue | sort length -desc | select -first 20 | ft length,fullname -auto"

Show largest folders under a specific path
powershell -c "gci 'C:\path' -Directory | % { $_.FullName; gci
$_.FullName -Recurse -File | measure length -sum }"

Check shadow storage usage
vssadmin list shadowstorage /for=C:

Resize shadow storage to a sane limit
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5GB

Show disk usage by folder (PowerShell 5+)
powershell -c "gci C:\ -Directory | % { '{0,10:N2} GB {1}' -f ((gci $_.FullName -Recurse -File | measure length -sum).sum/1GB), $_.FullName }"

Show Windows Update download cache size
powershell -c "(gci C:\Windows\SoftwareDistribution\Download -Recurse
-File | measure length -sum).sum/1GB"

Clear Windows Update download cache
net stop wuauserv & net stop bits & rd /s /q C:\Windows\SoftwareDistribution\Download & net start wuauserv & net start
bits

Show size of the Windows Search index
powershell -c "(gci 'C:\ProgramData\Microsoft\Search\Data\Applications\Windows' -Recurse -File
| measure length -sum).sum/1GB"

Show size of DriverStore
powershell -c "(gci C:\Windows\System32\DriverStore\FileRepository
-Recurse -File | measure length -sum).sum/1GB"

Show size of pagefile and hibernation file
dir C:\pagefile.sys
dir C:\hiberfil.sys

Show size of MEMORY.DMP
dir C:\Windows\MEMORY.DMP

Show size of Windows.edb
dir
"C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb"

Show size of System Volume Information (admin only)
dir "C:\System Volume Information"

Show size of event logs
powershell -c "gci C:\Windows\System32\winevt\Logs | sort length -desc | select -first 20 | ft name,length"

Show size of CBS.log
dir C:\Windows\Logs\CBS\CBS.log

Show size of DISM logs
dir C:\Windows\Logs\DISM

Show size of Windows.old
dir C:\Windows.old

Show size of a folder (quick)
powershell -c "(gci 'C:\path' -Recurse -File | measure length
-sum).sum/1GB"

Confirm whether something is currently exploding in size
Win+R > resmon > Disk > [sort by] Total (B/sec)
Look for something like...
SearchIndexer.exe > Windows.edb corruption
svchost.exe (netsvcs) > Windows Update stuck
OneDrive.exe > sync loop
MsMpEng.exe > Defender logs
chrome.exe > runaway cache
System > pagefile or memory dump
TiWorker.exe > update cleanup
vmwp.exe > Hyper-V checkpoint explosion
vmmem > WSL2 disk expanding
etc.

In addition, I've written system-specific scripts, which check my own
system (since I employ a highly-organized structure) for size hogs.
--
These are learned by experience, & hence I would want others to benefit.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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.

-a-a C:\> vssadmin list shadowstorage /for=C:
-a-a-a-a-a-a-a-a Used Shadow Copy Storage space: 5.32 GB
-a-a-a-a-a-a-a-a Allocated Shadow Copy Storage space: 5.65 GB -a-a-a-a-a-a-a-a 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.-a
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:

-a-a 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.-a
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.-a If your disk fills up mysteriously, and you cannot find any large files & all the usual cleanup steps fail, you might want to run:

-a-a 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. ---a
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
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Paul wrote:

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.

Hi Paul,

Wow. That was refreshing! It's exciting to learn from a Usenet response!

Thanks for posting your numbers as we can all work together as a well-honed team given each of our setups have been modified over many years.

What you're showing above is actually the "normal" case, AFAICT, and it
helps confirm the point of the PSA for a properly set up Windows box.

Your C: drive has a maximum shadow storage size of 2.37 GB (about 2%).
Your H: drive has a maximum of 6.45 GB (about 5%).

Since VSS always reports the maximum shadow storage size as a percentage of
the drive it's associated with, not a percentage of used space, free space,
or anything else, your "2.37 GB (2%)" means, I think, that your C: drive is roughly 118 GB in total size and your "6.45 GB (5%)" on H: means that H:
drive is roughly 129 GB in total size (AFAICT).

Both of those sets of numbers appear to me to be sane, bounded values.
They likely won't run away and consume either of your entire disks.

In my case, the "Maximum Shadow Copy Storage space" was set to 100% of the drive. I don't know why. I don't know how. I didn't even know to look.

Now I do know how to look, which is the main point of this helpful PSA:

vssadmin list shadowstorage /for=C:

The output doesn't mean VSS was using what it reports, but only that
Windows was allowed to reserve that much if it wanted to. Once the disk got tight, VSS and NTFS metadata allocation pushed right up against that limit
and the last few GB vanished instantly, while I was editing a text file.

Your output on a better-set-up PC shows the opposite situation than mine.
Your max size is capped, so even if VSS wanted more space, it can't exceed those limits on your machine so you won't likely see the same behavior.

Your additional helpful note about File History is apropos for this PSA.]

Looking it up, apparently Windows File History uses its own storage
mechanism & hence, it doesn't contribute to VSS usage. The two systems are separate. I didn't realize it existed until you pointed it out. Thanks.
Win+R > FileHistory
Reported:
a. No file history was found
b. File History is currently turned off.
c. Configure File History settings'
d. Control Panel\All Control Panel Items\File History

It's probably important to note that it seems, after looking it up, that
File History does not use VSS shadow storage as it uses a normal folder structure on whatever drive we selected as the File History target.
<drive>:\FileHistory\<username>\<computername>\Data\

I'm not exactly sure what FileHistory is useful for, but it seems to be a lightweight, automatic backup system for our personal files.
a. It's apparently not the whole system
b. Nor the installed programs
c. And certainly not the Windows installation itself
d. But... it seems to know what is your "user data"

In fact, it seems to be kind of sort of a set of versioned copies of our Documents, Pictures, Desktop, etc., stored on another drive. Is it?
i. C:\Users\<you>\Documents
ii. C:\Users\<you>\Pictures
iii. C:\Users\<you>\Desktop
iv. C:\Users\<you>\Music
v. C:\Users\<you>\Videos
vi. C:\Users\<you>\Favorites
vii. C:\Users\<you>\AppData\Local\Microsoft\Windows\Libraries

I don't use the official folders in C:\Users so my data will all be stored
on C:\data\{my folder hierarchy that makes sense to me over the decades}
So FileHistory won't back them up unless I add those folders to a library.

Good to know.
Thanks for adding topical helpful value to this PSA about shadow copies.

It keeps older versions too, so we can apparently restore yesterday's copy
of a file we accidentally overwrote. It seems nice. If we have the space.

In addition to your helpful information about VSS and File History,
that Acronis quote you found lines up with what I ran into. Some Windows updates in the past (Creators Update era, Windows 8 era, etc.) were known
to reset the shadow storage maximum to very large values, sometimes 100%.

If that happened years ago and nobody noticed, the system would run fine
until the disk finally got tight, and then the problem would appear
suddenly. Certainly my system dates to 2009 so it has had many updates.

So your numbers look good. Mine were simply misconfigured, probably from something long ago. The PSA is just to help people check that setting in
case they hit the same failure mode.

Thanks again for the data point as it's wonderfully exciting to communicate with people who want to add helpful value so as to benefit all who read it.
--
We're each here to learn and help others & to ask for help when needed.
--- Synchronet 3.21b-Linux NewsLink 1.2