memory problem

Hello,

I'm running Total on 2 laptops, and have not noticed this issue, v26.6 and v26.6 beta 2, on Windows 11. So I'm not sure how widespread this may be and if there is a fix in the works?

IMO, I would contact off forum support and see what they have to say, and if they wanted you to submit log files. Otherwise, you could continue to wait for a response here from a mod.

https://www.f-secure.com/en/support

Same issue on another machine, first on 26.6 and still on 26.8. What I can add: how much is retained per process, a trend on an otherwise idle machine, and why ordinary laptops may never show it.

Here is the AI-generated report:

System

HP ZBook 15 G5, 32 GB RAM, Windows 11 Pro build 26200 x64.
Windows Defender is off (AMRunningMode: Not running), so F-Secure is the only
active AV. VBS and HVCI are on and enforced, Credential Guard is running,
VirtualMachinePlatform is installed but the full Hyper-V role is not.

State after 46 hours on 26.6

physical in use : 31.27 GB of 31.59 GB      available     : 0.33 GB
paged pool      :  7.35 GB                  standby cache : 0.32 GB
nonpaged pool   :  4.03 GB

Tag      Paged MB   Nonpaged MB   Outstanding
PLE0       3952.8           0.0       445,417
Proc          0.0        1524.6       446,621
Toke        947.8           0.0       457,058
MiP2          0.0         653.4       446,622
DAV3        203.9           0.0       445,417
DAV0        139.6           0.0       444,637
AVBh          0.0         129.1       445,996
DAV1         68.7           0.0       445,417

With 0.32 GB of standby cache there is effectively no file cache left, which
is what made the machine unusable rather than merely full.

These eight tags hold 7.44 GB between them, about 17,900 bytes per retained
process object. Their outstanding counts are within 3% of each other, so one
allocation of each is retained together.

Attribution

Searching for the tag strings across all driver binaries maps each
non-Microsoft tag to exactly two files:

findstr /M /L /C:PLE0 C:\Windows\System32\drivers\*.sys
  C:\Windows\System32\drivers\rtp1.sys
  C:\Windows\System32\drivers\rtp2.sys

The same holds for DAV0, DAV1, DAV3 and AVBh. Proc, Toke and MiP2 are
Windows' own tags. The kernel frees an EPROCESS only when nothing references
it any longer, so 446,621 outstanding Proc allocations mean process objects
are kept alive long after their processes exited, and that count tracks tags
that exist only in rtp1.sys and rtp2.sys.

Open handles in user mode cannot explain it. About two hours before this
sample, the handles open in all processes together, of every type, numbered
209,408, less than half the outstanding Proc count above.

Retention per process on 26.8

The product updated from 26.6 to 26.8 between my measurements. rtp1.sys and
rtp2.sys are byte-identical across that update (1.1.2607.9217, 2026-08-18,
480,848 bytes). Everything below is on 26.8.

Idle, load and idle intervals, where the load creates 200 short-lived
processes with cmd.exe /c exit. Changes in outstanding allocations,
measured 5 seconds after the load:

                 run 1, load 4.9 s              run 2, load 6.5 s
             idle   load   per process     idle   load   per process
Proc            5    204          1.02       49    213          1.07
Toke            5    205          1.03      108    207          1.04
PLE0            8    384          1.92       13    433          2.17

"idle" is the idle interval of the same length right after the load, and
"per process" is the load change divided by 200. The background was quiet in
run 1, and subtracting its idle interval gives 1.00, 1.00 and 1.88. It was
noisy in run 2, where idle changes around the load ranged from -139 to +108,
so run 2 is best read as gross figures.

Short-term and long-term behaviour

Part of this is released again within minutes. Tracking 300 processes for
7 minutes:

              PLE0   Proc
baseline      2278   1943
+5 s          +498   +294
+30 s         +278   +282
+120 s        +217   +226
+300 s        +380   +364
+420 s        +498   +495

Within two minutes PLE0 fell back by more than half and Proc by about a
quarter. After that the counts rose again with no further load from the
test, so other process creation on the machine dominated, and this test
cannot say how much of the 300 is eventually released.

The long-run counts answer that instead. Proc and PLE0 differed by 0.3% at
46 hours, and by 0.4% at 4.8 hours on 26.8 (below). Over hours, roughly one
PLE0 allocation remains per retained process object, and the counts keep
growing until a reboot.

A three-hour trend on an idle machine, 26.8

Sampled every ten minutes with nobody using the machine:

time     uptime h    PLE0      Proc     paged pool    available
21:03        1.93    3,931     3,414       1,100 MB     15.73 GB
22:03        2.93   49,987    49,503       1,849 MB     13.09 GB
23:03        3.94   86,101    85,638       2,480 MB     10.20 GB
23:53        4.77  113,095   112,667       2,814 MB      7.74 GB

About 38,500 Proc allocations and 600 MB of paged pool per hour, and
available memory halved in under three hours. Since the update the machine has run out
of memory more than once, each time within a day of a reboot.

Why ordinary laptops may never show it

At about 18 KB per process this needs a process-dense workload. On a machine
that starts only a few hundred processes a day it adds up to a few megabytes,
which would fit the reply above that it does not show on two ordinary
laptops.

Developer tooling is enough, though. The trend above came from an idle
machine with such tooling running: a directory watcher written as a shell
loop runs grep for every file in a folder every few seconds, and under Git
for Windows each external command costs several processes. Shortly after the
trend, sampling the process list for 90 seconds found 537 new processes.
Over the same interval the Proc count rose by 758, since a poll four times a
second misses most processes that live only tens of milliseconds.

Reproduction

for ($i = 0; $i -lt 200; $i++) { & cmd.exe /c exit 0 }

Read the PLE0 and Proc tags with poolmon (poolmon /iPLE0, poolmon /iProc)
before and after, compared with an idle interval of the same length.

Not included

No FSDIAG bundle, and no test with real-time protection disabled. Defender is
off on this machine, so that test needs the machine off the network first.