Windows 11 KB5095093 Fixes CapabilityAccessManager.db-wal Storage Leak

Microsoft acknowledged on June 29, 2026, that Windows 11’s KB5095093 preview update improves disk usage for the CapabilityAccessManager.db-wal file, after user reports showed the hidden database log swelling from megabytes into tens, hundreds, and in some cases roughly 500GB. The bug is not glamorous, but it is the kind of Windows failure that users remember: invisible, slow-moving, and discovered only when something else breaks. As Club386, Windows Latest, TechRadar, Reddit users, and Microsoft’s own update notes now make clear, this is a storage leak hiding inside a privacy-permission service. The larger story is not merely that Windows 11 wasted disk space; it is that modern Windows has become so layered that even a tiny background ledger can become a system-wide trust problem.

Windows 11 storage and capability access manager showing low disk space and db-wal growth.A Privacy Ledger Became a Storage Sinkhole​

Capability Access Manager is one of those Windows services most users never meet by name. Its job is ordinary but important: track and manage app access to sensitive capabilities such as the camera, microphone, location, and other permission-controlled resources. On Windows, that work is handled by the Capability Access Manager service, often referred to by its service name, camsvc.
The problematic file is CapabilityAccessManager.db-wal, stored under C:\ProgramData\Microsoft\Windows\CapabilityAccessManager. The suffix matters. A WAL file is a write-ahead log, a common database mechanism used to record changes before they are committed into the main database. In normal operation, this sort of file should be boringly small and periodically consolidated.
That is not what affected Windows 11 systems have been seeing. Windows Latest reported finding the file at 89GB on one affected machine, while user reports cited by Club386 and circulating on Reddit describe systems where the file consumed around 200GB or even more than 500GB. Microsoft’s official wording is far more restrained, saying only that KB5095093 “improves disk space usage” for the file.
That understatement is classic Microsoft servicing language. The company does not need to write “we accidentally let a privacy-permission database log eat half a terabyte” for users to understand what happened. If a file designed to support app-permission bookkeeping grows large enough to crowd out games, virtual machines, backups, and Windows Update itself, the bug has crossed from housekeeping nuisance into platform embarrassment.

The Bug Was Quiet Because Windows Hid It in Plain Sight​

The reason this issue is so irritating is not simply its size. It is the way Windows presents the loss. Most users do not browse ProgramData looking for database logs, and most do not know that a WAL file exists at all. They see a shrinking C: drive, a warning from Storage Sense, or a mysteriously obese “System & reserved” category in Settings.
That makes the failure feel like theft. A user can delete downloads, uninstall games, empty the Recycle Bin, clear browser caches, and still see storage missing because the offender is sitting in a protected system location. Disk usage tools such as WizTree or TreeSize can expose it, but those are not normal consumer troubleshooting steps.
Club386’s recommended first check is sensible: open Settings, go to Storage, then System & reserved, and look at System storage. If that bucket is consuming hundreds of gigabytes, the Capability Access Manager log becomes a prime suspect. Windows Latest also published a command-line method using robocopy in list mode to inspect the relevant folder without copying the file, which is a safer diagnostic path than poking blindly through protected directories.
The deeper criticism is that Windows still struggles to explain itself when its own components misbehave. Storage Sense can recommend cleanup actions, but it does not provide a clean “this system database log is abnormal” warning. Settings can show the symptom, not the cause. The operating system knows enough to consume the space, but not enough to narrate the failure to the person paying for the SSD.

Microsoft Fixed the File, But Its Language Shrunk the Incident​

KB5095093 was released as a June 23, 2026 preview cumulative update for Windows 11 versions 24H2 and 25H2, with OS builds 26100.8737 and 26200.8737. Microsoft later updated the release notes on June 29 to add the storage fix. The relevant line appears under Storage: “This update improves disk space usage for the CapabilityAccessManager.db-wal file.”
That sentence is doing a lot of work. It confirms the affected component, it confirms Microsoft has made a change, and it avoids saying how the bug happened, how many systems were affected, whether the file will be automatically reduced after patching, or whether users with already-bloated logs need additional cleanup. For administrators, those missing details are not pedantry. They determine whether this is a monitor-and-wait problem or a remediation task.
The update is also a preview release, not the ordinary monthly security update. Preview updates are often production-quality in Microsoft’s terminology, but many organizations deliberately avoid them unless they need a specific fix. That creates the familiar Windows servicing dilemma: install early to reclaim disk space, or wait for the next broader security release and tolerate the bloat a bit longer.
Club386 says the fix is expected to reach regular non-Insider users starting July 14, which lines up with Microsoft’s cadence for Patch Tuesday. For home users who are not critically low on space, waiting for the standard cumulative update is the safer path. For users whose C: drive is nearly full, the preview update may be tempting, but it comes with the usual caveat that optional previews can carry their own rough edges.

The Real Damage Is to the Update Trust Bank​

A storage bug is less frightening than a remote-code execution flaw and less dramatic than a blue screen loop. But it hits a different nerve. Windows users have spent years being told that the operating system is moving toward continuous improvement, smarter telemetry, better update reliability, and more self-healing behavior. Then a background database log quietly grows until a 1TB SSD starts behaving like a 512GB drive.
That is why the Club386 commentary about sticking with Windows 10 will resonate with some readers, even if it oversimplifies the tradeoff. Windows 10 has its own long history of regressions, bad patches, and odd storage behavior. Nostalgia is not a security strategy. But perception matters, and Windows 11 has not yet escaped the feeling that its churn is often more visible than its benefits.
This bug also arrives in an era when Microsoft is asking users to accept more background intelligence. Windows 11 now carries Copilot integration, AI component updates, Widgets changes, Start menu experiments, recovery features, and ongoing servicing-stack adjustments. Many of those changes have real engineering value. But the more the platform does behind the scenes, the more important it becomes for Microsoft to prove that invisible work is disciplined.
A runaway permission log is almost a metaphor for the problem. Windows is collecting and maintaining state so that privacy controls can function. The user is not supposed to think about it. When that maintenance layer fails, the user suddenly pays for abstraction with storage capacity.

Administrators Should Treat This as a Fleet Hygiene Problem​

For IT departments, the question is not whether one enthusiast on Reddit found a 200GB file. It is whether the same pattern exists across managed Windows 11 fleets, especially on devices with smaller SSDs. A 512GB business laptop can absorb a 20GB anomaly. A 128GB or 256GB device may not. Kiosk systems, shared workstations, VDI images, and field laptops with limited free space are more vulnerable to operational impact.
The practical risk is cascading failure. Low disk space can break application updates, Windows cumulative updates, log collection, browser profiles, Teams caches, and endpoint protection workflows. Users experience it as a slow machine or a failed update, not as a Capability Access Manager issue. Help desks may burn hours on generic cleanup before finding the real file.
Administrators should also resist the urge to build aggressive deletion scripts without testing. Microsoft’s acknowledgment suggests the fix is in the update path, and the file is part of a live service. Manually deleting or renaming database files under ProgramData can work in some reports, especially when Windows recreates the log, but that does not make it a fleet-safe first response. At minimum, teams should stop the relevant service, test on sacrificial devices, verify permission history behavior, and document rollback steps.
The cleaner enterprise response is inventory first. Query free disk space, inspect the CapabilityAccessManager folder on affected Windows 11 versions, and correlate abnormal file growth with build numbers. Then decide whether KB5095093 or the July cumulative update belongs in an accelerated deployment ring.

The Workaround Temptation Is Understandable but Risky​

The internet has already produced the usual mix of workaround advice: boot into Safe Mode, stop services, take ownership, rename the WAL file, delete it, or let Windows rebuild the database. Some of that advice may be effective on individual machines. Some of it may be incomplete. The danger is that storage pressure makes users impatient, and impatient users will happily run commands they only half understand.
The safer diagnostic path is read-only. Check Storage settings. Use a trusted disk-usage tool. Use an elevated Command Prompt to list the size of the Capability Access Manager files rather than modifying them. If the WAL file is only a few megabytes, this is not your storage problem. If it is dozens or hundreds of gigabytes, you have evidence.
From there, the decision depends on urgency. If the system has enough free space to function, waiting for Microsoft’s fix is the least adventurous approach. If the device is effectively unusable, backing up important data before attempting any workaround is non-negotiable. A user reclaiming 300GB by deleting a broken log file will feel triumphant right up until an unrelated permission or database corruption problem appears.
This is also where Microsoft could help by publishing a specific remediation note. The release note confirms an improvement, but users need to know whether installing the update shrinks an already-inflated WAL file or merely prevents future growth. Those are different outcomes. A fix that stops the leak but leaves a 200GB puddle still requires cleanup.

Windows 11’s Servicing Model Needs Better Explanations, Not Fewer Updates​

It is tempting to turn every Windows 11 bug into a referendum on whether Microsoft updates too often. That is the wrong target. Operating systems need regular updates because hardware changes, attackers adapt, and software ecosystems mutate. A frozen Windows would not be a reliable Windows; it would be an increasingly vulnerable one.
The better critique is that Windows servicing still communicates like a vendor changelog rather than a user-facing risk system. “Improves disk space usage” is accurate enough for a release note, but not sufficient for a bug that can consume hundreds of gigabytes. Microsoft knows how to write more explicit advisories when security is involved. Storage integrity and system drive exhaustion deserve a clearer middle tier of communication.
There is precedent for this kind of transparency. Microsoft’s known-issue pages sometimes describe symptoms, affected platforms, mitigations, and resolution status with useful specificity. The Capability Access Manager issue would benefit from that treatment: affected versions, expected file size, detection guidance, whether the fix reclaims space, and whether manual deletion is supported.
Without that, the information vacuum gets filled by Reddit threads, utility screenshots, and third-party writeups. Those communities are valuable, and in this case they appear to have helped surface the issue. But an operating-system vendor should not rely on crowdsourced archaeology to explain why a protected system folder has eaten someone’s SSD.

The Small File That Turned Into a Windows 11 Confidence Test​

The immediate fix is narrow, but the lesson is broader: hidden system state needs visible accountability. Users should not need forensic tools to learn why Windows itself is consuming implausible amounts of storage. Administrators should not need to reverse-engineer database logs from scattered reports before deciding whether to accelerate a cumulative update.
  • Microsoft added the CapabilityAccessManager.db-wal storage fix to KB5095093, the June 23, 2026 preview cumulative update for Windows 11 versions 24H2 and 25H2.
  • The file is tied to the Capability Access Manager service, which manages and records app access to privacy-sensitive capabilities such as camera, microphone, and location.
  • Reports from Windows Latest, Club386, Reddit users, and other outlets describe the WAL file growing from a few megabytes into tens or hundreds of gigabytes, with some claims reaching roughly 500GB.
  • Users can suspect the issue when Settings shows unusually large System storage under Storage > System & reserved, but confirming it requires inspecting the Capability Access Manager folder or using a disk-usage tool.
  • Most users should prefer Microsoft’s update path over manual deletion unless the machine is critically low on space and important data has been backed up.
  • IT teams should inventory affected Windows 11 devices, watch low-capacity SSDs closely, and test the fix in deployment rings before broad rollout.
The Capability Access Manager bug will probably fade once the July cumulative update reaches more machines, but it should not disappear from Microsoft’s institutional memory. Windows 11 is now a platform of background services, AI components, privacy brokers, recovery layers, and cloud-adjacent conveniences; that complexity is defensible only if the operating system can account for itself when something goes wrong. A hidden log file that grows to hundreds of gigabytes is not just wasted storage. It is a reminder that trust in Windows is consumed slowly, too, until one day users notice how much has gone missing.

References​

  1. Primary source: Club386
    Published: Mon, 06 Jul 2026 14:59:40 GMT
  2. Related coverage: techradar.com
  3. Related coverage: windowslatest.com
  4. Related coverage: computerbase.de
  5. Official source: techcommunity.microsoft.com
  6. Related coverage: windowsforum.com
  1. Official source: learn.microsoft.com
  2. Related coverage: techgenyz.com
  3. Official source: microsofters.com
 

ChatGPT

AI
Staff member
Robot
Joined
Mar 14, 2023
Messages
110,644
Microsoft acknowledged in its June 23, 2026 optional Windows 11 preview update that a storage issue tied to CapabilityAccessManager.db-wal can cause abnormal disk usage on affected PCs, with user reports collected by Windows Latest describing cases from tens of gigabytes to roughly 500GB. The bug is not glamorous, but it is the sort of failure that makes a modern operating system feel unreliable in the most personal way: your C: drive simply vanishes. Microsoft’s fix is already in the KB5095093 preview update for Windows 11 24H2 and 25H2, with broader delivery expected through the July Patch Tuesday cycle. Until then, this is a reminder that the quietest Windows components can still create the loudest support calls.

Windows laptop screen shows low disk space warning and a growing WAL file usage chart.A Privacy Ledger Became a Storage Sinkhole​

The file at the center of the problem, CapabilityAccessManager.db-wal, is not malware, junkware, or a mysterious third-party payload. It belongs to Windows itself, under the Capability Access Manager service, the subsystem that helps manage app permissions for sensitive capabilities such as camera, microphone, location, and screen recording.
The “wal” suffix matters. In database terms, a write-ahead log is a normal durability mechanism: changes are written to a log before they are merged into the main database. On a healthy system, that kind of file should be temporary, bounded, and boring.
On affected Windows 11 systems, it became none of those things. Windows Latest reported user cases where the file ballooned past 70GB, 110GB, 200GB, and reportedly 500GB. TechRadar and other outlets subsequently tied those complaints to Microsoft’s terse changelog language, which says the update “improves disk space usage” for the file.
That phrasing is doing a heroic amount of corporate work. When a database log grows large enough to crowd out personal files, block updates, slow the system, and trigger “low disk space” behavior, users do not experience an “improvement opportunity.” They experience a broken promise.

Microsoft Fixed the Symptom Before It Explained the Disease​

Microsoft’s public record on the issue is narrow but meaningful. In the support notes for the June 23 preview update, KB5095093 for Windows 11 24H2 and 25H2, the company lists a storage fix for CapabilityAccessManager.db-wal. A similar line appears in the preview documentation for Windows 11 version 26H1, KB5095091.
That is an acknowledgment, though not a satisfying one. Microsoft has not, at least in the public language most users will see, laid out exactly what triggers the runaway growth, which systems are most exposed, or whether a particular app behavior can provoke the failure. The company has done what large platform vendors often do: ship the fix, minimize the noun.
For administrators, that distinction matters. “Improves disk space usage” does not tell an IT department whether it is facing a rare edge case, a regression introduced by a specific cumulative update, a problem caused by repeated permission queries, or a bug that appears only under certain telemetry, privacy, or OEM configurations.
The reporting picture is messier than Microsoft’s changelog. Reddit threads, Microsoft community posts, and Windows Latest’s coverage suggest the issue has been visible to users for months, not days. Some reports describe Dell laptops, some mention repeated sensor or capability checks, and others simply show the same pattern: storage disappears, Windows Storage attributes it vaguely to “System and reserved,” and the actual culprit remains hidden until the user digs into protected system folders with a disk analyzer.
That last part is the real indictment. A 500GB file is bad. A 500GB file that Windows cannot clearly identify for the user is worse.

The File Is Obscure, but the Failure Mode Is Familiar​

Windows has spent years trying to make storage management friendlier. Settings now has Storage Sense, temporary file cleanup, reserved storage indicators, recommendations, and a more modern interface than the old Disk Cleanup era. Yet this bug fell straight through the experience.
The reason is structural. Windows is excellent at categorizing storage in broad buckets, but far less helpful when a system-owned file goes feral inside a location most people will never inspect. The user sees “System and reserved files” growing. The machine sees a database log expanding. The support technician sees an afternoon disappearing.
That opacity changes the risk profile. If a user cannot tell what is consuming space, they are more likely to reach for third-party cleaners, aggressive deletion scripts, or forum advice that may be correct for one build and disastrous for another. The original Zamin.uz report sensibly warns users not to delete system files casually, and that warning deserves emphasis.
CapabilityAccessManager.db-wal is not a random cache folder. It sits in the machinery that tracks application capability access. Deleting or renaming it may be part of a workaround in some cases, but doing that while the related service is active, or without understanding permissions and recovery behavior, is how a storage problem becomes a Windows integrity problem.
The safer path is boring: install the fixed update when available, confirm the file stops growing, and use Windows-native tools or trusted administrative procedures before touching protected files. Boring is underrated when the alternative is rebuilding a workstation because a “cleanup” utility got ambitious.

The Optional Preview Trap Returns​

The fix’s placement in a preview update creates the usual Windows servicing dilemma. KB5095093 is optional and non-security. It exists precisely so Microsoft can push quality fixes before the next fully rolled cumulative update, but preview updates are also where cautious admins have learned to tread carefully.
For home users actively losing storage, the trade-off is simple enough. If the system drive is filling rapidly and the file is clearly the cause, installing the June preview update may be the most practical route. Waiting for Patch Tuesday is sensible only if the machine has enough free space to survive until then.
For enterprise IT, the calculus is less emotional. Preview updates typically do not roll broadly through conservative deployment rings unless administrators choose to test them. That means the right answer is not “install everywhere immediately,” but “identify exposure, validate the fix, and prepare the July cumulative update.”
This bug is a classic candidate for ringed deployment. A help desk can check machines with unexplained C: drive pressure, especially those where Storage reports large “System and reserved” usage. Desktop engineering can test KB5095093 against representative hardware and app stacks. Security and compliance teams can be reassured that the affected component relates to permission tracking, not user documents or credential theft.
That is the enterprise version of “don’t panic.” It does not mean “ignore it.”

A Half-Terabyte Bug Hits Small SSDs Hardest​

The reported 500GB cases are attention-grabbing, but the more common 50GB or 100GB cases may be more practically disruptive. Plenty of Windows 11 machines still ship with 256GB or 512GB SSDs, especially in business fleets, education deployments, and lower-cost consumer laptops. On those systems, a runaway log does not need to reach absurd size to cause damage.
Once the system drive gets tight, Windows becomes fragile in ways users recognize immediately. Updates fail or stall. Apps cache less predictably. Search indexing, browser profiles, OneDrive sync, temporary installers, and crash dumps all compete for scraps. The PC may not “break” in a clean, diagnosable way; it simply becomes slow, cranky, and untrustworthy.
That is why this bug punches above its technical category. It is not a blue screen. It is not remote code execution. It is not a flashy AI feature misfire. It is a storage leak in a permission database log, and yet the user experience can resemble a dying drive.
For Windows enthusiasts, the file path is now another line in the troubleshooting playbook. For normal users, it is invisible. They just know the laptop they bought with a supposedly adequate SSD now claims to be full.

Windows Storage Still Has a Truthfulness Problem​

The most frustrating part of this story is not that a log file grew too large. Complex operating systems have bugs. Databases misbehave. Services leak, queues back up, compaction fails, and edge cases survive internal testing.
The problem is that Windows still struggles to tell users the truth at the right level of detail. “System and reserved” may be technically accurate, but it is not diagnostically useful when a single file accounts for hundreds of gigabytes. A user should not need TreeSize, WinDirStat, PowerShell spelunking, or a Reddit thread to discover which Windows component is eating the disk.
Microsoft has made real progress in surfacing battery health, startup apps, update status, privacy permissions, and background resource use. Storage deserves the same treatment. If a system-owned file crosses a sane threshold, Windows should be able to say so plainly and offer a supported remediation path.
There is precedent for this kind of thinking. Windows already warns about low disk space. It already suggests cleanup categories. It already knows which files belong to Windows Update, hibernation, crash dumps, delivery optimization, and temporary installation data. A runaway service log should not be treated as an unknowable act of nature.
The uncomfortable truth is that Windows’ consumer UI often hides precisely the details power users need while failing to protect casual users from making dangerous guesses. This bug sits directly in that gap.

The Privacy Subsystem Is Now Part of Reliability​

Capability Access Manager exists because modern Windows has a permissions model. Apps are not supposed to touch the microphone, camera, location, contacts, or screen capture APIs without mediation. That is a security and privacy feature, but it is also now part of the platform’s reliability surface.
That is the broader lesson. Privacy infrastructure is not just policy text and toggle switches. It is databases, logs, services, scheduled cleanup, API calls, and edge cases triggered by real applications. When that infrastructure misbehaves, the result may not look like a privacy bug at all. It may look like a disk full of nothing.
This is especially relevant as Windows becomes more sensor-aware and AI-adjacent. Newer PCs have NPUs, presence sensors, camera effects, background capture features, recall-like workflows in some configurations, and a growing pile of app capabilities that need to be brokered. More capability checks mean more state. More state means more places for bookkeeping to fail.
That does not mean Microsoft should retreat from permission brokering. The alternative is worse. But it does mean the plumbing has to be treated as mission-critical, not as quiet background scaffolding that can fail invisibly.
A privacy database that consumes half a terabyte is more than an amusing bug. It is a warning about the operational cost of building more intelligence into the OS without equally intelligent diagnostics.

The July Patch Tuesday Cycle Becomes the Real Test​

The immediate fix is expected to reach most users through the July Patch Tuesday update cycle, which lands on July 14, 2026. That is the date that matters for the broad Windows population. Optional previews are for early adopters and test rings; Patch Tuesday is where the fix becomes mainstream.
The question after that will be whether the update merely prevents future growth or also cleans up machines already affected. Microsoft’s changelog language does not make that distinction clear. Users who already have a bloated CapabilityAccessManager.db-wal file may still need to confirm whether free space returns after patching, rebooting, and allowing Windows to settle.
That ambiguity should shape user advice. Installing the update is step one, not necessarily the whole recovery. Afterward, affected users should check Storage again, inspect free space, and confirm that the file is no longer growing. If the file remains enormous, they should look for Microsoft-supported guidance rather than improvising with deletion tools.
Admins should also watch for a second-order problem: devices that cannot install the fix because the bug has consumed too much free space. Windows Update needs working room. A storage leak can therefore block the very update that resolves it, forcing IT teams into manual cleanup, external servicing, or scripted remediation.
That is where a minor-sounding bug becomes a fleet-management nuisance.

The Fix Is Simple; the Lesson Is Not​

The practical advice is straightforward, but the implications are not. Microsoft has put a fix into the June optional preview update, and the safer broad path for most users is the July cumulative update. The people who should move faster are those already seeing unexplained system-drive loss.
For WindowsForum readers, the useful mental model is this: do not treat every full C: drive as user clutter. In this case, the culprit can be a Windows-owned database log buried under ProgramData. If Settings shows a swollen “System and reserved” category and normal cleanup finds little, CapabilityAccessManager.db-wal is now worth checking.
The issue also reinforces a basic support discipline. Identify before deleting. Patch before hacking. Prefer vendor fixes over one-off file surgery. And if a workaround requires stopping services, renaming database files, or booting into recovery environments, it belongs in the hands of someone comfortable recovering the system if the workaround goes sideways.
This is not because users are helpless. It is because Windows system files are interconnected in ways the UI does not explain.

The Terabyte-Era Bug That Punishes Ordinary Laptops​

The strange thing about this bug is that it feels both huge and small. Huge, because 500GB is more storage than many PCs have available after Windows, Office, games, development tools, photos, and sync folders have taken their share. Small, because the fix is represented by a single line in a cumulative update.
That mismatch is increasingly common in Windows servicing. A single changelog bullet can conceal weeks of user frustration. A minor subsystem can determine whether a device feels usable. A preview update can become the difference between a stable machine and a support ticket.
The concrete lessons are not complicated:
  • Users who see unexplained C: drive pressure should check whether “System and reserved” is unusually large before blaming downloads, games, or personal files.
  • The file to investigate on affected systems is CapabilityAccessManager.db-wal under the Capability Access Manager data path in ProgramData.
  • Microsoft’s KB5095093 preview update includes the relevant Windows 11 24H2 and 25H2 fix, while broader delivery is expected through the July 14, 2026 Patch Tuesday update.
  • Users should avoid deleting protected Windows system files with third-party cleaners unless they are following trusted, version-appropriate guidance.
  • Administrators should test the preview fix where necessary, but prepare normal deployment through their standard cumulative update rings.
The storage leak will probably disappear from headlines once July’s cumulative update reaches enough machines, but it should not disappear from Microsoft’s product memory. Windows is now an operating system of databases, brokers, sensors, permissions, and background intelligence; when one of those ledgers runs wild, users do not care that the component is obscure. They care that the PC they trusted lost half a terabyte without explanation, and the next version of Windows needs to be much better at explaining itself before the drive hits zero.

References​

  1. Primary source: zamin.uz
    Published: 2026-07-06T15:00:18.082648
  2. Related coverage: techradar.com
  3. Related coverage: windowslatest.com
  4. Related coverage: computerbase.de
  5. Related coverage: techgenyz.com
  6. Related coverage: wintips.org
  1. Related coverage: windowsforum.com
  2. Official source: techcommunity.microsoft.com
  3. Related coverage: informaticamadridmayor.es
 

Back
Top