I’m here to discuss a growing issue on my radar, that being the file…
“C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.DB-wal”
…growing endlessly.
This concern could be anywhere from a new large-scale issue that is just starting to emerge, and I’m one of the first people to find it, to an environmental issue caused by some niche piece of software, or just a complete fluke, and nobody else will ever find this useful. That is sometimes the problem with being on the bleeding edge of an issue, but I’d rather put this out and help no one than do nothing and find out I was the first to know of a new issue and didn’t help where I could have.
In this article, I will cover…
- How We Got Here:
- What Is This File? (CapabilityAccessManager.DB-wal)
- How Bad Is the Issue?
- Automated CapabilityAccessManager.db-wal File Size Check:
- How to Clean Up CapabilityAccessManager.DB-wal:
- The Unknowns:
- Why Is This Happening?
How We Got Here:
This week, 4/20/2026, I have seen a rapidly growing quantity of devices that have run out of disk space. Early investigation struggled to understand why, as WinDirStat could not locate this space. If, under options, we enabled it to display “Unknown,” it was seeing huge quantities of consumed space it couldn’t explain (anywhere from 50-200GB), similar to what is shown below.
The WinDirStat blog, What is “<Unknown>”?WinDirStat Blog, is pretty clear that this likely comes down to a permission issue with whatever content you’re trying to find. Basically, WinDirStat knows based on HDD stats that 300GB is consumed, but can only find 250GB worth of files, therefore 50GB of space is shown as “unknown” usage, as it cannot locate those 50GB worth of missing files.
While that blog may advise against the use of System, we felt we had no other choice, so with the power of PsExec (please be careful with this tool) in hand, and the simple command…
.\psexec.exe -s -i "C:\Program files\WinDirStat\WinDirStat.exe"
…We can now run WinDirStat as the System account to try and find these files. What this revealed on every station we tried it on was that the file “C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.DB-wal” had grown to utterly ridiculous sizes (50-200GB). That’s not normal.
The reason we could not see this folder/file is that it is not meant to be accessible, not even by a user like the built-in Administrator account. Instead, it can only be interacted with via the System account.
What Is This File? (CapabilityAccessManager.DB-wal)
Unfortunately, there is very little information, and practically zero first-party documentation, on this file. I did locate two forums discussing it in the context of a similar issue.
One is this forum from March of 2025: [Bug] Rainmeter’s WiFiStatus queries cause huge 30GB+ CapabilityAccessManager.db-wal file – Rainmeter Forums
And one is this forum from March of 2026: CapabilityAccessManager is devouring my hard drive – Microsoft Q&A
Both of these I will talk about more later.
Summarizing what I could find, this file is a database file that tracks what apps have been granted or denied access to sensitive resources like the camera, microphone, location, contacts, etc (the same permissions you see in Settings -> Privacy & Security).
This should be a self-managing file of very small size. Many of our known-good machines have proven to have files less than 1 MB, if even a handful of KB. Some resources are claiming an average expected max size of 4MB. As detailed in the section below, that is not what I am seeing.
How Bad Is the Issue?
Again, the claimed file sizes online are that they should be less than 1 MB or at most 4 MB.
d3Xt3r (thank you!) on the WinAdmins Discord did a large-scale query and found that… “(of) ~8000 devices, only one device had a file >500 MB (647 MB), 6 devices were between 300-100 MB, 100 devices > 10MB. The remaining devices (~7900) were in single digits. So doesn’t seem to be an issue for us.” They also highlighted that they are 24H2, which will come up later.
That certainly sounds relatively in line with what online research suggests.
Meanwhile, my mass scan? It’s not good. I’ve reached 3,700 devices and counting thus far. The average currently stands at 5.9 gigabytes. The median stands at 451 MB, so we know that there are a lot of high-end outliers yanking the average up. To detail it a bit more…
1,456 devices are in excess of 1 GB.
361 are in excess of 10 GB.
137 are in excess of 50 GB.
51 are in excess of 100 GB.
7 are in excess of 200 GB.
1 has reached 332 GB. (wow)
Regardless of whether the right answer is 0.5 MB, 4 MB, 451 MB, or 5.5 GB, something seems to be happening to some count of devices.
That all said, it’s worth highlighting that, thus far, there is not a lot of online movement on this topic. It’s just me and a handful of folks on the Microsoft QA as of late.
Automated CapabilityAccessManager.db-wal File Size Check:
To check this file size more simply than WinDirStat, I created this script that can be found on my GitHub. Obviously, test this yourself!!! Do not take my word for it and throw it to the world.
This can either be deployed as an Intune remediation (detection script only, run as system, run as 64-bit), and it will report back the size in MB of the CapabilityAccessManager.DB-wal file. By default, it is configured to flag files over 1 GB, causing them to return as “with issue.” Based on the numbers above, this seems reasonable. Detailed file sizes can be seen in the PreRemediationDetectionScriptOutput column of a detailed export from the remediation.
Alternatively, to check one machine, you can use Psexec with the below process to execute the script locally as System.
- Run a CMD as admin
- CD to your psexec.exe location
- .\psexec.exe -S -I powershell.exe
- You now have a new/second PowerShell running as System, which you can validate with the “whoami” command
- We will now ensure this process can execute scripts with…
- Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
- And execute our script with…
- .\CapabilityAccessManager-Detection.ps1
- Output will come to the console for the size of the file in MB.
How to Clean Up CapabilityAccessManager.DB-wal:
There are similar DB files I’ve seen explode in size on Windows, primarily the Search Index file. This file, unlike the search index, seems to have no such vendor-provided process for resetting it, which also means there is probably no supported process. Thus, I state clearly that I assume what I am about to provide is not a supported process. Further info on what can likely be expected as a result of running this is in the next section.
Now we come back to this forum: [Bug] Rainmeter’s WiFiStatus queries cause huge 30GB+ CapabilityAccessManager.db-wal file – Rainmeter Forums
A user by the name of jsmorley provided a script, which, after reviewing, kills the processes and services that are using this file, allowing us to then delete it and then restart those processes. I’ve now tested this on several devices, and, well… they’ve not exploded. But again, I have no idea what the ramifications of this are.
I’ve prettied this script up to include logging out to a file as well as tracking of file size before, after, and the space reclaimed. This cleanup script can be found on my GitHub. Obviously, test this yourself!!! Do not take my word for it and throw it to the world.
I can think of three good ways to deploy this.
- Deployed as a Win32 self-service Company Portal app. Trigger detection based on the creation of the log file, thus restricting it to run once, unless someone knows how to delete or rename said log file.
- Deploy it as an Intune remediation with a detection script only (run as system, 64-bit), and then technicians can use the “run once” remediation feature in Intune to assign it as needed. Because the last line written to the host is the before, after, and space saved info, this should be viewable not only in the local log created by the script, but also in the PreRemediationDetectionScriptOutput column of the detailed device run status export of the remediation from Intune.
- Deploy it as an Intune remediation with the previous file size query script as your detection, and then use this as the remediation script, automating the detection and remediation of oversized files. Again, because the last line written to the host is the before, after, and space saved info, this should be viewable not only in the local log created by the script, but also in the PreRemediationDetectionScriptOutput column of the detailed device run status export of the remediation from Intune.
I urge caution with this option, though, as the baseline expected size is not a known value, just being guessed, and by default is set at 1 GB in the detection script. Automating this could let it run many times on a given machine, and it’s not known what even one execution could negatively impact, let alone many executions.
The Unknowns:
Again, this solution is not supported by the vendor (Microsoft). There is very little (or simply no) first-party info on this file, its purpose, its expected size, or the ramifications of deleting it. Nor is there any info on this issue yet besides the previously mentioned blogs, which don’t yet seem to scream that this is a global, massive issue as there is little online activity as of current.
The current belief is that the DB will gracefully rebuild itself, the deletion does not cause any harm, and that the issue will not come back (the file will stay under the appropriate size). That remains to be proven.
One expected belief, though, is that you will likely have your app privacy / privileged permission settings blown away. Meaning, you might need to say that Chrome can use your camera, or Teams can use your mic once again to re-establish that setting.
Trust me, I am not too happy about this risk either. But, ultimately, while scary, if you have this issue, your employees are already down. You can either take this risk and try this, and so far in my testing, they are back up for now, but it’s uncertain what the future may hold, or you can be stuck with a full disk, unable to work. It is your choice.
Obviously, test this yourself!!! Do not take my word for it and throw it to the world.
Why Is This Happening?
I wanted to include this section, but as of writing, we do not know for certain where this is coming from, and thus, ultimately, who all is going to see this. I do have some info, though.
The aforementioned blogs do mention some interesting widgets, none of which are in use. We’ve tried to identify recent common software updates to no avail. And, we are not seeing a common platform, model, etc.
What we are seeing in common so far is that…
- All impacted employees thus far have had a 256 GB root drive.
This is likely survivor bias, though, as we believe devices with larger drives are impacted; it is simply taking longer for them to break simply because they have more space to chew through before this becomes a problem. (I can confirm this to be true now, the 330 GB~ file is on a 1TB machine that still has 400 GB free, so they still have no idea there is an issue). - I cannot ignore that the Microsoft QA over this same topic was born just after the patch Tuesday of March… And that every single impacted device I have seen has been on the March update or later (10.0.26200.8037, 10.0.26200.8039, 10.0.26200.8246). It could be a coincidence due to rapid patching, but it’s interesting.
- I’ll also highlight that this issue is not instant. The file takes time to build up, so whatever is causing the problem today likely started quite a while ago in order to get to these insane file sizes we are seeing. That again makes me wonder about the March update, as it applied to these devices several weeks ago, giving a plausible timeframe for the issue to have built up. That said, I don’t know how quickly the files are growing.
- All of the devices are Windows 11, 25H2, Entra joined, user auto-pilot enrolled.
Again, I have heard from someone on 24H2 who is not seeing the issue after doing a large-scale scan. Maybe it’s 25H2 related. Sadly, nobody on the Microsoft QA forum noted their Windows version.
I did marry my remediation detection data up to a device inventory export to try and find a common theme, but really all I found was that yes, devices reporting to have a huge file really reflect that space consumption (and likely low space). Similarly, our devices are relatively up to date (March, March out-of-band, April, etc). And yes, it’s every model and HDD size under the sun.
I’m going to hazard a guess that I will be opening a Microsoft case very, very soon.
Conclusion:
On one hand, I hope this does help someone. On the other hand, I hope this doesn’t help too many people because that would mean this is a broad issue and, oh my god, that would not be good.
In any case, I will update this blog as I gain further insight and information
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 