This article was previously published under Q264223
This article has been archived. It is offered "as is" and will no longer be updated.
A computer that is running Windows NT 4.0 or Windows 2000 may receive the following error message on a blue screen:
STOP 0x0000001E (0xC0000044, other parameters may vary)
The first parameter (0xC0000044) indicates "STATUS_QUOTA_EXCEEDED":
// MessageId: STATUS_QUOTA_EXCEEDED // MessageText: // Insufficient quota exists to complete the operation
This is indicative of a pool memory leak.
"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:
!driversLoaded System Driver SummaryBase Code Size Data Size Driver Name Creation Timef0d4d000 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.
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.
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.