Windows 11 Hard drive filling up unaccountably

• Install and run WinDirStat or TreeSize Free (both show a visual breakdown so you can click into the big blocks and see exact paths). This will immediately show whether C:\Windows\WinSxS, C:\Windows\SoftwareDistribution, C:\Windows.old, a VHDX, or another folder is the space hog. Do this first.

• Open an elevated Command Prompt (Run as administrator) and run:
  vssadmin list shadowstorage
  That shows how much space VSS is reserving. If it’s dozens of GB you can reduce it, or delete old shadow copies (but that removes restore points). Guidance for this step is commonly recommended.

• In an elevated Command Prompt run:
  DISM.exe /Online /Cleanup-Image /AnalyzeComponentStore
  If it says the component store can be cleaned, run:
  DISM.exe /Online /Cleanup-Image /StartComponentCleanup
  For a deeper (irreversible) cleanup:
  DISM.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase
  This is the supported way to shrink WinSxS after lots of updates; it can reclaim many GBs but /ResetBase prevents uninstalling earlier updates afterwards.

• Open Disk Cleanup as admin (Start → Disk Cleanup → select C: → “Clean up system files”) and check “Previous Windows installation(s)” and “Windows Update Cleanup”. That safely removes Windows.old and update installers. Storage Sense / Cleanup Recommendations can also help but Disk Cleanup (system files) is the classical route.

• Run these searches in an elevated PowerShell or use Everything search:
  • Search for large virtual disks: .vhdx, .vhd, *.vmdk
  • Search for Windows search DB and other big files: Windows.edb (ProgramData\Microsoft\Search), pagefile.sys, hiberfil.sys
• Example PowerShell to list top 20 largest files:
  
  Code:

  Get-ChildItem -Path C:\ -Force -Recurse -ErrorAction SilentlyContinue |
  Where-Object { -not $_.PSIsContainer } |
  Sort-Object Length -Descending |
  Select-Object FullName, @{Name='MB';Expression={[math]::Round($_.Length/1MB,2)}} -First 20

  WSL’s ext4.vhdx (often in %userprofile%\AppData\Local\Packages*wsl*\LocalState) can be very large and will show up here if present.

• If you don’t use hibernate, turn it off to remove hiberfil.sys:
  powercfg /hibernate off
  That frees roughly the size of RAM. For pagefile.sys, Windows usually manages it; moving or shrinking it is possible but riskier — ask before changing.

• Stop Windows Update service, delete SoftwareDistribution\Download contents, restart service:
  
  Code:

  net stop wuauserv
  rd /s /q C:\Windows\SoftwareDistribution\Download
  net start wuauserv

  This removes downloaded update installers and can free space. (Disk Cleanup also covers this.

• Disk Cleanup (system files) will remove it safely. If it’s confirmed you don’t need to revert an upgrade/major update, delete it.

• It may be a process creating large temporary files or a background backup service. Use Resource Monitor / Process Explorer and check Disk activity (which processes are writing most). Any backup software, VM software, or OneDrive sync settings? Also check OneDrive Files On‑Demand: Storage Sense can convert local OneDrive files back to online‑only to free space.

• Run WinDirStat (or TreeSize) and tell me which top folders inside C:\Windows (or other folders) are largest — or paste a screenshot of the WinDirStat treemap.
• Paste the output of:
  • vssadmin list shadowstorage and
  • DISM.exe /Online /Cleanup-Image /AnalyzeComponentStore (if you run it).
    If you paste those outputs I’ll give exact cleanup commands tailored to the results.

• Always use Disk Cleanup (system files) to remove Windows.old and update cleanup rather than deleting system folders manually.
• Don’t delete WinSxS files by hand — use DISM.
• Reducing shadow storage or deleting restore points will remove restore options — back up first if you want to keep points.

• Let it finish uninterrupted — large folders with many small files take a long time. Antivirus can slow it; if you trust the backup drive you can temporarily pause real‑time AV scanning (remember to re-enable it).
• If the copy fails or stalls, stop and use robocopy (reliable, resumable). Example from an elevated Command Prompt:
  robocopy "C:\Windows\Installer" "E:\InstallerBackup" /E /COPYAT /R:2 /W:5 /V /LOG:C:\InstallerCopy.log

• After the copy completes, verify sizes match. In PowerShell (run as admin) you can compare summed bytes:
  $s=(Get-ChildItem -Path C:\Windows\Installer -Recurse -Force | Measure-Object Length -Sum).Sum; $d=(Get-ChildItem -Path E:\InstallerBackup -Recurse -Force | Measure-Object Length -Sum).Sum; $s, $d
• If the two numbers match (or are very close), the backup is good.

• Use Start → Disk Cleanup → right‑click → Run as administrator → select C: → check “Windows Update Cleanup”, “Previous Windows installation(s)” (if present), and other temporary categories. Let it finish.
• After it completes, reboot and then run WinDirStat again to confirm reclaimed space and that C:\Windows\Installer is still the large folder (or reduced).

• Don’t panic — you can restore individual .msp files from your external backup by copying them back into C:\Windows\Installer and then rerun the uninstall/repair. If you moved the whole folder back and still have problems, restore the entire backup.
• If an error appears for a specific program, try Repair from Programs & Features first; if that fails restore the corresponding .msp from your backup.

• Keep the external backup for at least 2–4 weeks while you use the PC normally. If nothing fails, you can permanently delete the backup (or keep an image/archive elsewhere).

• Tell me what Disk Cleanup removed and the new free space. If more is needed we can:
  • Run DISM component cleanup (DISM /Online /Cleanup-Image /StartComponentCleanup)
  • Check shadow storage (vssadmin list shadowstorage) and reduce if necessary
  • Use PatchCleaner in “move” mode (it will move orphaned .msp/.mst files to your backup drive) — I can walk you through that.

• The WinDirStat treemap or the top 20 results of the PowerShell listing I gave previously, and
• The change in free space after Disk Cleanup.

• Leave the system alone for now and don’t delete your external backup yet. Keep it for at least 2–4 weeks while you verify everything works.
• Many programs will continue to run fine until you try to repair/uninstall/update them. The biggest risk is only when an app or Windows needs those .msp files.

• Open several programs you use often (Office, Adobe, antivirus, any specialized apps) and perform basic actions.
• Run Windows Update (Settings → Update & Security → Windows Update) and let it check/download/install any updates. Watch for installer/patch errors.
• Try one or two app uninstalls or repairs (Programs & Features → select app → Repair/Uninstall) — don’t do all of them, just test one to see if an error appears. If you see an error about a missing installer patch or missing file, note the file name.

• Restore the specific .msp/.msi from your external backup back into C:\Windows\Installer. That usually fixes the issue immediately. Use File Explorer with admin privileges or an elevated robocopy for reliability:
  • Example (open an elevated Command Prompt and run):
    robocopy "E:\InstallerBackup" "C:\Windows\Installer" *.msp /COPYAT /R:2 /W:5 /V /LOG:C:\InstallerRestore.log
  • Or to restore everything (slower):
    robocopy "E:\InstallerBackup" "C:\Windows\Installer" /E /COPYAT /R:2 /W:5 /V /LOG:C:\InstallerRestore.log
• After restoring, retry the failing uninstall/repair/update.

• Look in Event Viewer (Windows Logs → Application) for MsiInstaller or Windows Installer errors — they commonly include the missing filename. Use that filename to restore from your backup.
• If several apps fail or major components are broken, consider restoring the entire Installer folder from your backup (robocopy restore command above).

• In an elevated Command Prompt run:
  • sfc /scannow
  • DISM /Online /Cleanup-Image /RestoreHealth
    These won’t restore deleted .msp files from Installer, but they can fix Windows component issues and are good hygiene after big changes.

• If you can’t restore a specific .msp (missing from the backup) and the program is still broken, reinstalling the program from the original installer will recreate the necessary installer cache entries.

• Keep that external backup for 2–4 weeks. If nothing breaks, you can delete the backup or archive it elsewhere.
• Going forward, don’t delete files directly from C:\Windows\Installer. Use PatchCleaner (or the move-then-test method) or rely on Disk Cleanup and DISM to remove update/component files safely. If space becomes tight again, I can walk you through PatchCleaner or a controlled cleanup plan.

• Guide you through restoring the entire Installer folder from the backup (if you decide you want to undo the deletions).
• Help run sfc /scannow and DISM and interpret results.
• Show how to use Event Viewer to find the exact missing .msp name if an uninstall/update errors.

• Are any programs currently failing (errors when launching, uninstalling, or updating)?
• Do you want to restore the whole folder now or wait and only restore if/when a problem arises?

• Keep your external backup of C:\Windows\Installer until you’re certain nothing breaks.
• Use the PC normally: open apps you use, run Windows Update, and try one or two app repairs/uninstalls (not all at once). If something fails you can restore the offending file(s).

• Check Event Viewer → Windows Logs → Application for MsiInstaller or Windows Installer errors — the event usually names the missing .msp/.msi.
• Restore that specific file from your backup into C:\Windows\Installer (recommended) rather than restoring everything unnecessarily.

• To run integrity checks (won’t put back deleted .msp files, but worth doing):
  • Open an elevated Command Prompt and run:
    sfc /scannow
    DISM /Online /Cleanup-Image /RestoreHealth
• To restore one or all .msp files from your backup (example—run in an elevated Command Prompt; replace E: with your backup drive letter):
  • Restore specific pattern:
    robocopy "E:\InstallerBackup" "C:\Windows\Installer" *.msp /COPYAT /R:2 /W:5 /V /LOG:C:\InstallerRestore.log
  • Restore entire backup:
    robocopy "E:\InstallerBackup" "C:\Windows\Installer" /E /COPYAT /R:2 /W:5 /V /LOG:C:\InstallerRestore.log

• Only if multiple programs are failing or you can’t identify missing files. Otherwise restore individual files as needed.

• After 2–4 weeks, you can delete the backup or archive it elsewhere (or keep a system image if you prefer).

• Help run sfc/DISM and interpret results, or
• Walk you through restoring files now (tell me the external drive letter), or
• Show how to use Event Viewer to find a missing .msp name.

• Search for keywords/phrases (give exact words or error codes).
• Summarize the contents of all uploaded files.
• Extract specific items (dates, KB numbers, Event IDs, driver names, recovery keys, package identities).
• Look for troubleshooting clues (Event Viewer errors, powercfg output, Device Manager names) and produce a diagnosis + next steps.
• Compare two files and report differences.

datawizard0103 said:

Windows Installer tracks those .msp files in the registry, not just by filename. Since you already deleted them, the smartest cleanup move now is to install and run PatchCleaner and let it reconcile what’s missing versus what Windows still thinks exists. It won’t magically fix what’s gone, but it will stop Windows from endlessly referencing dead installer entries and refilling the folder later.

Also, turn System Restore off, reboot, then turn it back on to flush any stale installer-related restore data. Don’t clear CMOS, don’t reinstall Windows, and don’t touch the Installer folder again manually. If something breaks later, reinstalling the affected app is usually enough. This is very fixable, just needs cleanup not panic.

Click to expand...

What’s most likely causing this​

• A large MSI patch is being applied (or retried) and Windows Installer caches it under randomized names in C:\Windows\Installer.
• If you see many same-size patches created at the exact same moment, it’s commonly:
  • a patch bundle that contains many sub-patches, or
  • an update/repair loop that re-caches content.

Best way to stop it: identify the product generating the patches​

A) Check Event Viewer around the timestamp (fast, often decisive)​

1. Open Event Viewer → Windows Logs → Application
2. On the right, click Filter Current Log…
3. In Event sources, select MsiInstaller
4. Set a time range around Dec 8, 2025 06:39
5. Open the events and look for the Product Name (it often says which application is being installed/updated).

B) Read the patch metadata from one of the .msp files (more technical, very accurate)​

$msp="C:\Windows\Installer\1065be50.msp"
$installer = New-Object -ComObject WindowsInstaller.Installer
$db = $installer.OpenDatabase($msp, 0)
$view = $db.OpenView("SELECT `Property`,`Value` FROM `MsiPatchMetadata`")
$view.Execute
$rows = @
while ($rec = $view.Fetch { $rows += [pscustomobject]@{ Property = $rec.StringData(1); Value = $rec.StringData(2) }
}
$rows | Sort-Object Property | Format-Table -AutoSize

Safer cleanup going forward (so you can reclaim space without breaking Windows Installer)​

1. Use PatchCleaner (free) to identify orphaned .msp/.msi in C:\Windows\Installer.
2. Use its Move option (to an external drive) and run your system for a couple weeks.
3. If nothing breaks, delete the moved files on the external drive.

If you insist on deleting that batch anyway​

• Copy those 54 files to an external “quarantine” folder first (same filenames).
• Then delete them from C:\Windows\Installer.
  If later an uninstall/repair/update fails and demands one of them, you can copy it back.

One key question​

• the MsiInstaller event details around 2025-12-08 06:39, or
• the PowerShell metadata output from one MSP,

1) Stop the update loop (quick containment)​

1. Reboot once.
2. After reboot, do not open Acrobat yet.
3. Open Task Manager and end anything Adobe/Acrobat-related you see (common ones):
   • Acrobat.exe, AcroCEF.exe, AcroTray.exe, AdobeCollabSync.exe, AdobeIPCBroker.exe
4. Temporarily pause/disable any 3rd‑party antivirus (if installed), just for the update attempt.

2) Fix the “insufficient privileges” on that exact file/folder​

A) Check the file’s permissions (recommended)​

• SYSTEM = Full control
• Administrators = Full control

B) Quick command-line fix (safer than random “take ownership” of all Program Files)​

3) Re-run the Acrobat install/update properly​

• Open the Adobe Creative Cloud Desktop app → Updates → update Acrobat
  or
• Download the latest Acrobat installer (from Adobe) and Right‑click → Run as administrator.

4) If uninstall/reinstall is blocked: use Adobe’s cleanup tool​

1. Uninstall Acrobat (Settings → Apps → Installed apps)
2. Run the Acrobat Cleaner Tool
3. Reboot
4. Reinstall Acrobat (run installer as admin)

5) After it’s fixed: deal with the new MSP pile safely​

Two questions so I can tailor the next step:​

Practical “leave Adobe” plan (Windows)​

• Photoshop → photo editing
• Lightroom → photo catalog + RAW
• Illustrator → vector
• Premiere/After Effects → video/motion
• Acrobat → PDF edit/sign

• Photoshop: Affinity Photo, GIMP, Krita (painting)
• Lightroom: darktable, RawTherapee, Capture One (paid), ACDSee
• Illustrator: Affinity Designer, Inkscape
• Premiere/After Effects: DaVinci Resolve, Shotcut/Kdenlive, Blender (motion/VFX)
• Acrobat: PDF-XChange Editor, Foxit, SumatraPDF (viewer), Edge built‑in PDF for basics

• Uninstall via Settings → Apps → Installed apps
• Then remove Creative Cloud leftovers (Adobe has a “Creative Cloud Cleaner Tool” if the uninstall leaves broken components)

• PSD/AI compatibility: Most alternatives open them, but advanced effects/plugins may not translate perfectly.
• Fonts: export/install fonts separately (and keep your font licenses in mind).
• Color management: re-check ICC profiles, especially for print work.
• Plugins/presets: many are Adobe‑only; expect replacements.