You are currently offline, waiting for your internet to reconnect

How to Troubleshoot "Stop 0x0000001E" with First Parameter of 0xC0000044

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":
// 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:
  1. 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
  2. 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.
  3. 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
  4. 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 32s f0d4d000 f0d4d000+12400 52 61 46 32f0d5455ff0d548ddf0d58151f0d58400f0d5a52ef0d5d754
  5. 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-1u f0d5455f-1f0d5455e 6851614632       push    0x32466152 <-Pool Tagf0d54563 68b80b0000       push    0xbb8      f0d54568 6a01             push    0x1        f0d5456a ff159cd2d4f0     call    dword ptr [NT!ExAllocatePoolWithTag(f0d4d29c)]
  6. 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.

Article ID: 264223 - Last Review: 12/05/2015 20:29:30 - Revision: 2.1

Microsoft Windows 2000 Server, Microsoft Windows 2000 Professional Edition, Microsoft Windows NT Server 4.0 Standard Edition

  • kbnosurvey kbarchive kberrmsg kbhowto kbtshoot KB264223