Pools are where the operating system and its components obtain data storage, and we need to divert our attention to them for a moment. The data structures that represent system objects created and used by applications (and by the system itself) reside in these pools. Pools are accessible only in privileged mode, so you must transition to the operating system to see the objects stored in the pools.
The paged pool is where the system allocates data that can be paged out to disk. In the nonpaged pool, pages do not leave memory. Space is obtained here if the data structures stored there can be touched by interrupt routines or inside the spinlock critical sections which prevent multiprocessor conflicts within the operating system. These pages must remain in memory because page faults are not permitted within interrupts or spinlocks.
Uncontrolled growth in nonpaged pool space is a bug which you must watch for. If a computer is short of memory, you should check nonpaged pool size. This can vary quite a bit from one computer to the next, depending on the use of system services. You should note the nonpaged pool size at system startup, and compare that to its present value. It should not grow spontaneously during system operation, although each new object a program creates will use some nonpaged pool space. Gradual growth of nonpaged pool space is called a pool leak but, unlike pool leaks in the backyard, these pools get larger if there is a leak: stuff leaks in instead of out. A typical cause for a pool leak is an application's repeated inadvertent opening of a file or some other object.
The Memory: Nonpaged Pool Allocs indicate the total number of allocations currently in the pool. A division indicates the average size of the allocations, 211 bytes in this case. This quotient trends in the direction of the size of a leak if there is a pool leak. If there is a pool leak, the current number of allocations rises. Total allocations will certainly grow. You may have to watch these values for hours before you catch a pool leak.
Luckily, each process also has counters for Pool Nonpaged Bytes and Pool Paged Bytes. These are not precise counts, but rather estimates by the system Object Manager, which bills for pool usage based on object addressability rather than creation and destruction. In other words, a process is billed for the space to hold a thread object when the object is created and also when the handle to the object is duplicated. So process pool statistics tend to be overestimates, which we tell you so that you don't expect them to add up to the totals of the pool counters in the Memory object. The important thing is that if you have a pool leak you probably are able to discover which process is leaking by looking at the Process pool statistics.
As well as watching for leaks, we recommend you don't add protocols and drivers to your computer unless you need them. Windows NT is so easy to configure it is sometimes tempting to start everything possible. But there's no free lunch. Even idle protocols use pool space.