Server at 99% Disk: Recovering 47GB Windows Couldn't Clean

LIMEHAWK - Managed IT

Home>Incident Reports>Server at 99% Disk: Recovering 47GB Windows Couldn't Clean

Space recovered

47.3 GB

Incident

RMM alert came in at 7 AM: "C: drive below 2% free space." Application server, 99.2% capacity. Security patches failing to install. Event log flooded with "insufficient disk space" errors. Users were already reporting that the line-of-business application was crashing mid-save.

This was a 5-year-old server that had been upgraded in-place from Windows Server 2016 to 2019 to 2022, dragging years of accumulated cruft forward with every upgrade. The 256 GB C: drive had 1.8 GB free, and Windows was reporting it needed 4 GB minimum for the pending cumulative update. Ran standard Disk Cleanup as a first pass: recovered 400 MB. Not even close. We needed to find the other 40+ GB Windows was hiding.

Problem identification

- C: drive: 252 GB used of 256 GB, 1.8 GB free (0.7%)
- Windows Update: failing, needs 4 GB free for the pending cumulative update
- event log: 847 "disk full" errors in the past 24 hours
- application data: only 67 GB — not the problem

The math didn't add up. Windows itself was around 67 GB, application data was 67 GB, that's 134 GB accounted for. Where was the other 118 GB? Running TreeSize gave us the answer: C:\Windows\WinSxS was 48 GB, SoftwareDistribution was 23 GB, and there was a 19 GB Windows.old folder sitting from the 2019 to 2022 upgrade that had never been cleaned.

Why standard disk cleanup wasn't enough

The obvious solution was Disk Cleanup with "Clean up system files." Recovered 400 MB from temp files and thumbnails. Here's why it missed the real bloat:

- Windows.old: Disk Cleanup showed "Previous Windows Installation" but the checkbox was grayed out — file locks from running services kept it pinned
- SoftwareDistribution: Disk Cleanup only clears the Download subfolder (2 GB), not the DataStore (21 GB of accumulated update metadata)
- WinSxS: Disk Cleanup "marks" superseded components for removal but doesn't actually run DISM to delete them
- search index: 4.2 GB Windows.edb file — Disk Cleanup won't touch it at all

The bloat Windows doesn't want to clean by default was exactly what we needed to remove. We had to get aggressive.

Resolution

Ran our aggressive cleanup script via RMM. It goes well beyond what Disk Cleanup touches — stops services to release file locks, runs DISM directly for real WinSxS cleanup, and nukes the search index to force a clean rebuild.

Why this works

The script attacks the four major space hogs that standard cleanup misses. What gets cleaned:

1. cleanmgr /verylowdisk: runs Disk Cleanup in emergency mode — auto-selects all safe options without prompting
2. SoftwareDistribution: stops Windows Update services, deletes ENTIRE folder contents (not just Download), restarts services
3. DISM /StartComponentCleanup: actually removes superseded WinSxS components (Disk Cleanup only marks them)
4. Windows.edb: deletes the search index database, forcing a clean rebuild

Key insight: the real space savings come from WinSxS component cleanup. On this server, DISM recovered 31 GB of superseded system file versions accumulated from 5 years of in-place upgrades — files Windows was keeping "just in case" but would never actually use.

Outcome

Script ran for 23 minutes (DISM is slow, and that's normal — it's walking every component in the store). Total space recovered: 47.3 GB. C: drive went from 0.7% free to 19.2% free. Rebooted the server, the pending Windows Update installed successfully, application crashes stopped. Server has been running clean ever since.

- space recovered: 47.3 GB from Windows bloat
- free space after: 49.1 GB (19.2% of C:)
- script runtime: 23 minutes (mostly DISM)

Key takeaways

Takeaway

standard Disk Cleanup is too conservative — it leaves the real bloat untouched by design.

Takeaway

WinSxS grows forever on upgrade-in-place machines — only DISM can actually clean it.

Takeaway

SoftwareDistribution needs services stopped to fully clean — a running cleanup fails silently otherwise.

Takeaway

we now run this monthly on all servers — proactive cleanup prevents the emergency 7 AM alert.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)