Skip to content

Windows 11 CapabilityAccessManager 500GB Storage Bug — How to Verify

A Windows 11 bug can silently consume up to 500 GB of the system drive. The system reports low disk space even though nothing obvious is using it. Microsoft fixed it in the July 2026 Patch Tuesday update, KB5101650. This article covers how to check whether a machine is affected — both locally and remotely over SSH/WSL2 — and how the fix and cleanup work.

The Bug

The Capability Access Manager service (responsible for app permissions) writes a SQLite write-ahead-log file:

C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal

Normally this file is a few MB. On affected PCs a fault prevents the WAL from being checkpointed, so it grows without bound — reports range up to ~500 GB. The disk fills up while Storage settings show no obvious culprit.

Symptoms

  • System drive fills up with no apparent cause; free space keeps shrinking.
  • CapabilityAccessManager.db-wal is many GB (should be a few MB, or absent when checkpointed).
  • Disk-usage tools attribute the space to Windows / hidden system files.

How to Check (locally)

Run in an elevated PowerShell (Admin) — the file lives under a protected system profile:

$f = "$env:windir\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal"
if (Test-Path $f) { "{0:N2} GB" -f ((Get-Item $f -Force).Length / 1GB) } else { "file not present" }
  • A few MB, or "file not present" → fine. The WAL only exists while the DB has uncommitted transactions; absent after a checkpoint is healthy.
  • Multiple GB / hundreds of GB → affected.

Confirm the fix is installed:

Get-HotFix -Id KB5101650   # returns a row if applied

How to Check Remotely (over SSH / WSL2)

For a headless or remote box (e.g. a WSL2 workstation reached via Tailscale), invoke Windows PowerShell through WSL interop. Complex inline quoting gets mangled passing bash → powershell.exe, so base64-encode the script and use -EncodedCommand — this sidesteps all quoting. Build the script on the WSL side and encode it as UTF-16LE:

ssh <host> 'bash -s' <<'REMOTE'
cat > /tmp/chk.ps1 <<'PSEOF'
$f=$env:windir+'\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal'
if(Test-Path $f){'WAL_SIZE: {0:N3} GB' -f ((Get-Item $f -Force).Length/1GB)}else{'WAL_SIZE: file not present'}
try{$h=Get-HotFix -Id KB5101650 -ErrorAction Stop;'PATCH: KB5101650 installed '+$h.InstalledOn}catch{'PATCH: KB5101650 NOT installed'}
$c=Get-PSDrive C;'C_FREE: {0:N1} GB free / {1:N1} GB total' -f ($c.Free/1GB),(($c.Free+$c.Used)/1GB)
PSEOF
ENC=$(iconv -f UTF-8 -t UTF-16LE /tmp/chk.ps1 | base64 -w0)
powershell.exe -NoProfile -EncodedCommand "$ENC" 2>/dev/null
rm -f /tmp/chk.ps1
REMOTE

powershell.exe invoked this way runs non-elevated and can't read the file if permissions block it — a clean "file not present" combined with an installed KB5101650 is a reliable all-clear. If you need a guaranteed size read of an already-bloated file, run the local elevated check instead.

The Fix and Cleanup

  • KB5101650 stops the runaway growth. Install the latest Windows Update and reboot.
  • The patch does not shrink an already-bloated file. To reclaim the space: install the update, reboot (releases the file lock / checkpoints the WAL), then delete the oversized .db-wal if it persists — Windows regenerates a healthy one.

Bonus: Windows Version Strings Are Misleading

When checking the build, three fields commonly look "wrong" but are cosmetic quirks — not real version indicators:

Field Shows Reality
[Environment]::OSVersion 10.0.xxxxx Windows 11 always reports 10.0 internally for app compatibility.
Trailing revision via OSVersion .0 .NET reports the UBR (revision) as 0. The real revision is in the registry.
Registry ProductName Windows 10 Pro Never updated for Windows 11 — every Windows 11 PC reads this.

The authoritative fields are in HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion:

$p = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($p.DisplayVersion)  build $($p.CurrentBuild).$($p.UBR)"

Build-to-release map: 22000=21H2, 22631=23H2, 26100=24H2, 26200=25H2.