Windows 11 Pro 26H1 (build 28000.3231): Nonpaged pool grows continuously under VadS/VadF tags until reboot

Question

Windows 11 Pro 26H1 (build 28000.3231): Nonpaged pool grows continuously under VadS/VadF tags until reboot

Brian Parks 5

Service Windows 11 Pro, version 26H1, OS build 28000.3231.

Scenario On every PC running build 28000.3231, nonpaged pool memory grows steadily under the VadS and VadF pool tags (with a smaller amount under Vad ). It’s never released while the system is running; only a reboot frees it. The PCs run normal desktop and background workloads.

Result The VAD pool tags grow by about 4 to 20 MB per hour, depending on how busy the PC is. After a few days they hold 1 to 3 GB of nonpaged pool. On a 16 GB PC, that’s over 10% of physical memory after 5 days of uptime.

Environment

4 PCs on Windows 11 Pro 26H1, build 28000.3231: all affected.
6 PCs on build 26100 (Windows Server 2025 and Windows 11 IoT Enterprise LTSC 24H2) with comparable workloads: not affected. VadS/VadF stay at 2 to 4 MB after up to 12 days of uptime.
No pending cumulative updates are offered for build 28000.3231.

Troubleshooting efforts

Process memory: per-process nonpaged pool usage and handle counts don’t grow over several hours, and no process shows as responsible.
Address space regions: the total virtual memory region count across all readable processes stays flat while the VAD pool grows.
Service restarts: restarting the most active applications and services doesn’t release the pool.
Process creation: reducing how often processes are created slows the growth only slightly.
Allocation trace: a Windows Performance Recorder trace filtered to the VadS/VadF/Vad tags shows unfreed allocations from many unrelated processes, including processes that had already exited.
Call stacks: a trace with allocation stacks shows about 98% of the unfreed allocations with stacks entirely within ntoskrnl.exe. No third-party driver appears on the allocation path.

Steps to reproduce

Run Windows 11 Pro 26H1 build 28000.3231 with ordinary workloads.
Monitor nonpaged pool by tag (for example with poolmon, sorted by nonpaged bytes) over several hours.
VadS and VadF grow continuously, while the same workloads on build 26100 don’t.

Question Is this a known issue in build 28000.3231, and is a fix planned in an upcoming cumulative update?

Service
Windows 11 Pro, version 26H1, OS build 28000.3231.

Scenario
On every PC running build 28000.3231, nonpaged pool memory grows steadily under the VadS and VadF pool tags (with a smaller amount under Vad ). It’s never released while the system is running; only a reboot frees it. The PCs run normal desktop and background workloads.

Result
The VAD pool tags grow by about 4 to 20 MB per hour, depending on how busy the PC is. After a few days they hold 1 to 3 GB of nonpaged pool. On a 16 GB PC, that’s over 10% of physical memory after 5 days of uptime.

Environment

4 PCs on Windows 11 Pro 26H1, build 28000.3231: all affected.
6 PCs on build 26100 (Windows Server 2025 and Windows 11 IoT Enterprise LTSC 24H2) with comparable workloads: not affected. VadS/VadF stay at 2 to 4 MB after up to 12 days of uptime.
No pending cumulative updates are offered for build 28000.3231.

Troubleshooting efforts

Process memory: per-process nonpaged pool usage and handle counts don’t grow over several hours, and no process shows as responsible.
Address space regions: the total virtual memory region count across all readable processes stays flat while the VAD pool grows.
Service restarts: restarting the most active applications and services doesn’t release the pool.
Process creation: reducing how often processes are created slows the growth only slightly.
Allocation trace: a Windows Performance Recorder trace filtered to the VadS/VadF/Vad tags shows unfreed allocations from many unrelated processes, including processes that had already exited.
Call stacks: a trace with allocation stacks shows about 98% of the unfreed allocations with stacks entirely within ntoskrnl.exe. No third-party driver appears on the allocation path.

Steps to reproduce

Run Windows 11 Pro 26H1 build 28000.3231 with ordinary workloads.
Monitor nonpaged pool by tag (for example with poolmon, sorted by nonpaged bytes) over several hours.
VadS and VadF grow continuously, while the same workloads on build 26100 don’t.

Question
Is this a known issue in build 28000.3231, and is a fix planned in an upcoming cumulative update?

Neil D 34,660 Reputation points Volunteer Moderator

2026-10-26T10:29:56.39+00:00

@Brian Parks You should use the Windows Insider program tags for anything related to insider builds. The tags you have chosen or were chosen automatically cover windows consumer release to the public.

Windows Insider program
Andrei Makoldin 0 Reputation points

2026-10-28T18:32:09.7866667+00:00
Same issue here, also on Windows 11 Pro 26H1 build 28000.3231. Adding my measurements in case they help.

System: AMD Ryzen 9 5950X, 64 GB RAM, ASUS TUF GAMING B550M-PLUS. Developer workstation; build tools and coding agents start a lot of short-lived processes (git, conhost, pwsh, node, dotnet, python), roughly 60+ process starts per minute.

Long uptime: after ~135 h without a reboot, the nonpaged pool reached 25.8 GB. Of that, 24.2 GB was under the VAD tags: Vad 19.05 GB, VadS 4.58 GB, VadF 0.60 GB, about 180 million outstanding allocations. Committed memory reached 79 of 88 GB, and the system-managed pagefile grew from 10 GB to 20 GB. Only a reboot releases the memory.

Current: 7.7 h after a reboot, the VAD tags hold 676 MB / 5.85 million outstanding allocations (~88 MB/h average; much faster during heavy process churn).

Not attributable to live processes: walking the address space of all accessible processes with VirtualQueryEx gives only ~0.36 million regions in total, versus 5.85 million outstanding VAD allocations. There are no zombie processes: 472 Proc pool objects for 462 live processes.

Leak is tied to process exit. Controlled test, launching and exiting processes in a loop, background rate subtracted (noisy, approximate):

pwsh -NoProfile -Command exit: ~280-500 VAD allocations left per process

node -e 0: ~40-200 per process

git --version: ~13 per process

cmd /c exit: ~5 per process

The steady background growth (hundreds of VADs per second) correlates with process creation, not with CPU or GPU load. Stopping the Visual Studio debugger made no difference.

This is consistent with your WPR finding that the unfreed allocation stacks are inside ntoskrnl.exe.

Is this a known issue for 28000.3231, and is a fix planned in an upcoming cumulative update? Until then, rebooting every 2-3 days is the only workaround I have found.

3 answers

Your answer

Neil D 34,660 Reputation points Volunteer Moderator

2026-10-26T10:29:56.39+00:00

@Brian Parks You should use the Windows Insider program tags for anything related to insider builds. The tags you have chosen or were chosen automatically cover windows consumer release to the public.

Windows Insider program
Andrei Makoldin 0 Reputation points

2026-10-28T18:32:09.7866667+00:00

Same issue here, also on Windows 11 Pro 26H1 build 28000.3231. Adding my measurements in case they help.

System: AMD Ryzen 9 5950X, 64 GB RAM, ASUS TUF GAMING B550M-PLUS. Developer workstation; build tools and coding agents start a lot of short-lived processes (git, conhost, pwsh, node, dotnet, python), roughly 60+ process starts per minute.

Long uptime: after ~135 h without a reboot, the nonpaged pool reached 25.8 GB. Of that, 24.2 GB was under the VAD tags: Vad 19.05 GB, VadS 4.58 GB, VadF 0.60 GB, about 180 million outstanding allocations. Committed memory reached 79 of 88 GB, and the system-managed pagefile grew from 10 GB to 20 GB. Only a reboot releases the memory.

Current: 7.7 h after a reboot, the VAD tags hold 676 MB / 5.85 million outstanding allocations (~88 MB/h average; much faster during heavy process churn).

Not attributable to live processes: walking the address space of all accessible processes with VirtualQueryEx gives only ~0.36 million regions in total, versus 5.85 million outstanding VAD allocations. There are no zombie processes: 472 Proc pool objects for 462 live processes.

Leak is tied to process exit. Controlled test, launching and exiting processes in a loop, background rate subtracted (noisy, approximate):

pwsh -NoProfile -Command exit: ~280-500 VAD allocations left per process

node -e 0: ~40-200 per process

git --version: ~13 per process

cmd /c exit: ~5 per process

The steady background growth (hundreds of VADs per second) correlates with process creation, not with CPU or GPU load. Stopping the Visual Studio debugger made no difference.

This is consistent with your WPR finding that the unfreed allocation stacks are inside ntoskrnl.exe.

Is this a known issue for 28000.3231, and is a fix planned in an upcoming cumulative update? Until then, rebooting every 2-3 days is the only workaround I have found.

Answer 1

kobeni chan 0

Hello is there any fix yet?

0 comments

Answer 2

CrazyKats 20,295 Volunteer Moderator

Hi,

That build is now up to 28000.3365.

If the issue continues please post the

issued in the Feedback Hub (WIN+F)

and use record so they get the diagnostics.

Also may sure to file the FB publicly and

share the link here for others.

Andrei Makoldin 0 Reputation points

2026-10-29T05:26:10.3366667+00:00

Thanks. I'm already on 28000.3365 (KB5127653) and the leak is still there. Tested right after a reboot: each "pwsh -NoProfile -c exit" still leaves ~225-250 Vad/VadS/VadF allocations in nonpaged pool per process launch/exit (3 runs: 249, 223, 227; background subtracted), and they are not released after waiting.

I've filed it in Feedback Hub with a "Recreate my problem"

Answer 3

There is currently no publicly documented Microsoft known issue or announced cumulative-update fix for VadS/VadF nonpaged-pool growth on Windows 11 26H1 build 28000.3231; submit the existing traces as a build-specific Windows kernel bug and request escalation.

KB5127646 is the October 13, 2026 cumulative update that installs build 28000.3231. Its fixes and known issues do not mention VadS, VadF, VAD allocations, or nonpaged-pool growth.^1^ The current 26H1 release-health page likewise has no corresponding open issue or planned resolution.^2^ The resolved-issues history contains no matching entry either.^3^

Consequently, it is not possible to confirm from public Microsoft information that a fix is scheduled for the next cumulative update.

Submit the evidence to Microsoft

Your cross-build comparison and allocation stacks are already more useful than repeating generic driver, process, or service-isolation tests.

Press Windows+F to open Feedback Hub.
Sign in so that you can search for existing reports and track your submission.
Search for terms such as:
- VadS VadF nonpaged pool 28000.3231
- 26H1 VAD pool leak
If an exact report exists, select Give similar feedback. Otherwise, select Give new feedback and classify it as a Problem.
Use a precise title, for example:

Windows 11 26H1 build 28000.3231 continuously leaks nonpaged pool under VadS/VadF
Include:
- Growth rate and uptime measurements.
- Results from all four affected 28000.3231 systems.
- The build 26100 control results.
- PoolMon snapshots from shortly after boot and after several hours or days.
- The WPR/WPA allocation trace with pool tags and stacks.
- The observation that allocations remain attributed to exited processes.
- Confirmation that approximately 98% of captured stacks remain within ntoskrnl.exe.
Under Attachments, attach the trace and relevant screenshots. If offered, select Save a local copy of diagnostics and attachments before submitting.
Retain and share the resulting Feedback Hub link when opening a support case.

Feedback Hub is Microsoft's channel for reporting unexpected Windows behavior and supports attachments and diagnostic recording; Microsoft Support is the appropriate channel when direct investigation or an immediate response is required.^4^

For managed or business devices, open a Microsoft Support for Business case and request Windows kernel memory-management escalation. Provide the Feedback Hub link and traces rather than starting again with application restarts or basic process-memory checks.

Interim handling

Reboot before memory pressure becomes operationally significant. Your evidence indicates that this releases the accumulated pool; no documented live mitigation is available.
Continue applying later 26H1 cumulative updates, but verify the behavior after each update rather than assuming it was fixed silently.
Do not deploy the published 26H1 Known Issue Rollback policies for this symptom. The currently documented KIR and mitigations target unrelated Explorer, Remote Desktop, and other listed issues, not VAD pool growth.^2^
Avoid attributing the leak conclusively to a third-party driver or to ntoskrnl.exe solely from the captured allocation stack. The data supports escalation of a probable build-specific kernel regression, but Microsoft analysis is needed to establish the retaining component and whether a private or future public fix exists.

References