Kernel memory leak in rtp1.sys / rtp2.sys still present in F-Secure 26.8 (driver 1.1.2607.9217) – pr
Hi,I can confirm the kernel pool leak reported earlier in this thread. It is still present in F-Secure 26.8 on my machine, with the same rtp1.sys / rtp2.sys binaries mentioned by the previous reporter.
ENVIRONMENT
- Windows 11 Home 25H2, build 26200.9457
- AMD Ryzen 7 5800X, 32 GB RAM
- F-Secure 26.8
- rtp1.sys and rtp2.sys 1.1.2607.9217 (Avira real-time protection filter driver)
- BdSentry.sys 3.0.2412.1247, BdNet.sys 1.0.2411.1743, nif_driver_64.sys (fsnifdrv) 3.0.35
WORKLOAD
Software development workstation running an automated build and test loop around the clock (Git for Windows / MSYS2 bash, Node.js, npm builds, headless Chrome tests). This creates a very large number of short-lived processes.
MEASUREMENTS (last boot 2026-09-30 19:22)
- Leaked process objects
- 2026-10-01 14:55: performance counter \Objects\Processes = 140,865, while only 386 processes were actually running (Get-Process).
- 2026-10-01 15:20: \Objects\Processes = 144,170, still 386 running processes.
The number of process objects in the kernel grows with every process that is started, but they are never freed after the process exits.
- Commit charge (commit limit 42.2 GB)
- 2026-10-01 04:30: 27.3 GB
- 2026-10-01 14:55: 34.3 GB
- 2026-10-01 15:20: 36.6 GB
That is roughly +0.7 GB per hour under this workload.
- Kernel pools over the same period
- Paged pool: 2.16 GB -> 4.00 GB
- Nonpaged pool: 1.20 GB -> 1.88 GB
- Not caused by user-mode processes
- Total private bytes of all processes stayed flat at about 15.5 GB.
- Per-process pool usage (\Process()\Pool Paged Bytes and \Process()\Pool Nonpaged Bytes) sums to only about 0.1 GB.
The growth is entirely kernel-side.
IMPACT
- On 2026-10-01 at about 03:22 the commit limit was reached and applications started failing ("VirtualProtect failed with code 0x5af").
- This machine has had three unexpected shutdowns (Kernel-Power 41 / Event 6008) on 2026-09-18, 2026-09-22 and 2026-09-28. All of them happened during heavy overnight build activity, so I suspect they are related, although Ihave not proven this.
- The only workaround I have found is rebooting the machine regularly.
HOW TO SEE IT
Run anything that starts many short-lived processes, for example a build loop or "for /l %i in (1,1,10000) do cmd /c exit". Then compare the \Objects\Processes performance counter with the number of running processes. Thecounter keeps growing, while the number of running processes stays the same. This matches the earlier analysis in this thread: the real-time protection driver appears to take a reference on every created process and neverreleases it.
QUESTIONS
- Is a fix for rtp1.sys / rtp2.sys scheduled, and is there an estimated release version or date?
- Is there a supported workaround that avoids the leak until then, for example excluding specific processes or folders from real-time scanning?
I am happy to provide an FSDIAG report or poolmon snapshots if that helps the engineering team.
Thank you.
Comments
-
Same issue here: still present in F-Secure 26.9, reproducible on demand, and only with Virus Protection on
I can confirm this leak. Updating to F-Secure 26.9 did not fix it: the update left the Avira component unchanged.
System
- Windows 11 Pro, build 26300, HP laptop with 64 GB RAM
- F-Secure TOTAL 26.9 (also seen on 26.8)
- Avira Endpoint Protection SDK 1.0.2502.5082
- rtp1.sys / rtp2.sys 1.1.2607.9217 (same file date, 18/08/2026, before and after the 26.9 update)
Impact after 12 days of uptime, with almost all apps closed
- 83% of 64 GB RAM in use; commit charge about 63–67 GB of a 71 GB limit.
- Total private bytes of all user-mode processes: only about 14.5 GB.
- Nonpaged pool 3.5 GB, paged pool 5.1 GB.
- Kernel pool tags (read with the same API poolmon uses):
Proc 356,322 outstanding (process objects, while only ~275 processes were running)
Toke 372,897 outstanding (tokens)
PsIn / MiP2 ~356,32x outstanding
AVBh / PLE0 / DAV0 / DAV1 / DAV3 ~356,494 outstanding (tags found in rtp1.sys / rtp2.sys)
PLE0 alone = 1.95 GB of paged poolThe Avira tags rise in step with the stuck process objects, so every process that exits appears to keep a reference held by the RTP driver.
Controlled test (same machine, fresh reboot)
I started 500 ×
cmd /c exit(about 1,000 processes including conhost) and counted stuck process objects from a separate, fresh process once the test had finished:| F-Secure setting | Stuck immediately | Still stuck after settling |
|---|---|---|
| Virus Protection OFF | +411 | about 68, later 0 |
| Virus Protection ON (default) | +965 | about 817 |
| Virus Protection ON, Behavior Detection OFF | +974 | about 985 |The OFF and ON runs were on the same boot, with only the Virus Protection toggle changed. The rtp1/rtp2 drivers stay loaded in all three cases. Disabling Behavior Detection makes no difference, so the leak appears to be in the core real-time scanning path. That means there is no partial-disable workaround: the only setting that stops it also removes real-time protection.
How to reproduce (PowerShell, no admin needed)
# Count process objects (this includes exited processes still referenced) vs. live processes
"Process objects: {0} Live: {1}" -f (Get-Counter '\Objects\Processes').CounterSamples[0].CookedValue, (Get-Process).Count
# Start and exit ~1,000 short-lived processes
1..500 | % { (Start-Process cmd.exe -ArgumentList '/c exit' -WindowStyle Hidden -PassThru).WaitForExit() }
# Re-check from a NEW PowerShell window: with Virus Protection on, process objects stay ~800+ higher
"Process objects: {0} Live: {1}" -f (Get-Counter '\Objects\Processes').CounterSamples[0].CookedValue, (Get-Process).CountQuestions for F-Secure
- Is a fixed rtp1.sys / rtp2.sys (or Avira SDK) build scheduled, and in which F-Secure version or date?
- Is there a supported workaround that keeps real-time protection on, for example excluding specific processes or paths?
- Can you confirm the issue is tracked internally, and share a reference number?
Right now the only workaround is rebooting every few days. On machines that start many short-lived processes (developer tools, build loops, VS Code extensions), the commit limit is reached within a couple of weeks.
(produced by Claude)I'm uninstalling F-Secure and using a different vendor until confirmed fixed as it is killing my machine after only 3 days of use