DrivePool version: 2.3.13.1687 (64-bit)
covefs.sys version: 2.0.393.0
OS: Windows 11 Pro 25H2, build 26200.8653
RAM: 64 GB
Over several months my machine has slowed to a crawl after 1–2+ weeks of uptime. I've now traced it to a kernel paged-pool leak that pool-tag data attributes to CoveFS (covefs.sys). After 17 days of uptime, paged pool had grown to 10.1 GB (vs. a healthy 1–3 GB), and roughly 7.5 GB of that is attributable to CoveFS — partly direct COFS allocations, and partly security token objects that appear to be leaked one-per-file-operation.
A reboot fixes it every time, but the leak comes back as uptime accumulates.
Top paged-pool tags after 17 days of uptime (outstanding = allocs − frees):
1. COFS itself holds 2.7 GB across 11.2 million outstanding allocations that are never freed.
2. Toke and SeTd outstanding counts match exactly (2,015,462) — that's ~2 million kernel token objects alive at once, accounting for another ~4.7 GB with SeAt/SeDt. No user-mode process on the system has an abnormal handle count (highest is Chrome at ~15k), so these tokens are being referenced kernel-side. My working theory is that covefs.sys captures a security context (token reference) per file operation and doesn't release it, which would explain the token counts growing in lockstep with the COFS allocation count.
Impact
- Paged pool grows roughly linearly with uptime/file activity: I've measured 15.6 GB after ~7 days, 12.2 GB after 7 days, and 10.1 GB after 17 days on separate boots.
- Once pool gets large enough, the whole machine degrades — at ~15 GB, every process spawn (CreateProcess) took 1–6 seconds machine-wide.
- System commit ends up 30–40 GB higher than the sum of all process private bytes.
How I collected the data
Pool tags were read via NtQuerySystemInformation(SystemPoolTagInformation) (equivalent to poolmon output). Happy to re-run this and share fresh numbers at any uptime, collect a poolmon log, or gather anything else that would help — memory dumps, StableBit troubleshooting data, etc. Just tell me what you need.
Is this a known issue, and is there anything in 2.3.x newer than 2.3.1687 (or a beta) that addresses it?
Question
DylanFromWinnipeg
DrivePool version: 2.3.13.1687 (64-bit)
covefs.sys version: 2.0.393.0
OS: Windows 11 Pro 25H2, build 26200.8653
RAM: 64 GB
Over several months my machine has slowed to a crawl after 1–2+ weeks of uptime. I've now traced it to a kernel paged-pool leak that pool-tag data attributes to CoveFS (covefs.sys). After 17 days of uptime, paged pool had grown to 10.1 GB (vs. a healthy 1–3 GB), and roughly 7.5 GB of that is attributable to CoveFS — partly direct COFS allocations, and partly security token objects that appear to be leaked one-per-file-operation.
A reboot fixes it every time, but the leak comes back as uptime accumulates.
Top paged-pool tags after 17 days of uptime (outstanding = allocs − frees):
- Tag: Toke (security tokens), Paged Pool: 3567 MB, Outstanding allocations: 2,015,462
- Tag: COFS (CoveFS), Paged Pool: 2719 MB, Outstanding allocations: 11,267,288
- Tag: SeAt (token attributes), Paged Pool: 740 MB, Outstanding allocations: 8,076,304
- Tag: SeTd (token dynamic part), Paged Pool: 277 MB, Outstanding allocations: 2,015,462
- Tag: SeDt, Paged Pool: 153 MB, Outstanding allocations: 2,006,079
Two things stand out:
1. COFS itself holds 2.7 GB across 11.2 million outstanding allocations that are never freed.
2. Toke and SeTd outstanding counts match exactly (2,015,462) — that's ~2 million kernel token objects alive at once, accounting for another ~4.7 GB with SeAt/SeDt. No user-mode process on the system has an abnormal handle count (highest is Chrome at ~15k), so these tokens are being referenced kernel-side. My working theory is that covefs.sys captures a security context (token reference) per file operation and doesn't release it, which would explain the token counts growing in lockstep with the COFS allocation count.
Impact
- Paged pool grows roughly linearly with uptime/file activity: I've measured 15.6 GB after ~7 days, 12.2 GB after 7 days, and 10.1 GB after 17 days on separate boots.
- Once pool gets large enough, the whole machine degrades — at ~15 GB, every process spawn (CreateProcess) took 1–6 seconds machine-wide.
- System commit ends up 30–40 GB higher than the sum of all process private bytes.
How I collected the data
Pool tags were read via NtQuerySystemInformation(SystemPoolTagInformation) (equivalent to poolmon output). Happy to re-run this and share fresh numbers at any uptime, collect a poolmon log, or gather anything else that would help — memory dumps, StableBit troubleshooting data, etc. Just tell me what you need.
Is this a known issue, and is there anything in 2.3.x newer than 2.3.1687 (or a beta) that addresses it?
1 answer to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.