The July 2026 Patch Tuesday update for Windows 11, KB5101650, contains a fix for a database logging bug that has been silently consuming up to 500GB of drive space on some PCs since early this year. But installing the patch is only half the battle—Microsoft’s update stops the runaway growth, but it may not automatically shrink the massive log file that’s already clogging your storage.

The Silent Storage Killer Gets a Patch

The culprit is a write-ahead log file, CapabilityAccessManager.db-wal, managed by the Windows Capability Access Manager service (camsvc). On affected systems, Windows stopped performing its routine checkpoint that merges this log into the main database, causing the file to swell without limit. Microsoft’s release note for KB5101650 tersely states: “This update improves disk space usage for the CapabilityAccessManager.db-wal file.”

That wording is deliberate. The July update, which pushes Windows 11 24H2 to build 26100.8875 and 25H2 to build 26200.8875, prevents future runaway growth but does not guarantee the existing ballooned file will shrink. The fix first appeared in the June 23 optional preview update KB5095093—though Microsoft only added it to that changelog on June 29—and now rolls out broadly as part of the mandatory July cumulative update. Unlike features that trickle out via Microsoft’s gradual rollout, this storage correction deploys to every eligible PC at once.

What This Means for Home Users and Admins

For the average home user, the most obvious symptom is unexplained low disk space. If you open Settings > System > Storage > Show more categories > System & reserved and spot a “System files” total in the tens or hundreds of gigabytes that can’t be explained by the hibernation or page files, this bug is likely the cause. Windows itself does not name the responsible file anywhere in that interface, leaving many to wonder where their storage went.

IT administrators face a bigger challenge. As documented by Max Allen on his Azure to the Max blog, a week-long scan of roughly 10,000 endpoints found that 59% had a WAL file exceeding 1GB, and the worst machine grew by 65GB in a single week. One device reached 332GB. Because the file sits in a SYSTEM-protected directory, traditional disk-space analyzers often report its space as inaccessible, making fleet-level detection a headache.

How a Logging Headache Turned Into a Storage Crisis

The Capability Access Manager service logs every time an app requests sensitive capabilities—camera, microphone, location, screen capture. Its database and write-ahead log live at C:\\ProgramData\\Microsoft\\Windows\\CapabilityAccessManager\\. Normally, the WAL file stays small because Windows periodically commits its contents and shrinks it. On affected builds, that checkpoint stopped happening.

The first public warning came in March 2025, when a user on the Rainmeter forums reported that the WiFiStatus plugin’s location queries caused a 30GB file in under 10 hours on Windows 11 24H2. Other apps associated with heavy geolocation activity—Dell’s SmartByte, GeoComply—also triggered rapid growth, but they were not at fault. The core failure was in the camsvc service itself, which refused to merge the log even when the triggering apps were stopped.

Allen’s investigation traced the problem to builds 10.0.26200.8037, 10.0.26200.8039, and 10.0.26200.8246, suggesting a February or March 2026 update introduced the regression. Microsoft privately confirmed the bug as a known issue to Allen on May 13, weeks before any public acknowledgment, and stated a permanent fix was expected “around late June or early July.” The Windows release health dashboard still doesn’t mention it.

Step-by-Step: Reclaim Your Wasted Space

First, install KB5101650 through Windows Update. Then, verify the patch is active: open Settings > Windows Update > Update history, or run winver and confirm build 26100.8875 (24H2) or 26200.8875 (25H2). Administrators can also run Get-HotFix -Id KB5101650 in PowerShell.

Next, check the size of the offending WAL file without taking ownership or copying anything:

robocopy \"C:\\ProgramData\\Microsoft\\Windows\\CapabilityAccessManager\" \"%TEMP%\\CAMCheck\" /L /B /R:0 /W:0 /BYTES /NP

The /L switch lists files only, and /B uses backup mode to read protected metadata. Note the byte count next to CapabilityAccessManager.db-wal. A healthy system shows around 1.6MB. If yours is several gigabytes or more—especially if it grows on a second check—your PC is still affected.

For many, the July update alone shrinks the file. If it doesn’t, manual cleanup is needed. The safest method, recommended by Microsoft support before the patch, is:

  1. Boot into Safe Mode (via msconfig or the Shift+Restart method).
  2. Open an elevated Command Prompt and stop the service: net stop camsvc.
  3. Delete only CapabilityAccessManager.db-wal—leave CapabilityAccessManager.db and all other files untouched.
  4. Restart normally.

Alternatively, some users have renamed the file from the Windows Recovery Environment, allowed Windows to create a fresh log after a normal boot, and then deleted the old renamed copy. Do not take ownership of the folder or delete the main database; doing so can break Wi‑Fi connectivity, reset app permissions, or cause camsvc to fail with error 1067. If permissions were already altered, reset them with:

icacls \"C:\\ProgramData\\Microsoft\\Windows\\CapabilityAccessManager\" /reset /T /C

If your drive is so full that Windows Update cannot download the patch, clear the WAL file using the Safe Mode procedure first, then immediately install KB5101650.

What Comes Next

Microsoft’s handling of this bug underscores a familiar challenge: even a severe, fleet-wide storage leak can remain invisible if it affects only certain workloads. The company still hasn’t listed the issue on its public health dashboard, and the guardrails around automatic storage reclamation remain unclear. For now, the onus is on users and admins to verify that the fix took hold—and to remember that a lightning-fast SSD is only as good as the free space it has left.