Article ID: 264223
Article Last Modified on 11/1/2006
APPLIES TO
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Professional Edition
- Microsoft Windows NT Server 4.0 Standard Edition
This article was previously published under Q264223
SUMMARY
A computer that is running Windows NT 4.0 or Windows 2000 may receive the following error message on a blue screen:
The first parameter (0xC0000044) indicates "STATUS_QUOTA_EXCEEDED":
This is indicative of a pool memory leak.
MORE INFORMATION
"Quota" is pool memory that is allocated on behalf of a process for creation of kernel-mode objects. When the pool allocation is made, quota is charged against the process that requests the object. If the quota limit is exceeded, Memory Manager checks to see if there is sufficient pool memory to satisfy the requested quota allocation. If not, the allocation does not succeed with a "STATUS_QUOTA_EXCEEDED" status.
The "Stop 0x0000001E" message is caused by an unsuccessful quota allocation that is necessary for the system to continue operating normally. There are two possible causes for this situation:
- Object handles are leaking because of an object (or handle) leak in a program.
- A driver is leaking pool memory from kernel mode.
You can usually identify the first case by using Performance Monitor to track object handles for each process. You can identify the second case by following this procedure:
- Identify which tag is allocating excessive amounts of pool memory. For additional information about how to do this, click the article number below to view the article in the Microsoft Knowledge Base:
177415 How to Use Poolmon to Troubleshoot Kernel-Mode Memory Leaks
- For example purposes, assume that the RaF2 pool tag has exhausted nearly all of the paged pool memory, but that you do not know which drivers use this tag. The RaF2 tag is equivalent to the following ASCII byte sequence: 0x52, 0x61, 0x46, 0x32.
- To find the owner of the tag, search the machine-language code of the suspected drivers individually for the tag's byte sequence. For example, to search the Sample.sys driver for the tag, search for the "52 61 46 32" byte sequence in the range of f0d4d000 to f0d4d000+12400. For example:
!drivers Loaded System Driver Summary Base Code Size Data Size Driver Name Creation Time f0d4d000 12400 (73 kb) 1540 (5 kb) SAMPLE.SYS Fri Oct 08 14:15:27 1997
- The search hits indicate memory locations in which the tag's byte sequence appears in the machine-language code. In the following search, six hits are found. This does not necessarily mean that the hits are valid. You must perform further verification.
0: kd> s f0d4d000 f0d4d000+12400 52 61 46 32 s f0d4d000 f0d4d000+12400 52 61 46 32 f0d5455f f0d548dd f0d58151 f0d58400 f0d5a52e f0d5d754
- To confirm that a search hit is valid, unassemble starting at the address of each hit minus one byte. In the following example, the first hit is unassembled starting at 0xf0d5455f-0x1. Note that the tag is pushed onto the stack before a call to the NT!ExAllocatePoolWithTag function.
0: kd> u f0d5455f-1 u f0d5455f-1 f0d5455e 6851614632 push 0x32466152 <-Pool Tag f0d54563 68b80b0000 push 0xbb8 f0d54568 6a01 push 0x1 f0d5456a ff159cd2d4f0 call dword ptr [NT!ExAllocatePoolWithTag(f0d4d29c)]
- In this example, you have confirmed that the Sample.sys driver allocates pool by using the leaking tag in at least one location. You can perform the same type of search on the other hits to further validate that the driver is using the pool tag. You can also search any other resident driver in the same manner, provided that all of the driver's code is resident at the time of the search.
Additional query words: 0x1e
Keywords: kberrmsg kbhowto kbtshoot KB264223
