No formal product support is available from Microsoft for this Beta product. For information about obtaining support for a Beta release, please see the documentation included with the Beta product files, or check the Web location from which you downloaded the release. The information in this article applies to:
IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe. SUMMARY
Pool damage may be the root cause of many of the most evasive issues
with Windows NT. Pool damage is caused when a kernel-mode component
writes to memory outside of its 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.
MORE INFORMATIONWARNING: Using Registry Editor incorrectly can cause serious problems that
may require you to reinstall your operating system. Microsoft cannot
guarantee that problems resulting from the incorrect use of Registry Editor
can be solved. Use Registry Editor at your own risk.
Overrun detection is probably the most used. For overrun detection, the requested allocation is placed 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. Since the allocation is placed 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 attempting to read or write beyond the end of the first page immediately causes an access violation resulting in a Stop 0x0000000A or Stop 0x0000001E error. This enables someone debugging the system to identify the exact instruction causing 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 verify if 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 identify the exact piece of code causing the pool damage, but it may assist in identifying the component causing the damage. To activate the Special Pool utility, add the following keys and values to the registry:
The pool tag mask is the pool tag ID containing 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 beginning with "Nt", specify "2A744E" (without the quotation marks), which represents "*tN".The following table lists more examples:
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 placed 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.
"1" indicates that pool allocation overruns are detected for the tag specified. The allocation is placed at the end of the page and the guard page follows.
"0" indicates that pool allocation underruns are detected for the tag specified. The allocation is placed at the beginning of the page and the guard page precedes the page that contains the allocation. NOTE: For Windows NT Terminal Server 4.0, you need to disable KStackPool when using special pool. To do this, add the follow registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory ManagementIf you do not make this change on Terminal Server computers with >=256 MB, you may receive STOP 0x00000078 (PHASE0_EXCEPTION) error messages. Additional query words:
Keywords : kbenv kbtool |
Last Reviewed: November 25, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |