BAD_POOL_HEADER bugcheck

[Paolo_Gatti]

I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on Vista64.
Firstly, the Arg1 value of 0x21 is not one that i recognize, as i understood it,
Arg1 cannot take the value 0x21.
(http://msdn.microsoft.com/en-us/library/ff557389(v=vs.85).aspx).

Secondly, when i enabled special pool with driver verifier I still get the same
BAD_POOL_HEADER bugcheck. I was hoping to see a different bugcheck (eg
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION, DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or
PAGE_FAULT_IN_FREED_SPECIAL_POOL etc …) which would then point me to where the
bug in my driver is.

Any thoughts/suggestions gratefully received.

thanks,

Paolo

– Output of !analyze-v included below.

0: 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: 0000000000000021,
Arg2: fffff880068f4000
Arg3: 0000000000010020
Arg4: 0000000000010000

Debugging Details:

BUGCHECK_STR: 0x19_21

POOL_ADDRESS: fffff880068f4000 Paged pool

DEFAULT_BUCKET_ID: VISTA_RC

PROCESS_NAME: devpathexer.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80001989220 to fffff800018b0450

STACK_TEXT:
fffffa6014eb34b8 fffff80001989220 : 0000000000000019 0000000000000021 fffff880068f4000 0000000000010020 : nt!KeBugCheckEx
fffffa6014eb34c0 fffffa6002bde187 : 0000000000000000 0000000000000002 0000000000000001 fffffa606d647470 : nt!ExDeferredFreePool+0x765
fffffa6014eb3570 fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0 fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17 [u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
fffffa6014eb36c0 fffff80001b1d5b9 : 0000000000000004 0000000000000040 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a
fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00 0000000000000000 fffffa8005b3d660 00000c4000000001 : nt!IopParseDevice+0x5f9
fffffa6014eb38a0 fffff80001b16622 : 0000000000000a68 fffffa8005b3d748 0000000000000100 0000000000000000 : nt!ObpLookupObjectName+0x205
fffffa6014eb39b0 fffff80001b1bc27 : 0000000002000000 0000000002000000 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2
fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830 fffff80002000000 0000000000000000 000000000018e848 : nt!IopCreateFile+0x287
fffffa6014eb3b20 fffff800018afef3 : fffff88006973170 fffffa8002dbabb0 0000000000000a78 fffff80001b1a314 : nt!NtCreateFile+0x78
fffffa6014eb3bb0 0000000077c4726a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000018e7b8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77c4726a

STACK_COMMAND: kb

FOLLOWUP_IP:
POCDrv64!PocDrvDispatch+c17 [u:\windows (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
fffffa6002bde187 e932030000 jmp POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)

FAULTING_SOURCE_CODE:
5489: &&
5490: (pHook->pDeviceName.Buffer != NULL)
5491: &&
5492: (pHook->pDeviceName.Length > 0)

5493: &&
5494: (irpStack->Parameters.Create.SecurityContext != NULL)
5495: )
5496: {
5497: LtProbe (“xLTx-PocDrvDispatch-38”);
5498: PocTrace ((

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: POCDrv64

IMAGE_NAME: POCDrv64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d020eb4

SYMBOL_NAME: POCDrv64!PocDrvDispatch+c17

FAILURE_BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

Followup: MachineOwner

0: kd>

[Mark_Roddy]

Google says:

Arg1: 0000000000000021, the data following the pool block being freed
is corrupt. Typically this means the consumer (call stack ) has
overrun the block.
Arg2: fffff880068f4000, The pool pointer being freed.
Arg3: 0000000000010020, The number of bytes allocated for the pool block.
Arg4: 0000000000010000, The corrupted value found following the pool block.

What version of windbg are you using?
Do you tag all your allocations?
What is the tag on this block?
Does the data look familiar?

Mark Roddy

On Fri, Dec 17, 2010 at 7:00 AM, wrote:
>
> I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on Vista64.
> Firstly, the Arg1 value of 0x21 is not one that i recognize, as i understood it,
> Arg1 cannot take the value 0x21.
> (http://msdn.microsoft.com/en-us/library/ff557389(v=vs.85).aspx).
>
> Secondly, when i enabled special pool with driver verifier I still get the same
> BAD_POOL_HEADER bugcheck. I was hoping to see a different bugcheck (eg
> SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION, DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or
> PAGE_FAULT_IN_FREED_SPECIAL_POOL etc …) which would then point me to where the
> bug in my driver is.
>
> Any thoughts/suggestions ?gratefully received.
>
> thanks,
>
> Paolo
>
> – Output of !analyze-v included below.
>
>
>
> 0: 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: 0000000000000021,
> Arg2: fffff880068f4000
> Arg3: 0000000000010020
> Arg4: 0000000000010000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: ?0x19_21
>
> POOL_ADDRESS: ?fffff880068f4000 Paged pool
>
> DEFAULT_BUCKET_ID: ?VISTA_RC
>
> PROCESS_NAME: ?devpathexer.exe
>
> CURRENT_IRQL: ?0
>
> LAST_CONTROL_TRANSFER: ?from fffff80001989220 to fffff800018b0450
>
> STACK_TEXT:
> fffffa6014eb34b8 fffff80001989220 : 0000000000000019 0000000000000021 fffff880068f4000 0000000000010020 : nt!KeBugCheckEx
> fffffa6014eb34c0 fffffa6002bde187 : 0000000000000000 0000000000000002 0000000000000001 fffffa606d647470 : nt!ExDeferredFreePool+0x765
> fffffa6014eb3570 fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0 fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17 [u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
> fffffa6014eb36c0 fffff80001b1d5b9 : 0000000000000004 0000000000000040 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a
> fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00 0000000000000000 fffffa8005b3d660 00000c4000000001 : nt!IopParseDevice+0x5f9
> fffffa6014eb38a0 fffff80001b16622 : 0000000000000a68 fffffa8005b3d748 0000000000000100 0000000000000000 : nt!ObpLookupObjectName+0x205
> fffffa6014eb39b0 fffff80001b1bc27 : 0000000002000000 0000000002000000 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2
> fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830 fffff80002000000 0000000000000000 000000000018e848 : nt!IopCreateFile+0x287
> fffffa6014eb3b20 fffff800018afef3 : fffff88006973170 fffffa8002dbabb0 0000000000000a78 fffff80001b1a314 : nt!NtCreateFile+0x78
> fffffa6014eb3bb0 0000000077c4726a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
> 000000000018e7b8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77c4726a
>
>
> STACK_COMMAND: ?kb
>
> FOLLOWUP_IP:
> POCDrv64!PocDrvDispatch+c17 [u:\windows (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
> fffffa6002bde187 e932030000 ? ? ?jmp ? ? POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)
>
> FAULTING_SOURCE_CODE:
> ?5489: ? ? ? ? ? ? ? ? ? ? ? ? &&
> ?5490: ? ? ? ? ? ? ? ? ? ? ? ? (pHook->pDeviceName.Buffer != NULL)
> ?5491: ? ? ? ? ? ? ? ? ? ? ? ? &&
> ?5492: ? ? ? ? ? ? ? ? ? ? ? ? (pHook->pDeviceName.Length > 0)
>> 5493: ? ? ? ? ? ? ? ? ? ? ? ? &&
> ?5494: ? ? ? ? ? ? ? ? ? ? ? ? (irpStack->Parameters.Create.SecurityContext != NULL)
> ?5495: ? ? ? ? ? ? ? ? ? ? ? ? )
> ?5496: ? ? ? ? ? ? ? ? ? ? {
> ?5497: ? ? ? ? ? ? ? ? ? ? ? ? LtProbe (“xLTx-PocDrvDispatch-38”);
> ?5498: ? ? ? ? ? ? ? ? ? ? ? ? PocTrace ? ?((
>
>
> SYMBOL_STACK_INDEX: ?2
>
> FOLLOWUP_NAME: ?MachineOwner
>
> MODULE_NAME: POCDrv64
>
> IMAGE_NAME: ?POCDrv64.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d020eb4
>
> SYMBOL_NAME: ?POCDrv64!PocDrvDispatch+c17
>
> FAILURE_BUCKET_ID: ?X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17
>
> BUCKET_ID: ?X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17
>
> Followup: MachineOwner
> ---------
>
> 0: kd>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

[OSR_Community_User]

The most common cause of BAD_POOL_HEADER is taking a long walk off a short
pier, that is, buffer overrun. One of the common places this can happen is
overwriting your device extension block in some way (I’ve found that even
special pool doesn’t catch these, since apparently IoCreateDevice doesn’t
use special pool). I’d suspect that pDeviceName, but if that is correct,
look elsewhere for places you do memory allocations.

It would actually be useful if special pool actually told us what objects
will be allocated in the special pool.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, December 17, 2010 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] BAD_POOL_HEADER bugcheck

I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on
Vista64.
Firstly, the Arg1 value of 0x21 is not one that i recognize, as i understood
it,
Arg1 cannot take the value 0x21.
(http://msdn.microsoft.com/en-us/library/ff557389(v=vs.85).aspx).

Secondly, when i enabled special pool with driver verifier I still get the
same BAD_POOL_HEADER bugcheck. I was hoping to see a different bugcheck (eg
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION,
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or PAGE_FAULT_IN_FREED_SPECIAL_POOL
etc …) which would then point me to where the bug in my driver is.

Any thoughts/suggestions gratefully received.

thanks,

Paolo

– Output of !analyze-v included below.

0: 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: 0000000000000021,
Arg2: fffff880068f4000
Arg3: 0000000000010020
Arg4: 0000000000010000

Debugging Details:

BUGCHECK_STR: 0x19_21

POOL_ADDRESS: fffff880068f4000 Paged pool

DEFAULT_BUCKET_ID: VISTA_RC

PROCESS_NAME: devpathexer.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80001989220 to fffff800018b0450

STACK_TEXT:
fffffa6014eb34b8 fffff80001989220 : 0000000000000019 0000000000000021
fffff880068f4000 0000000000010020 : nt!KeBugCheckEx fffffa6014eb34c0 fffffa6002bde187 : 0000000000000000 0000000000000002 0000000000000001 fffffa606d647470 : nt!ExDeferredFreePool+0x765 fffffa6014eb3570 fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0 fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17
[u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493] fffffa6014eb36c0 fffff80001b1d5b9 : 0000000000000004 0000000000000040 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00 0000000000000000 fffffa8005b3d660 00000c4000000001 : nt!IopParseDevice+0x5f9 fffffa6014eb38a0 fffff80001b16622 : 0000000000000a68 fffffa8005b3d748 0000000000000100 0000000000000000 : nt!ObpLookupObjectName+0x205 fffffa6014eb39b0 fffff80001b1bc27 : 0000000002000000 0000000002000000 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2 fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830 fffff80002000000 0000000000000000 000000000018e848 : nt!IopCreateFile+0x287 fffffa6014eb3b20 fffff800018afef3 : fffff88006973170 fffffa8002dbabb0 0000000000000a78 fffff80001b1a314 : nt!NtCreateFile+0x78 fffffa6014eb3bb0 0000000077c4726a
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceCopyEnd+0x13
000000000018e7b8 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x77c4726a

STACK_COMMAND: kb

FOLLOWUP_IP:
POCDrv64!PocDrvDispatch+c17 [u:\windows (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
fffffa6002bde187 e932030000 jmp POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)

FAULTING_SOURCE_CODE:
5489: &&
5490: (pHook->pDeviceName.Buffer != NULL)
5491: &&
5492: (pHook->pDeviceName.Length > 0)

5493: &&
5494: (irpStack->Parameters.Create.SecurityContext
!= NULL)
5495: )
5496: {
5497: LtProbe (“xLTx-PocDrvDispatch-38”);
5498: PocTrace ((

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: POCDrv64

IMAGE_NAME: POCDrv64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d020eb4

SYMBOL_NAME: POCDrv64!PocDrvDispatch+c17

FAILURE_BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

Followup: MachineOwner

0: kd>

---

NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[OSR_Community_User]

As far as “tagged allocations”, I’ve seen people consistently use ‘MYDV’ =
for
every kind of block they allocate; good practice is that every type of =
block
has a different tag, and for some reason this is not evident to a lot of
programmers. They seem to think that tags are per-driver, instead of
per-block-type. And Don Burn cornered me once and gave me a lecture on =
used
tagged deallocation, too, and he is right.
joe
=20

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, December 17, 2010 7:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BAD_POOL_HEADER bugcheck

Google says:

Arg1: 0000000000000021, the data following the pool block being freed is
corrupt. Typically this means the consumer (call stack ) has overrun =
the
block.
Arg2: fffff880068f4000, The pool pointer being freed.
Arg3: 0000000000010020, The number of bytes allocated for the pool =
block.
Arg4: 0000000000010000, The corrupted value found following the pool =
block.

What version of windbg are you using?
Do you tag all your allocations?
What is the tag on this block?
Does the data look familiar?

Mark Roddy

On Fri, Dec 17, 2010 at 7:00 AM, wrote:
>
> I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on
Vista64.
> Firstly, the Arg1 value of 0x21 is not one that i recognize, as i=20
> understood it,
> Arg1 cannot take the value 0x21.
> =
(http://msdn.microsoft.com/en-us/library/ff557389(v=3Dvs.85).aspx).
>
> Secondly, when i enabled special pool with driver verifier I still get =

> the same BAD_POOL_HEADER bugcheck. I was hoping to see a different=20
> bugcheck (eg SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION,=20
> DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or=20
> PAGE_FAULT_IN_FREED_SPECIAL_POOL etc …) which would then point me to
where the bug in my driver is.
>
> Any thoughts/suggestions =A0gratefully received.
>
> thanks,
>
> Paolo
>
> – Output of !analyze-v included below.
>
>
>
> 0: kd> !analyze -v
> *************************************************************
>
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0
=A0 =A0=20
> *
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bugcheck Analysis =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0
> *
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0
=A0 =A0=20
> *
> *************************************************************
>
>
> 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=20
> of the problem, and then special pool applied to the suspect tags or=20
> the driver verifier to a suspect driver.
> Arguments:
> Arg1: 0000000000000021,
> Arg2: fffff880068f4000
> Arg3: 0000000000010020
> Arg4: 0000000000010000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: =A00x19_21
>
> POOL_ADDRESS: =A0fffff880068f4000 Paged pool
>
> DEFAULT_BUCKET_ID: =A0VISTA_RC
>
> PROCESS_NAME: =A0devpathexer.exe
>
> CURRENT_IRQL: =A00
>
> LAST_CONTROL_TRANSFER: =A0from fffff80001989220 to fffff800018b0450
>
> STACK_TEXT:
> fffffa6014eb34b8 fffff80001989220 : 0000000000000019=20<br>&gt; 0000000000000021 fffff880068f4000 0000000000010020 :=20
> nt!KeBugCheckEx fffffa6014eb34c0 fffffa6002bde187 :=20
> 0000000000000000 0000000000000002 0000000000000001=20<br>&gt; fffffa606d647470 : nt!ExDeferredFreePool+0x765 fffffa6014eb3570=20<br>&gt; fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0=20
> fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17=20
> [u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493] fffffa6014eb36c0 =<br><br>&gt; fffff80001b1d5b9 : 0000000000000004 0000000000000040=20
> 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a=20
> fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00=20<br>&gt; 0000000000000000 fffffa8005b3d660 00000c4000000001 :=20
> nt!IopParseDevice+0x5f9 fffffa6014eb38a0 fffff80001b16622 :=20
> 0000000000000a68 fffffa8005b3d748 0000000000000100=20<br>&gt; 0000000000000000 : nt!ObpLookupObjectName+0x205 fffffa6014eb39b0=20<br>&gt; fffff80001b1bc27 : 0000000002000000 0000000002000000=20
> 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2=20
> fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830=20<br>&gt; fffff80002000000 0000000000000000 000000000018e848 :=20
> nt!IopCreateFile+0x287 fffffa6014eb3b20 fffff800018afef3 :=20
> fffff88006973170 fffffa8002dbabb0 0000000000000a78=20<br>&gt; fffff80001b1a314 : nt!NtCreateFile+0x78 fffffa6014eb3bb0=20<br>&gt; 0000000077c4726a : 0000000000000000 0000000000000000=20
> 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
> 000000000018e7b8 0000000000000000 : 0000000000000000=20<br>&gt; 0000000000000000 0000000000000000 0000000000000000 : 0x77c4726a
>
>
> STACK_COMMAND: =A0kb
>
> FOLLOWUP_IP:
> POCDrv64!PocDrvDispatch+c17 [u:\windows=20<br>&gt; (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
> fffffa6002bde187 e932030000 =A0 =A0 =A0jmp =A0 =A0=20<br>&gt; POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)
>
> FAULTING_SOURCE_CODE:
> =A05489: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> =A05490: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
(pHook->pDeviceName.Buffer !=3D NULL)
> =A05491: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> =A05492: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
(pHook->pDeviceName.Length > 0)
>> 5493: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> =A05494: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
> (irpStack->Parameters.Create.SecurityContext !=3D NULL)
> =A05495: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 )
> =A05496: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A05497: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LtProbe =
(“xLTx-PocDrvDispatch-38”);
> =A05498: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PocTrace =A0 =
=A0((
>
>
> SYMBOL_STACK_INDEX: =A02
>
> FOLLOWUP_NAME: =A0MachineOwner
>
> MODULE_NAME: POCDrv64
>
> IMAGE_NAME: =A0POCDrv64.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: =A04d020eb4
>
> SYMBOL_NAME: =A0POCDrv64!PocDrvDispatch+c17
>
> FAILURE_BUCKET_ID: =A0X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17
>
> BUCKET_ID: =A0X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17
>
> Followup: MachineOwner
> ---------
>
> 0: kd>
>
> —
> NTDEV is sponsored by OSR
>
> 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=20
> http://www.osronline.com/page.cfm?name=3DListServer
>

—
NTDEV is sponsored by OSR

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

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[OSR_Community_User]

Two more possible causes of bad poolheader bugchecks:

First, make sure that EVERY local variable which is a pointer is declared as
whatever * name = NULL;

And that when you allocate a block of data that has pointers (for example,
your device extension), that you initialize ALL pointers to NULL.

The reason is that an uninitialized pointer can be a pointer to arbitrary
information, including blocks once held by other drivers, and therefore not
subject to special pool allocation when it is selected for your driver. But
if you set the pointers to NULL, you will get access faults if you try to
use them without initialization.

A common excuse for not initializing variables is that it is “inefficient”,
but this is a complete myth. First off, in debug mode, it probably costs
one instruction cycle, which in a 2.8GHz machine is about 350ps, except that
on the average in a superscaler, it costs 175ps because two instructions are
being dispatched. Second, in release mode, if you have done the assignment
of a real pointer value, the NULL assignment is deleted because it is
redundant, so its cost is truly zero.

It doesn’t hurt to compile at /W4 to catch certain errors of variable usage,
or use PREFast, to help find some errors lke this. But note the implication
here: the memory damage may not take place in the special pool because you
are clobbering the memory of some other random arbitrary kernel component!
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, December 17, 2010 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] BAD_POOL_HEADER bugcheck

I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on
Vista64.
Firstly, the Arg1 value of 0x21 is not one that i recognize, as i understood
it,
Arg1 cannot take the value 0x21.
(http://msdn.microsoft.com/en-us/library/ff557389(v=vs.85).aspx).

Secondly, when i enabled special pool with driver verifier I still get the
same BAD_POOL_HEADER bugcheck. I was hoping to see a different bugcheck (eg
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION,
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or PAGE_FAULT_IN_FREED_SPECIAL_POOL
etc …) which would then point me to where the bug in my driver is.

Any thoughts/suggestions gratefully received.

thanks,

Paolo

– Output of !analyze-v included below.

0: 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: 0000000000000021,
Arg2: fffff880068f4000
Arg3: 0000000000010020
Arg4: 0000000000010000

Debugging Details:

BUGCHECK_STR: 0x19_21

POOL_ADDRESS: fffff880068f4000 Paged pool

DEFAULT_BUCKET_ID: VISTA_RC

PROCESS_NAME: devpathexer.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80001989220 to fffff800018b0450

STACK_TEXT:
fffffa6014eb34b8 fffff80001989220 : 0000000000000019 0000000000000021
fffff880068f4000 0000000000010020 : nt!KeBugCheckEx fffffa6014eb34c0 fffffa6002bde187 : 0000000000000000 0000000000000002 0000000000000001 fffffa606d647470 : nt!ExDeferredFreePool+0x765 fffffa6014eb3570 fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0 fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17
[u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493] fffffa6014eb36c0 fffff80001b1d5b9 : 0000000000000004 0000000000000040 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00 0000000000000000 fffffa8005b3d660 00000c4000000001 : nt!IopParseDevice+0x5f9 fffffa6014eb38a0 fffff80001b16622 : 0000000000000a68 fffffa8005b3d748 0000000000000100 0000000000000000 : nt!ObpLookupObjectName+0x205 fffffa6014eb39b0 fffff80001b1bc27 : 0000000002000000 0000000002000000 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2 fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830 fffff80002000000 0000000000000000 000000000018e848 : nt!IopCreateFile+0x287 fffffa6014eb3b20 fffff800018afef3 : fffff88006973170 fffffa8002dbabb0 0000000000000a78 fffff80001b1a314 : nt!NtCreateFile+0x78 fffffa6014eb3bb0 0000000077c4726a
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceCopyEnd+0x13
000000000018e7b8 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x77c4726a

STACK_COMMAND: kb

FOLLOWUP_IP:
POCDrv64!PocDrvDispatch+c17 [u:\windows (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
fffffa6002bde187 e932030000 jmp POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)

FAULTING_SOURCE_CODE:
5489: &&
5490: (pHook->pDeviceName.Buffer != NULL)
5491: &&
5492: (pHook->pDeviceName.Length > 0)

5493: &&
5494: (irpStack->Parameters.Create.SecurityContext
!= NULL)
5495: )
5496: {
5497: LtProbe (“xLTx-PocDrvDispatch-38”);
5498: PocTrace ((

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: POCDrv64

IMAGE_NAME: POCDrv64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d020eb4

SYMBOL_NAME: POCDrv64!PocDrvDispatch+c17

FAILURE_BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

Followup: MachineOwner

0: kd>

---

NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[Pavel_Lebedinsky]

Regarding IoCreateDevice not using special pool:

By default driver verifier does not verify allocations made by the kernel; you have to explicitly add ntoskrnl.exe to the list of verifier drivers (e.g. verifier.exe /flags 1 /driver mydriver.sys ntoskrnl.exe will enable special pool for mydriver.sys and the kernel).

Another option is to enable special pool globally using the Memory Management\PoolTag registry value.

Note that enabling special pool for the entire kernel (or globally) needs a substantial amount of memory/VA space in order to be effective. You would probably want a 64 bit system with at least a couple of gigabytes of RAM, preferably more than that.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Saturday, December 18, 2010 7:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] BAD_POOL_HEADER bugcheck

The most common cause of BAD_POOL_HEADER is taking a long walk off a short pier, that is, buffer overrun. One of the common places this can happen is overwriting your device extension block in some way (I’ve found that even special pool doesn’t catch these, since apparently IoCreateDevice doesn’t use special pool). I’d suspect that pDeviceName, but if that is correct, look elsewhere for places you do memory allocations.

It would actually be useful if special pool actually told us what objects will be allocated in the special pool.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, December 17, 2010 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] BAD_POOL_HEADER bugcheck

I am getting BAD_POOL_HEADER bugcheck when running some DTM tests on Vista64.
Firstly, the Arg1 value of 0x21 is not one that i recognize, as i understood it,
Arg1 cannot take the value 0x21.
(http://msdn.microsoft.com/en-us/library/ff557389(v=vs.85).aspx).

Secondly, when i enabled special pool with driver verifier I still get the same BAD_POOL_HEADER bugcheck. I was hoping to see a different bugcheck (eg SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION,
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL or PAGE_FAULT_IN_FREED_SPECIAL_POOL etc …) which would then point me to where the bug in my driver is.

Any thoughts/suggestions gratefully received.

thanks,

Paolo

– Output of !analyze-v included below.

0: 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: 0000000000000021,
Arg2: fffff880068f4000
Arg3: 0000000000010020
Arg4: 0000000000010000

Debugging Details:

BUGCHECK_STR: 0x19_21

POOL_ADDRESS: fffff880068f4000 Paged pool

DEFAULT_BUCKET_ID: VISTA_RC

PROCESS_NAME: devpathexer.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80001989220 to fffff800018b0450

STACK_TEXT:
fffffa6014eb34b8 fffff80001989220 : 0000000000000019 0000000000000021
fffff880068f4000 0000000000010020 : nt!KeBugCheckEx fffffa6014eb34c0 fffffa6002bde187 : 0000000000000000 0000000000000002 0000000000000001 fffffa606d647470 : nt!ExDeferredFreePool+0x765 fffffa6014eb3570 fffff80001cbb58a : fffffa8000000008 fffff9800a18cbd0 fffffa8000010018 fffff98002000000 : POCDrv64!PocDrvDispatch+0xc17 [u:\windowspoc\code\e-poc-v6\pocdrv\pocdrv.c @ 5493] fffffa6014eb36c0 fffff80001b1d5b9 : 0000000000000004 0000000000000040 0000000000000040 fffffa80059e0810 : nt!IovCallDriver+0x34a fffffa6014eb3700 fffff80001b15705 : fffffa8004da0e00 0000000000000000 fffffa8005b3d660 00000c4000000001 : nt!IopParseDevice+0x5f9 fffffa6014eb38a0 fffff80001b16622 : 0000000000000a68 fffffa8005b3d748 0000000000000100 0000000000000000 : nt!ObpLookupObjectName+0x205 fffffa6014eb39b0 fffff80001b1bc27 : 0000000002000000 0000000002000000 0000000000000001 fffffa6014eb3ca0 : nt!ObOpenObjectByName+0x2f2 fffffa6014eb3a80 fffff80001b25aa8 : 000000000018e830 fffff80002000000 0000000000000000 000000000018e848 : nt!IopCreateFile+0x287 fffffa6014eb3b20 fffff800018afef3 : fffff88006973170 fffffa8002dbabb0 0000000000000a78 fffff80001b1a314 : nt!NtCreateFile+0x78 fffffa6014eb3bb0 0000000077c4726a
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceCopyEnd+0x13
000000000018e7b8 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x77c4726a

STACK_COMMAND: kb

FOLLOWUP_IP:
POCDrv64!PocDrvDispatch+c17 [u:\windows (se)\code\e-poc-v6\pocdrv\pocdrv.c @ 5493]
fffffa6002bde187 e932030000 jmp POCDrv64!PocDrvDispatch+0xf4e (fffffa6002bde4be)

FAULTING_SOURCE_CODE:
5489: &&
5490: (pHook->pDeviceName.Buffer != NULL)
5491: &&
5492: (pHook->pDeviceName.Length > 0)

5493: &&
5494: (irpStack->Parameters.Create.SecurityContext
!= NULL)
5495: )
5496: {
5497: LtProbe (“xLTx-PocDrvDispatch-38”);
5498: PocTrace ((

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: POCDrv64

IMAGE_NAME: POCDrv64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d020eb4

SYMBOL_NAME: POCDrv64!PocDrvDispatch+c17

FAILURE_BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

BUCKET_ID: X64_0x19_21_VRF_POCDrv64!PocDrvDispatch+c17

Followup: MachineOwner

0: kd>

---

NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

---

NTDEV is sponsored by OSR

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