Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

How to use the special pool feature to isolate pool damage

View products that this article applies to.


Pool damage may cause many of the most evasive issues with Windows NT. Pool damage is caused when a kernel-mode component writes to memory outside the allocated pool area. By writing to memory beyond the boundary of its allocated area, it is likely that another area of allocated memory, possibly owned by another component, is overwritten. This damage can cause problems such as blue screens in completely unrelated areas of code. A kernel-mode component reading beyond its allocated area can also cause problems.

Whether it is caused by Original Equipment Manufacturers (OEM) drivers or problems in Windows, pool damage problems are some of the most difficult to identify. Usually, all that can be seen in a crash dump analysis is the symptom of the actual problem, such as a data area becoming damaged and causing problems in a completely unrelated block of code. Until now, it was almost impossible to find the segment of code that damages the memory.

The source of pool damage can now be identified at the instruction causing the pool damage. A new memory management utility that is named Special Pool is included with Windows NT 4.0 Service Pack 4 (SP4), Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Special Pool utility identifies the kernel-mode component that is damaging pool data by writing to memory outside its allocated area.

Note Memory tuning does not apply to Windows Vista and Windows Server 2008. However the special pool feature does apply for these products.

↑ Back to the top

More Information

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

The special Pool utility allocates two pages of virtual memory for every pool allocation that is requested through ExAllocatePoolWithTag that matches the following criteria:
  • The allocation request must be for a size smaller than the maximum allocation that will fit in a pool page.
  • The request must match the PoolTag specification in the registry.
For pool overrun detection, the first page is used to contain the allocation at the end of the page. The second page is a guard page. For pool underrun detection, the first page is the guard page. It is followed by a page that contains the allocation at the beginning of the page.

Overrun detection is probably the most used. For overrun detection, the requested allocation is positioned at the end of the first page by backing up the request size from the end of the page. The allocation size is rounded up to an 8-byte boundary. A pattern key, the size, and the pool tag information are written to the header at the first eight bytes of the first page. The pattern is also propagated throughout the page. Because the allocation is positioned on the nearest 8-byte boundary, there may be as many as seven slop bytes following the allocation. The pattern is also written to the slop bytes following the allocation.

The second page is the guard page. The guard page consists of a special page table entry (PTE) that is marked with no-access protection. By marking this second page with no-access protection, any code trying to read or write beyond the end of the first page immediately causes an access violation that results in a Stop 0x0000000A or Stop 0x0000001E error. This enables someone debugging the system to find the exact instruction that causes pool damage.

As a backup check to catch violators that write beyond the end of the allocation but not beyond the end of the page, the slop bytes at the end of the allocation are validated during the free pool request (ExFreePoolWithTag). The slop bytes are compared to the pattern in the allocation header to determine whether anything is overwritten in the slop byte area. If the verification check does not work, a Stop 0x00000001A error occurs.

This check does not necessarily find the exact block of code that causes pool damage. However, it may help identify the component that causes the damage.

To enable the Special Pool utility, add the following keys and values to the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Value Name: PoolTag

Data Type: REG_DWORD
Data: Pool tag mask | Allocation size mask | 0
The pool tag mask is the pool tag ID that contains masking characters of the pool in which you want to put in the special pool. This mask must be specified in hexadecimal in reverse order. This mask may also contain "?" to mask a single character or "*" to mask from here to the end of the tag. For example, to monitor all pools with a pool tag that begins with "Nt", specify "2A744E" (without the quotation marks), which represents "*tN".

The following table lists more examples.

Pool to monitor Character representation Pool tag mask
All pools "*" 0x2A
N??s "s??N" 0x733F3F4E
Allocation size mask specification places all pool allocations of a specified size into the special pool. This is also specified in hexadecimal. For example, if all allocations of 32 bytes are positioned in the special pool, specify 0x20.

When zero (0x0) is specified, the Special Pool utility is not initialized. In addition, the Special Pool utility is not initialized if the PoolTag registry value is not defined in the registry.
Value Name: PoolTagOverruns
Data Type: REG_DWORD
Data: 1 | 0
1 indicates that pool allocation overruns are detected for the tag specified. The allocation is located at the end of the page and the guard page follows.

0 indicates that pool allocation underruns are detected for the tag. The allocation is located at the beginning of the page, and the guard page comes before the page that contains the allocation.

Common use examples to create these two registry keys would be as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ Memory Management

Value Name: PoolTag
Data Type: REG_DWORD
Data: 0x2A

Value Name: PoolTagOverruns
Data Type: REG_DWORD
Data: 1

Note For Windows NT Terminal Server 4.0, you must disable KStackPool when you use special pool. To do this, add the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Value Name: EnableKStackPool
Data Type: REG_DWORD
Data: 0

1 - KStack pool always enabled
2 - KStack pool enabled for computers that have 256 MB or more memory (default)
If you do not make this change on Terminal Server computers that have 256 MB or more memory, you may receive "STOP 0x00000078 (PHASE0_EXCEPTION)" error messages.

Note The Special Pool feature may not work in Windows Server 2003 if there are insufficient special page table entries (PTEs). This issue typically occurs on single-user terminal servers that contain more than 1 GB of RAM and that have the memory management tuning values of the computer set to default values. This issue does not occur in 64-bit versions of Windows Server 2003.

A memory dump file analysis of the issue may contain the following information:
*** Virtual Memory Usage *** 
Physical Memory: 1015660 ( 4062640 Kb)
Page File: \??\C:\Pagefile1\pagefile.sys
Current: 4193280Kb Free Space: 4180856Kb
Minimum: 4193280Kb Maximum: 4193280Kb
Available Pages: 552680 ( 2210720 Kb)
ResAvail Pages: 932179 ( 3728716 Kb)
Locked IO Pages: 347 ( 1388 Kb)
Free System PTEs: 187166 ( 748664 Kb)
Free NP PTEs: 32765 ( 131060 Kb)
Free Special NP: 117228 ( 468912 Kb)
Modified Pages: 106 ( 424 Kb)
Modified PF Pages: 98 ( 392 Kb)
NonPagedPool Usage: 6599 ( 26396 Kb)
NonPagedPool Max: 65536 ( 262144 Kb)
PagedPool 0 Usage: 10697 ( 42788 Kb)
PagedPool 1 Usage: 1240 ( 4960 Kb)
PagedPool 2 Usage: 1239 ( 4956 Kb)
PagedPool 3 Usage: 1265 ( 5060 Kb)
PagedPool 4 Usage: 1231 ( 4924 Kb)
PagedPool Usage: 15672 ( 62688 Kb)
PagedPool Maximum: 90112 ( 360448 Kb)
Shared Commit: 3866 ( 15464 Kb)
Special Pool: 511 ( 2044 Kb) <-- very small
Shared Process: 5205 ( 20820 Kb)
PagedPool Commit: 15672 ( 62688 Kb)
Driver Commit: 2091 ( 8364 Kb)
Committed pages: 439832 ( 1759328 Kb)
Commit limit: 2023823 ( 8095292 Kb)

0: kd> dd nt!MmSpecialPoolRejected l8
8057afe0 00000000 00000000 00b2e59a 00000000 <-- A DWORD value of 3 causes special pool PTE's shortage.
8057aff0 00000000 00000000 00000000 00000000

8057afd8 nt!MiSpecialPoolFirstPte = 0xc022af78
8057afd4 nt!MiSpecialPoolLastPte = 0xc022af78
You can verify the issue by the size of the Special Pool that is allocated from the analysis. In this case, the issue occurs because the following special pool PTE values are equal:
  • MiSpecialPoolFirstPte
  • MiSpecialPoolLastPte
This issue may also occur if the value of the MmSpecialPoolRejected registry entry is three or larger.

To work around this issue, configure the value of the PagedPoolSize registry entry to a value that is smaller than the paged pool size that is permitted. For example, set the PagedPoolSize registry entry to a value 256 MB. If you want to configure a larger value, use the Performance Monitor utility to determine the computer's requirement for a larger paged pool size.

You can use the following values for PagedPoolSize registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
For Windows Server 2003 without a service pack:

Value Name: PagedPoolSize
Data Type: REG_DWORD
Data: 10000000
Base: Hexadecimal

For Windows Server 2003 with Service Pack 1 (SP1) installed:

Value Name: PagedPoolSize
Data Type: REG_DWORD
Base: Hexadecimal

Note After you make any of the registry changes that are described in this article, restart the computer to cause the changes to take effect.

If after you enable the Special Pool feature, the computer stops responding (hangs), and you receive an error message on a blue screen during startup, restart the computer by using the Last Known Good Configuration option. Enabling the Special Pool feature is not written to the Last Known Good Configuration entry in the registry until after a successful logon.

↑ Back to the top

Keywords: kb, kbenv, kbhowto, kbqfe, nt4sp4fea, nt5howto, public

↑ Back to the top

Article Info
Article ID : 188831
Revision : 1
Created on : 1/7/2017
Published on : 4/19/2013
Exists online : False
Views : 831