BAD_POOL_HEADER (19) BSOD

NTDEV
1

Is there some place where I could get some info on how to find the root cause of this error? I don’t know how to “internal pool links must be walked”.

Larry C

Here is the output for !analyze -v:

4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa8005f443f0, The pool entry we were looking for within the page.
Arg3: fffffa8005f45330, The next pool entry.
Arg4: 0000000004f443e8, (reserved)

Debugging Details:

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: fffffa8005f443f0 Nonpaged pool

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800019f8cae to fffff800018ce1c0

STACK_TEXT:
fffff880023acbc8 fffff800019f8cae : 0000000000000019 0000000000000020 fffffa8005f443f0 fffffa8005f45330 : nt!KeBugCheckEx
fffff880023acbd0 fffff80001bc0633 : fffffa8007a4bb60 0000000000000001 fffffa803545464d fffffa80039be040 : nt!ExDeferredFreePool+0x12da
fffff880023acc80 fffff800018d7851 : fffff80001a6b200 fffff80001bc0601 fffffa80039be000 fffff80000000000 : nt!IopProcessWorkItem+0x23
fffff880023accb0 fffff80001b64e6a : 0000000000000000 fffffa80039be040 0000000000000080 fffffa80039b1740 : nt!ExpWorkerThread+0x111
fffff880023acd40 fffff800018bef06 : fffff8800213c180 fffffa80039be040 fffff880021470c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880023acd80 0000000000000000 : fffff880023ad000 fffff880023a7000 fffff880023ac9e0 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+23
fffff800`01bc0633 488bcb mov rcx,rbx

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!IopProcessWorkItem+23

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4f76721c

FAILURE_BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

Followup: MachineOwner

2

This article ultimately describes why this bugcheck happens:

http://analyze-v.com/?p=734

(It takes a while to get there, but stick with it)

Basically there’s some kind of memory corruption going on. You can walk the
pool page to categorize the corruption a bit more, but that isn’t always
helpful in tracking down the root cause. Generally Driver Verifier’s Special
Pool option is the easiest way to track these down, you may want to try
enabling it on any drivers in the machine that you think are suspect (yours,
third party, etc.)

-scott
OSR

wrote in message news:xxxxx@ntdev…

Is there some place where I could get some info on how to find the root
cause of this error? I don’t know how to “internal pool links must be
walked”.

Larry C

Here is the output for !analyze -v:

4: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa8005f443f0, The pool entry we were looking for within the page.
Arg3: fffffa8005f45330, The next pool entry.
Arg4: 0000000004f443e8, (reserved)

Debugging Details:

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: fffffa8005f443f0 Nonpaged pool

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800019f8cae to fffff800018ce1c0

STACK_TEXT:
fffff880023acbc8 fffff800019f8cae : 0000000000000019 0000000000000020
fffffa8005f443f0 fffffa8005f45330 : nt!KeBugCheckEx
fffff880023acbd0 fffff80001bc0633 : fffffa8007a4bb60 0000000000000001
fffffa803545464d fffffa80039be040 : nt!ExDeferredFreePool+0x12da
fffff880023acc80 fffff800018d7851 : fffff80001a6b200 fffff80001bc0601
fffffa80039be000 fffff80000000000 : nt!IopProcessWorkItem+0x23
fffff880023accb0 fffff80001b64e6a : 0000000000000000 fffffa80039be040
0000000000000080 fffffa80039b1740 : nt!ExpWorkerThread+0x111
fffff880023acd40 fffff800018bef06 : fffff8800213c180 fffffa80039be040
fffff880021470c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880023acd80 0000000000000000 : fffff880023ad000 fffff880023a7000
fffff880023ac9e0 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+23
fffff800`01bc0633 488bcb mov rcx,rbx

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!IopProcessWorkItem+23

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4f76721c

FAILURE_BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

Followup: MachineOwner

3

>
Read my essays on storage allocators on my MVP Tips site

www.flounder.com/mvp_tips.htm

You have allocated a block of size N and written more bytes into the
address than N. It could be as little as N+1 bytes, but it is typically
more. Part of it depends on whether or not N is a multiple of an
allocation unit, such as 4 or 8.

Check every allocation you do and make sure are not overrunning a buffer.
On a read operation, or a DeviceIoControl that is doing input, you are
required to obey the buffer length limit given to you; this error is
particularly indicative of failing to handle the buffer length (watch out
for off-by-1 errors!) properly fot DO_BUFFERED_IO or MODE_BUFFERED I/O.m

When you overrun a buffer, you overwrite memory allocator state. This
error is thebresult.

If you used tags, the tag of the block of storage preceding the damaged
block could tell you who owns the block that was too short.

Try running with Driver Verifier enabled and Special Pool enabled within DV.
joe

Is there some place where I could get some info on how to find the root
cause of this error? I don’t know how to “internal pool links must be
walked”.

Larry C

Here is the output for !analyze -v:

4: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the
driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa8005f443f0, The pool entry we were looking for within the
page.
Arg3: fffffa8005f45330, The next pool entry.
Arg4: 0000000004f443e8, (reserved)

Debugging Details:

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: fffffa8005f443f0 Nonpaged pool

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800019f8cae to fffff800018ce1c0

STACK_TEXT:
fffff880023acbc8 fffff800019f8cae : 0000000000000019 0000000000000020
fffffa8005f443f0 fffffa8005f45330 : nt!KeBugCheckEx
fffff880023acbd0 fffff80001bc0633 : fffffa8007a4bb60 0000000000000001
fffffa803545464d fffffa80039be040 : nt!ExDeferredFreePool+0x12da
fffff880023acc80 fffff800018d7851 : fffff80001a6b200 fffff80001bc0601
fffffa80039be000 fffff80000000000 : nt!IopProcessWorkItem+0x23
fffff880023accb0 fffff80001b64e6a : 0000000000000000 fffffa80039be040
0000000000000080 fffffa80039b1740 : nt!ExpWorkerThread+0x111
fffff880023acd40 fffff800018bef06 : fffff8800213c180 fffffa80039be040
fffff880021470c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880023acd80 0000000000000000 : fffff880023ad000 fffff880023a7000
fffff880023ac9e0 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+23
fffff800`01bc0633 488bcb mov rcx,rbx

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!IopProcessWorkItem+23

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4f76721c

FAILURE_BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

BUCKET_ID: X64_0x19_20_nt!IopProcessWorkItem+23

Followup: MachineOwner

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer