Article ID: 265879 - View products that this article applies to.
This article was previously published under Q265879
NoticeThis article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center
(http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fwin2000)is a starting point for planning your migration strategy from Windows 2000. For more information see the Microsoft Support Lifecycle Policy
This article describes how to debug Stop C2 error messages.
Windows 2000 contains many built-in features that enhance the pool allocation process. A number of new stop codes have been added that help you locate drivers that do not function correctly. Because of these additional features, you may be able to find the root cause of the driver's malfunction by simple debugging.
The following procedure describes how to debug a OxC2 stop.
First, check the stop documentation. For example:
After you have collected detailed information about the 0xC2 stop, use the debugger:
BAD_POOL_CALLER (0xC2) The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc. 1 - type of pool violation the caller is guilty of. 6 - the pool address being freed is already free. 7 - the pool address being freed is already free. 8 - parameter 2 is the IRQL allocating at, parameter 3 is the pool type 9 - parameter 2 is the IRQL freeing at, parameter 3 is the pool type Parameter 1 = 0x1, 0x2, or 0x4 : Pool header has been corrupted Parameter 2 = Pointer to pool header Parameter 3 = First part of pool header contents Parameter 4 = 0 Parameter 1 = 0x6 : Attempt to free pool which was already freed Parameter 2 = Reserved (__LINE__) Parameter 3 = Pointer to pool header Parameter 4 = Pool header contents Parameter 1 = 0x7 : Attempt to free pool which was already freed Parameter 2 = Reserved (__LINE__) Parameter 3 = Pointer to pool header Parameter 4 = 0 Parameter 1 = 0x8 : Attempt to allocate pool at invalid IRQL Parameter 2 = Current IRQL Parameter 3 = Pool type Parameter 4 = Size of allocation Parameter 1 = 0x9 : Attempt to free pool at invalid IRQL Parameter 2 = Current IRQL Parameter 3 = Pool type Parameter 4 = Address of pool Parameter 1 = 0x40 : Attempt to free usermode address to kernel pool Parameter 2 = Starting address Parameter 3 = Start of system address space Parameter 4 = 0 Parameter 1 = 0x41 : Attempt to free a non-allocated nonpaged pool address Parameter 2 = Starting address Parameter 3 = physical page frame Parameter 4 = highest physical page frame Parameter 1 = 0x50 : Attempt to free a non-allocated paged pool address Parameter 2 = Starting address Parameter 3 = Start offset in pages from beginning of paged pool Parameter 4 = Size in bytes of paged pool Parameter 1 = 0x99 : Attempt to free pool with invalid address (or corruption in pool header) Parameter 2 = Address being freed Parameter 3 = 0 Parameter 4 = 0
The stop documentation indicates that memory is being freed. This information is indicated by the following line:
E:\bin>i386kd -z K:\DOWNLOAD\memory.dmp Loading Dump File [K:\DOWNLOAD\memory.dmp] Full Kernel Dump File ... 0: kd> !reload GOOD HOUSEKEEPING DONE HERE 0: kd> dd kibugcheckdata l8 DUMPING THE ERROR 8047fba0 000000c2 00000007 00000b68 815bade0 8047fbb0 815bade8 e1007000 00000000 818988c0 0: kd> kv DUMPING STACK ChildEBP RetAddr Args to Child bdce0348 be11dc84 e1fff000 a08d0008 000007f8 banshee!vH3ImageTransferMm32 bdce037c be116f18 be85fd78 00000001 bdce03dc banshee!vMmXferNative bdce03ac be113eec e1fff000 e25e2a38 bdce03dc banshee!vPutBits bdce03e8 a008e47f e1ff86f8 e25e2a38 e1fef908 banshee!DrvCopyBits bdce0430 a008e899 be113d40 bdce04d8 e1ff86f8 win32k!OffCopyBits bdce04e4 a008e4d1 e1ff86f8 e25e2a38 00000000 win32k!SpBitBlt
Parameter 1 = 0x7: Attempt to free pool which was already freed.But the stack shows that the video card is in the process of a write, so you must continue to investigate. First, you must determine if this computer is a multiprocessor.
The preceding text indicates that memory is freed through the driver drivername. This could be the possible root cause.
0: kd> ~1 SWITCH PROC 1: kd> kv DUMPING STACK ChildEBP RetAddr Args to Child bde81b7c 8046894d 815bade8 00000000 be03bb2b ntkrnlmp!ExFreePoolWithTag bde81b88 be03bb2b 815bade8 be03ca94 815bade8 ntkrnlmp!ExFreePool 00000128 00000000 00000000 00000000 00000000 BADDRIVER
Next, define the driver:
The preceding text indicates that the driver is used by a third-party software package. This driver is most likely the cause of the error. To further investigate this issue, search the Microsoft Knowledge Base for more information. Also, check the file properties with Windows Explorer or by using a Hex editor on the file itself. You can also check the vendor's Web site for any updates or known issues.
1: kd> !drivers Loaded System Driver Summary Base Code Size Data Size Driver Name Creation Time 80400000 139f40 (1255 kb) 4f3c0 (316 kb) ntoskrnl.exe Tue Dec 07 14:05:26 1999 80062000 ffe0 ( 63 kb) 3d60 ( 15 kb) hal.dll Tue Nov 02 20:14:22 1999 ed410000 1760 ( 5 kb) 1000 ( 4 kb) BOOTVID.dll Wed Nov 03 20:24:33 1999 ed49c000 1b00 ( 6 kb) 680 ( 1 kb) gameenum.sys Sat Sep 25 14:35:57 1999 ed080000 a000 ( 40 kb) 20c0 ( 8 kb) VIDEOPRT.SYS Sat Nov 06 16:55:20 1999 bfdcf000 1d480 ( 117 kb) 7520 ( 29 kb) mga64m.sys Mon Nov 29 20:47:46 1999 bfdbc000 11600 ( 69 kb) 1600 ( 5 kb) el90xnd5.sys Fri Oct 29 17:54:34 1999 ed090000 3a60 ( 14 kb) 5980 ( 22 kb) banshee.sys Fri Oct 29 19:00:56 1999 ed5df000 2e0 ( 0 kb) 4a0 ( 1 kb) audstub.sys Sat Sep 25 14:35:33 1999 ed370000 33e0 ( 12 kb) a40 ( 2 kb) raspti.sys Fri Oct 08 16:45:10 1999 ed0c0000 c5e0 ( 49 kb) 20e0 ( 8 kb) parallel.sys Fri Oct 22 18:00:54 1999 ed5e0000 580 ( 1 kb) 540 ( 1 kb) swenum.sys Sat Sep 25 14:36:31 1999 be552000 72a60 ( 458 kb) 13c40 ( 79 kb) mga64d.dll Tue Nov 30 04:33:19 1999 be113000 36f00 ( 219 kb) 7a20 ( 30 kb) banshee.dll Tue Nov 30 04:31:18 1999 be031000 FFFF ( FF kb) FFFF ( F kb) BADDRIVER.sys Mon Feb 30 23:22:43 2000 TOTAL: 7f8dc0 (8163 kb) 172140 (1480 kb) ( 0 kb 0 kb)