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

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:

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:

   !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

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 32
   s f0d4d000 f0d4d000+12400 52 61 46 32
   f0d5455f
   f0d548dd
   f0d58151
   f0d58400
   f0d5a52e
   f0d5d754

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-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)]

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.