XPost: alt.comp.os.windows-10, alt.comp.microsoft.windows   
   From: nospam@needed.invalid   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)