SUMMARY
On this machine atc.sys accumulates kernel pool memory continuously and does not return it
until reboot. At 6 days uptime it held 1,242 MB across 282 distinct pool tags with 3,063,374
outstanding allocations. After a reboot it reached 357 MB within 20 minutes.
The memory is never returned while Windows is running. A reboot is currently the only recovery.
ENVIRONMENT
Product Bitdefender Total Security 27.0.60.339
Agent Bitdefender Agent 27.1.1.48
VPN Bitdefender VPN 27.3.5.11
Driver atc.sys 1.86.445.0, file modified 2026-09-15
Other BD drivers Trufos.sys 2.7.2.81, gemma.sys 1.49.169.0, bddci4.sys 4.8.8.75,
ignisv2.sys 2.8.13.222, vlflt.sys 2.0.284.0
Service "atc", StartMode System, State Running
OS Windows 11 Pro, build 26200, 64-bit
Hardware 32 GB RAM (33,245,948 KB visible)
Workload note: this machine runs many concurrent automated build and test processes, so its
process-creation and file-open rate is far above a typical desktop. The leak scales with that
rate, which is likely why it is visible here so quickly.
MEASUREMENTS
- At 144.9 hours uptime (2026-09-17, before reboot)atc.sys total 1,242 MB across 282 pool tags
Outstanding allocations 3,063,374
System paged pool 4,922 MB
System nonpaged pool 3,851 MB
Commit charge 60.4 GB on 32 GB of physical RAM
Free physical RAM 5 GB - Reboot recovered it, which confirms the memory was held rather than in useatc.sys before reboot 1,052 MB
atc.sys after reboot 300 MB at 6 minutes uptime
Returned 751 MB - Regrowth after reboot, measured over 10.7 minutesat 6 min uptime 300 MB, 981,824 outstanding allocations
at 20 min uptime 357 MB, 1,063,020 outstanding allocations
delta +57 MB, +81,196 outstanding in 10.7 minutes - Largest atc.sys tags at 20 minutes uptimeTag MB Outstanding
#FCI 45.1 89,641
#UCH 36.3 262,647
#STX 35.4 89,298
#SAC 35.0 189
#RUS 23.0 604
#PAE 20.1 13
#CBT 20.0 11
#FXO 13.7 89,652#FCI, #STX and #FXO track each other almost exactly (89,641 / 89,298 / 89,652), which suggests
one allocation site producing three structures per event.
HOW atc.sys WAS IDENTIFIED
Pool tags were read from the live kernel with
NtQuerySystemInformation(SystemPoolTagInformation = 22), the same table poolmon.exe reads.
Each tag was then attributed to a driver by scanning all 945 .sys files under
C:\Windows\System32\drivers and C:\Windows\System32 for the tag's four literal ASCII bytes,
since a pool tag compiles to an immediate and appears verbatim in the binary.
Every one of the 282 tags beginning with "#" was found in atc.sys and in no other driver.
Controls were run so the method is not trusted blindly:
- "FMfn" resolved to fltmgr.sys alone (correct)
- "Toke" resolved to the kernel and many drivers (correct)
- Tags known to shrink were verified to shrink, so the instrument reports decreases as well
as increases
WHAT IS NOT PROVEN
A second, larger leak was measured on the same machine and I could NOT attribute it to
Bitdefender. Reporting it in case it is related, clearly labelled as unattributed:
Kernel security token objects ("Toke" / "SeTd" / "SeTl" / "SeAt")
Before reboot 464,160 outstanding tokens, 1,260 MB
After reboot 8,490 outstanding tokens, 16 MB
Regrowth +394 tokens in 10.7 minutes
464,160 outstanding tokens against 332,406 total user-mode handles machine-wide means no
process held them; a kernel component did. The correlation with atc.sys is strong because both
scale with process creation and ATC hooks process creation, but correlation is all I have. I
have no kernel debugger evidence naming the holder, and I am not claiming Bitdefender causes it.
Also worth ruling out explicitly: FMfn (Filter Manager name cache) reached 547 MB and looked
like a leak, but it trims correctly in both directions and is NOT a defect.
HOW TO REPRODUCE
Run this in PowerShell, wait 10 minutes, run it again, and compare. It needs no elevation and
no download.
******: reads the kernel pool tag table and totals every tag owned by atc.sys.
(attached separately as poolsnap.ps1, or reproduce with poolmon.exe from the WDK and sum
every tag beginning with "#")
Expected on an affected machine: the atc.sys total rises continuously and never falls back.
WHAT I AM ASKING
- Confirm whether this regrowth rate is expected for Active Threat Control.
- If it is a defect, whether a fix exists in a build newer than atc.sys 1.86.445.0.
- Whether there is a supported setting that bounds ATC's pool use on machines with a very high
process-creation rate.
I have not disabled or unloaded atc.sys, since it is a System-start driver.
