Context
Windows can lose usable memory because a kernel component keeps allocating pool memory, even when ordinary application processes look modest. PoolMon helps identify which allocation tags grow over time. The investigation needs a trend, a plausible driver mapping, and a controlled correction; the largest tag in one snapshot is not automatically a leak.
Confirm which memory population is growing
Record physical memory, committed memory, paged and nonpaged pool, process working sets, uptime, and workload changes. Nonpaged pool cannot simply be paged out to solve pressure. Increasing a pagefile therefore does not repair an unbounded kernel allocation problem.
Compare the incident with a known healthy interval. Kernel memory can legitimately grow with connections, files, or device activity, then stabilize or shrink. A leak hypothesis becomes stronger when outstanding allocations keep increasing under a comparable workload and do not return after the work subsides.
Collect PoolMon evidence safely
Microsoft includes PoolMon in the Windows Driver Kit. Use the installed tool's documented controls to inspect the relevant pool type and sort by bytes or allocation differences. Record timestamps and repeated samples rather than relying on a single screen.
Capture tag, pool type, allocation count, free count, outstanding difference, and bytes. Preserve the raw observations in an authorized diagnostic location. Kernel investigation rarely needs customer payloads; avoid collecting unrelated sensitive process data by default.
Ensure the sampling interval covers the suspected trigger. A leak tied to backup, security scanning, or network reconnects may not grow during a short idle observation. Correlate the tag trend with the actual operation timeline.
Map a tag to a responsible component
PoolMon's mapping support and the WDK tag information can help connect tags with drivers. Treat the mapping as an investigative lead. Tags may be shared or mapping information incomplete, and the component allocating memory may be responding to a problem elsewhere.
Record driver file, vendor, version, signing information, recent installation, and relevant event logs. Compare with the vendor's supported known-issue and update guidance. Do not remove a storage or network driver from a production server simply because its name resembles the tag.
Advanced verification or kernel debugging should follow an approved targeted procedure. Some diagnostic modes can deliberately stress drivers or cause a system failure. Start with nonintrusive trends and reproduce on an appropriate test host before escalating to disruptive diagnostics.
An illustrative network-filter leak
A server's nonpaged pool rises after a security-agent update. Application working sets are stable, and reboot temporarily clears the symptom. Repeated PoolMon samples identify a growing tag associated with a network-filter path during connection churn.
The team confirms the software version, reproduces the workload on a pilot host, and tests the vendor-supported correction. It compares the tag's growth and memory stability over the same workload duration. Reboot is retained as a recovery action where appropriate, but not presented as proof that the leak was fixed.
Quick diagnostic map
| Evidence | Interpretation to test | Next check |
|---|---|---|
| Nonpaged pool grows; processes stable | Kernel allocation pressure | Repeated PoolMon samples |
| Tag grows only with expected workload | Legitimate demand or leak | Recovery after workload ends |
| Tag maps to several components | Attribution uncertain | Driver versions and targeted reproduction |
| Reboot clears memory temporarily | State reset | Reproduce growth under the same trigger |
A focused operator exercise
On a representative test host, record a healthy memory baseline and driver inventory. Run the suspected trigger with a bounded workload while collecting repeated pool samples. Stop the workload and observe whether outstanding allocations stabilize or return.
Apply one supported driver or agent correction to a pilot, then repeat the same test. Validate application networking or storage as well as memory behavior. Retain a rollback method and access path. The acceptance receipt should identify the observed tag trend, candidate component, correction version, and test duration.
Monitor the recurrence window
Track pool growth rate and remaining system headroom, not only a universal absolute threshold. Include uptime and workload volume so the owner can estimate how quickly the host may become unstable. Reassess after future driver and endpoint-agent updates.
Frequently asked questions
Is the largest pool tag always the leaking driver?
No. Compare growth over time, workload correlation, mapping evidence, and a controlled correction.
Will a larger pagefile fix a nonpaged-pool leak?
It does not repair the allocation behavior. Identify and correct the responsible kernel or driver path while maintaining a recovery plan.
Continue the investigation
- Windows Pagefiles: Reconcile Commit and Crash-Dump Needs
- Defender Performance: Measure Before Adding Exclusions
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Windows Server & Active Directory to discuss implementation, validation and operational handover.
Technical reference
Use PoolMon to Find a Kernel-Mode Memory Leak - Windows drivers | Microsoft Learn
Example 9 Detecting a Pool Memory Leak - Windows drivers | Microsoft Learn