BAD_POOL_CALLER issue

WINDBG
1

Trying to debug bug check 0xc2.

got dump with verifier on. here is the analyze -v output
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 000000000000109b, (reserved)
Arg3: 0000000000000000, Memory contents of the pool block
Arg4: fffff8a0141cb010, Address of the block of pool being deallocated

Debugging Details:

POOL_ADDRESS: fffff8a0141cb010 Paged pool

BUGCHECK_STR: 0xc2_7

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002fb9be9 to fffff80002e86c00

STACK_TEXT:
fffff880099b94b8 fffff80002fb9be9 : 00000000000000c2 0000000000000007 000000000000109b 0000000000000000 : nt!KeBugCheckEx
fffff880099b94c0 fffff80002e48cd2 : 0000000000000000 fffff8a0141cb810 fffffa80144c15d0 000000000008c011 : nt!ExDeferredFreePool+0x1201
fffff880099b9570 fffff800031291bb : fffffa80144c1550 0000000000000011 000000000008c089 0000000000010286 : nt!MiDeleteSegmentPages+0x112
fffff880099b9640 fffff80002e8fe44 : 0000000000000000 fffff880014ffa00 fffffa8003d1e080 fffffa8003d1e080 : nt!MiSegmentDelete+0x7b
fffff880099b9680 fffff80002ecac3b : fffff880014ffa00 fffffa80144a6db0 0000000000000000 0000000000000000 : nt!ObfDereferenceObject+0xd4
fffff880099b96e0 fffff80002e9fb99 : fffff880014ffa64 fffffa80144a3e00 fffffa80144a6db0 0000000000000000 : nt!CcDeleteSharedCacheMap+0x1cb
fffff880099b9740 fffff880014ffb30 : fffffa80076b9180 0000000000000000 0000000000000001 0000000000000000 : nt!CcUninitializeCacheMap+0x389
fffff880099b97c0 fffff880014d08d6 : 0000000000000000 fffff8000302c200 0000000000000001 0000000000000000 : Ntfs!NtfsDeleteInternalAttributeStream+0xcc
fffff880099b9810 fffff880014485d0 : fffff8a0141c9660 fffff8a0141c9760 fffff8000302c200 fffff8a0141cdab0 : Ntfs!NtfsRemoveScb+0xe2
fffff880099b9850 fffff8800144787f : fffff8a0141c9630 fffff8000302c280 fffff880099b9a01 fffffa80139eb1e0 : Ntfs!NtfsPrepareFcbForRemoval+0x50
fffff880099b9880 fffff880014ce6f0 : fffffa80139eb1e0 fffffa80076b9180 fffff8a0141cda80 fffff8a0141cde18 : Ntfs!NtfsTeardownFromLcb+0x2af
fffff880099b9910 fffff8800144ea42 : fffffa80139eb1e0 fffffa80139eb1e0 fffff8a0141cda80 fffff880014dda00 : Ntfs!NtfsTeardownStructures+0x200
fffff880099b9990 fffff880014ddc53 : fffffa80139eb1e0 fffff8000302c280 fffff8a0141cda80 0000000000000009 : Ntfs!NtfsDecrementCloseCounts+0xa2
fffff880099b99d0 fffff880014cd2cf : fffffa80139eb1e0 fffff8a0141cdbb0 fffff8a0141cda80 fffffa80076b9180 : Ntfs!NtfsCommonClose+0x353
fffff880099b9aa0 fffff80002e90251 : 0000000000000000 fffff8000317ed00 fffff8000308d801 fffff80000000002 : Ntfs!NtfsFspClose+0x15f
fffff880099b9b70 fffff80003124ede : 0000000000000010 fffffa8018017040 0000000000000080 fffffa8003c8db30 : nt!ExpWorkerThread+0x111
fffff880099b9c00 fffff80002e77906 : fffff80003001e80 fffffa8018017040 fffffa801601a040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880099b9c40 0000000000000000 : fffff880099ba000 fffff880099b4000 fffff880099b9190 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiDeleteSegmentPages+112
fffff800`02e48cd2 4c8b8424d0000000 mov r8,qword ptr [rsp+0D0h]

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!MiDeleteSegmentPages+112

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 5147d9c6

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0xc2_7_VRF_nt!MiDeleteSegmentPages+112

BUCKET_ID: X64_0xc2_7_VRF_nt!MiDeleteSegmentPages+112

Followup: MachineOwner

Also tried using !verifier 0x80
0: kd> !verifier 0x80 fffff8a0141cb010

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address 0xfffff8a0141cb010.

Finished parsing all pool tracking information.
No entries matching address fffff8a0141cb010 have been found.

Any help to further debug this issue is appreciated.

2

Seems pretty self-explanatory. You called ExFreePool twice on the same
address, as it says. At some higher level, you caused soething o be
freed.mThe factvthat there is a worker thread involved suggests a race
condition. Lookmat places where you cause resource freeing. The
preseceof the decrement-count suggests that you may have failed to
increnent tge count somewhere, so it has gone to 0 and started to tear
something down that someother part of ypur driver thougt remained intact.
joe

Trying to debug bug check 0xc2.

got dump with verifier on. here is the analyze -v output
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a
bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 000000000000109b, (reserved)
Arg3: 0000000000000000, Memory contents of the pool block
Arg4: fffff8a0141cb010, Address of the block of pool being deallocated

Debugging Details:

POOL_ADDRESS: fffff8a0141cb010 Paged pool

BUGCHECK_STR: 0xc2_7

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002fb9be9 to fffff80002e86c00

STACK_TEXT:
fffff880099b94b8 fffff80002fb9be9 : 00000000000000c2 0000000000000007
000000000000109b 0000000000000000 : nt!KeBugCheckEx
fffff880099b94c0 fffff80002e48cd2 : 0000000000000000 fffff8a0141cb810
fffffa80144c15d0 000000000008c011 : nt!ExDeferredFreePool+0x1201
fffff880099b9570 fffff800031291bb : fffffa80144c1550 0000000000000011
000000000008c089 0000000000010286 : nt!MiDeleteSegmentPages+0x112
fffff880099b9640 fffff80002e8fe44 : 0000000000000000 fffff880014ffa00
fffffa8003d1e080 fffffa8003d1e080 : nt!MiSegmentDelete+0x7b
fffff880099b9680 fffff80002ecac3b : fffff880014ffa00 fffffa80144a6db0
0000000000000000 0000000000000000 : nt!ObfDereferenceObject+0xd4
fffff880099b96e0 fffff80002e9fb99 : fffff880014ffa64 fffffa80144a3e00
fffffa80144a6db0 0000000000000000 : nt!CcDeleteSharedCacheMap+0x1cb
fffff880099b9740 fffff880014ffb30 : fffffa80076b9180 0000000000000000
0000000000000001 0000000000000000 : nt!CcUninitializeCacheMap+0x389
fffff880099b97c0 fffff880014d08d6 : 0000000000000000 fffff8000302c200
0000000000000001 0000000000000000 :
Ntfs!NtfsDeleteInternalAttributeStream+0xcc
fffff880099b9810 fffff880014485d0 : fffff8a0141c9660 fffff8a0141c9760
fffff8000302c200 fffff8a0141cdab0 : Ntfs!NtfsRemoveScb+0xe2
fffff880099b9850 fffff8800144787f : fffff8a0141c9630 fffff8000302c280
fffff880099b9a01 fffffa80139eb1e0 : Ntfs!NtfsPrepareFcbForRemoval+0x50
fffff880099b9880 fffff880014ce6f0 : fffffa80139eb1e0 fffffa80076b9180
fffff8a0141cda80 fffff8a0141cde18 : Ntfs!NtfsTeardownFromLcb+0x2af
fffff880099b9910 fffff8800144ea42 : fffffa80139eb1e0 fffffa80139eb1e0
fffff8a0141cda80 fffff880014dda00 : Ntfs!NtfsTeardownStructures+0x200
fffff880099b9990 fffff880014ddc53 : fffffa80139eb1e0 fffff8000302c280
fffff8a0141cda80 0000000000000009 : Ntfs!NtfsDecrementCloseCounts+0xa2
fffff880099b99d0 fffff880014cd2cf : fffffa80139eb1e0 fffff8a0141cdbb0
fffff8a0141cda80 fffffa80076b9180 : Ntfs!NtfsCommonClose+0x353
fffff880099b9aa0 fffff80002e90251 : 0000000000000000 fffff8000317ed00
fffff8000308d801 fffff80000000002 : Ntfs!NtfsFspClose+0x15f
fffff880099b9b70 fffff80003124ede : 0000000000000010 fffffa8018017040
0000000000000080 fffffa8003c8db30 : nt!ExpWorkerThread+0x111
fffff880099b9c00 fffff80002e77906 : fffff80003001e80 fffffa8018017040
fffffa801601a040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880099b9c40 0000000000000000 : fffff880099ba000 fffff880099b4000
fffff880099b9190 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiDeleteSegmentPages+112
fffff800`02e48cd2 4c8b8424d0000000 mov r8,qword ptr [rsp+0D0h]

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!MiDeleteSegmentPages+112

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 5147d9c6

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0xc2_7_VRF_nt!MiDeleteSegmentPages+112

BUCKET_ID: X64_0xc2_7_VRF_nt!MiDeleteSegmentPages+112

Followup: MachineOwner

Also tried using !verifier 0x80
0: kd> !verifier 0x80 fffff8a0141cb010

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address
0xfffff8a0141cb010.

Finished parsing all pool tracking information.
No entries matching address fffff8a0141cb010 have been found.

Any help to further debug this issue is appreciated.

WINDBG is sponsored by OSR

OSR is hiring!! Info at 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

3

You are right.

But I am trying to debug which memory is freed twice :frowning:

4

What kind of driver is this? You can always try enabling Verifier on more
drivers, including the kernel itself.

-scott
OSR

wrote in message news:xxxxx@windbg…

You are right.

But I am trying to debug which memory is freed twice :frowning: