IRP IRP_MJ_MDL_READ/IRP_MJ_MDL_READ_COMPLETE BSOD

[ben_tsang]

Hi All,

I have a mini filter which implements the fast I/O and IRP IRP_MJ_MDL_READ/IRP_MJ_MDL_READ_COMPLETE requests:

In IRP_MJ_MDL_READ I will allocate my own mdl and buffer with my data and return back, and put the mdl and buffer to a table.

In IRP_MJ_MDL_READ_COMPLETE I will check the table with mdl to check if it is my mdl, if yes, then I will free my mdl and free my buffer.

The filter was working for a few years, recently we got BSOD from the customer environment almost once a month as the following dump,all we know that the crashed computers were installed the McAfee virusScan enterprise 8.8 patches 2

The question is:
The buffer was corructed when we tried to free it, is there a way to find out who corructed the pool from the memory dump?

Thanks in advance
Ben

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: 0000000000000022,
Arg2: fffff8a00276a000
Arg3: 0000000000000001
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0x19_22

POOL_ADDRESS: fffff8a00276a000

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800016c8c80 to fffff80001673740

STACK_TEXT:
fffff8800844a808 fffff800016c8c80 : 0000000000000019 0000000000000022 fffff8a00276a000 0000000000000001 : nt!KeBugCheckEx
fffff8800844a810 fffff800017a8518 : 0000000000000000 fffff8800844a960 fffff8800844a8d0 fffff80000000001 : nt! ?? ::FNODOBFM::string'+0x72f8 fffff8800844a8a0 fffff8800600acb8 : 000000000000002e 0000000000000000 0000000000000000 0000000000000001 : nt!ExFreePoolWithTag+0x468 fffff8800844a950 fffff88001549027 : 0000000000000000 fffffa800d95a260 fffffa800fc1da00 0000000000000000 : MiniFilter!FreeMdlRead+0x90 fffff8800844a990 fffff8800154bb9d : fffff78000000300 fffff88006b581f0 fffffa800dacd200 fffffa800a67b900 : fltmgr!FltpPerformPreCallbacks+0x2f7 fffff8800844aa90 fffff8800154bd7e : fffffa800a67b910 fffffa8034865cd0 fffffa8009d2f150 fffffa801dd1fb90 : fltmgr!FltpPassThroughFastIo+0x4d fffff8800844aad0 fffff88006b5ed83 : fffffa8020a89300 fffffa8000000008 fffffa8020a89010 fffffa801dd1fb90 : fltmgr!FltpFastIoMdlReadComplete+0x11e fffff8800844ab50 fffff88006b39b42 : 0000000000000008 fffffa800a67b910 fffffa801dd1f8e0 fffff88006b65b66 : srv2!Smb2CleanupWorkItem+0x253 fffff8800844abd0 fffff88006b39ab6 : fffff88006b58110 000000001b7da8d4 fffffa8020a89010 0000000000000007 : srv2!SrvFreeWorkItem+0x72 fffff8800844ac50 fffff88006b5e16a : fffffa800dacd1a0 000000000000000e fffffa800dacd1a0 fffffa801dd1f8f0 : srv2!SrvDereferenceWorkItem+0x46 fffff8800844acc0 fffff800019167c6 : 700909090a0d202c fffffa804be706c0 0000000000000080 fffffa8009a225f0 : srv2!SrvProcWorkerThread+0x15a fffff8800844ad40 fffff80001651c26 : fffff800017ede80 fffffa804be706c0 fffff800017fbc40 2c6e6f6974706972 : nt!PspSystemThreadStartup+0x5a fffff8800844ad80 0000000000000000 : fffff8800844b000 fffff88008445000 fffff8800844a9c0 00000000`00000000 : nt!KiStartSystemThread+0x16

[Scott_Noone_OSR]

The buffer was corructed when we tried to free it, is there a way to find
out who corructed the pool from the memory dump?

Not likely. From the documentation of 0x19.0x22:

An address being freed does not have a tracking entry. This is usually
because the call stack is trying to free a pointer that either has already
been freed or was never allocated to begin with.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff557389(v=vs.85).aspx

So, possibly a structure that has been freed twice. Unfortunately what you
want to know is when the other free happened, which you likely won’t be able
to find from the dump.

Can you reproduce this locally with Driver Verifier enabled? If not, would
your customer allow you to enable Verifier? It might crash the system at a
more opportune time. Even if it doesn’t, you can at least hope that the free
will be in the alloc/free log (!verifier 80).

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Hi All,

I have a mini filter which implements the fast I/O and IRP
IRP_MJ_MDL_READ/IRP_MJ_MDL_READ_COMPLETE requests:

In IRP_MJ_MDL_READ I will allocate my own mdl and buffer with my data and
return back, and put the mdl and buffer to a table.

In IRP_MJ_MDL_READ_COMPLETE I will check the table with mdl to check if it
is my mdl, if yes, then I will free my mdl and free my buffer.

The filter was working for a few years, recently we got BSOD from the
customer environment almost once a month as the following dump,all we know
that the crashed computers were installed the McAfee virusScan enterprise
8.8 patches 2

The question is:
The buffer was corructed when we tried to free it, is there a way to find
out who corructed the pool from the memory dump?

Thanks in advance
Ben

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: 0000000000000022,
Arg2: fffff8a00276a000
Arg3: 0000000000000001
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0x19_22

POOL_ADDRESS: fffff8a00276a000

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800016c8c80 to fffff80001673740

STACK_TEXT:
fffff8800844a808 fffff800016c8c80 : 0000000000000019 0000000000000022
fffff8a00276a000 0000000000000001 : nt!KeBugCheckEx
fffff8800844a810 fffff800017a8518 : 0000000000000000 fffff8800844a960
fffff8800844a8d0 fffff80000000001 : nt! ?? ::FNODOBFM::string'+0x72f8 fffff8800844a8a0 fffff8800600acb8 : 000000000000002e 0000000000000000 0000000000000000 0000000000000001 : nt!ExFreePoolWithTag+0x468 fffff8800844a950 fffff88001549027 : 0000000000000000 fffffa800d95a260 fffffa800fc1da00 0000000000000000 : MiniFilter!FreeMdlRead+0x90 fffff8800844a990 fffff8800154bb9d : fffff78000000300 fffff88006b581f0 fffffa800dacd200 fffffa800a67b900 : fltmgr!FltpPerformPreCallbacks+0x2f7 fffff8800844aa90 fffff8800154bd7e : fffffa800a67b910 fffffa8034865cd0 fffffa8009d2f150 fffffa801dd1fb90 : fltmgr!FltpPassThroughFastIo+0x4d fffff8800844aad0 fffff88006b5ed83 : fffffa8020a89300 fffffa8000000008 fffffa8020a89010 fffffa801dd1fb90 : fltmgr!FltpFastIoMdlReadComplete+0x11e fffff8800844ab50 fffff88006b39b42 : 0000000000000008 fffffa800a67b910 fffffa801dd1f8e0 fffff88006b65b66 : srv2!Smb2CleanupWorkItem+0x253 fffff8800844abd0 fffff88006b39ab6 : fffff88006b58110 000000001b7da8d4 fffffa8020a89010 0000000000000007 : srv2!SrvFreeWorkItem+0x72 fffff8800844ac50 fffff88006b5e16a : fffffa800dacd1a0 000000000000000e fffffa800dacd1a0 fffffa801dd1f8f0 : srv2!SrvDereferenceWorkItem+0x46 fffff8800844acc0 fffff800019167c6 : 700909090a0d202c fffffa804be706c0 0000000000000080 fffffa8009a225f0 : srv2!SrvProcWorkerThread+0x15a fffff8800844ad40 fffff80001651c26 : fffff800017ede80 fffffa804be706c0 fffff800017fbc40 2c6e6f6974706972 : nt!PspSystemThreadStartup+0x5a fffff8800844ad80 0000000000000000 : fffff8800844b000 fffff88008445000 fffff8800844a9c0 00000000`00000000 : nt!KiStartSystemThread+0x16

[ben_tsang]

Thanks Scott,

Do I need to enable driver verifier for both McAfee and my driver? Or just my driver will be good enough to know the problem when it crashes again?

Thanks
Ben

[Scott_Noone_OSR]

Possibly, it ultimately depends on who is doing the freeing. I’d start by
enabling it on both and seeing where it gets me (this may of course uncover
unrelated issues).

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Thanks Scott,

Do I need to enable driver verifier for both McAfee and my driver? Or just
my driver will be good enough to know the problem when it crashes again?

Thanks
Ben

[ben_tsang]

Hi Scott,

I finally convinced my client to enable driver, after reboot, the system crashed right away, it was caused by the pcanywhere driver aw_host5.sys, it tried to free the memory where bytes after the end of the allocation have been overwritten. From the driver verifier pool allocation log, it tried to free the memory never allocated, how can it do that? without the driver verifier, it can work for a month and crash with different error.

kd> !analyze
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C1, {fffff98008406ff0, fffff98008406ff4, 8d0004, 24}

Page 20bb8d not present in the dump file. Type “.hh dbgerr004” for details
Probably caused by : aw_host5.sys ( aw_host5+1575 )

Followup: MachineOwner

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

SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
Special pool has detected memory corruption. Typically the current thread’s
stack backtrace will reveal the guilty party.
Arguments:
Arg1: fffff98008406ff0, address trying to free
Arg2: fffff98008406ff4, address where bits are corrupted
Arg3: 00000000008d0004, (reserved)
Arg4: 0000000000000024, caller is freeing an address where bytes after the end of the allocation have been overwritten

Debugging Details:

Page 20bb8d not present in the dump file. Type “.hh dbgerr004” for details

BUGCHECK_STR: 0xC1_24

SPECIAL_POOL_CORRUPTION_TYPE: 24

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: awhost32.exe

CURRENT_IRQL: 1

IRP_ADDRESS: fffff98004bdcf3b

LAST_CONTROL_TRANSFER: from fffff80001bd0c74 to fffff80001ac8c40

STACK_TEXT:
fffff88006a704c8 fffff80001bd0c74 : 00000000000000c1 fffff98008406ff0 fffff98008406ff4 00000000008d0004 : nt!KeBugCheckEx
fffff88006a704d0 fffff80001bfc93b : fffff80001a53000 0000000020206f49 000000000000937c fffffa800933f950 : nt!MmFreeSpecialPool+0x374
fffff88006a70610 fffff80001add63e : 0000000000000000 fffff98004bdcfb0 fffff98004bdcee0 fffff98004bdcfb0 : nt!ExDeferredFreePool+0xf33
fffff88006a706c0 fffff80001acc9fa : fffff98004bdcfb3 0000000000000001 0000000000000001 fffff80001b8b923 : nt!IopCompleteRequest+0x5ce
fffff88006a70790 fffff80001f6d19f : fffff98004bdcee0 0000000000000000 fffff98004bdce00 0000000000000000 : nt!IopfCompleteRequest+0x66a
fffff88006a70880 fffff8800322d575 : fffff80000000001 fffffa80093222d0 0000000000000000 fffff98004bdcee0 : nt!IovCompleteRequest+0x19f
fffff88006a70950 fffff80001f73c16 : 00000000046b0000 fffff98004bdcee0 fffff98004bdcee0 fffffa8007b74bd0 : aw_host5+0x1575
fffff88006a709b0 fffff80001de7b57 : fffffa800933f950 fffff88006a70ca0 fffffa800933f950 fffffa80093222d0 : nt!IovCallDriver+0x566
fffff88006a70a10 fffff80001de83b6 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 : nt!IopXxxControlFile+0x607
fffff88006a70b40 fffff80001ac7ed3 : fffffa800809fb30 0000000000000001 fffffa8009336a50 fffff80001dc3734 : nt!NtDeviceIoControlFile+0x56
fffff88006a70bb0 0000000074812e09 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000442f0f8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x74812e09

STACK_COMMAND: kb

FOLLOWUP_IP:
aw_host5+1575
fffff880`0322d575 8bc3 mov eax,ebx

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: aw_host5+1575

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: aw_host5

IMAGE_NAME: aw_host5.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d97d75

FAILURE_BUCKET_ID: X64_0xC1_24_VRF_aw_host5+1575

BUCKET_ID: X64_0xC1_24_VRF_aw_host5+1575

Followup: MachineOwner

0: kd> !verifier 0x80 fffff98008406ff0

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 0xfffff98008406ff0.

======================================================================
Pool block fffff98008406ff0, Size 0000000000000010, Thread fffffa8009336a50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001add63e nt!IopCompleteRequest+0x5ce
fffff80001acc9fa nt!IopfCompleteRequest+0x66a
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff8800322d575 aw_host5+0x1575
fffff80001f73c16 nt!IovCallDriver+0x566
fffff80001de7b57 nt!IopXxxControlFile+0x607
fffff80001de83b6 nt!NtDeviceIoControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001dd4e57 nt!IopSynchronousServiceTail+0x147
fffff80001db5d43 nt!NtReadFile+0x631
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001db5c46 nt!NtReadFile+0x534
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa800931c8b0
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dd462a nt!IopCloseFile+0x14a
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa800931c8b0
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dd458b nt!IopCloseFile+0xab
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001acc9fa nt!IopfCompleteRequest+0x66a
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff8800143ae84 Ntfs+0xfe84
fffff880014ba7f5 Ntfs+0x8f7f5
fffff880014b8346 Ntfs+0x8d346
fffff880014b8b14 Ntfs+0x8db14
fffff80001f73c16 nt!IovCallDriver+0x566
fffff88000db3bcf fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001d79b0f nt!IopGetFileInformation+0x4f
fffff80001daafd7 nt!IopQueryNameInternal+0x19f
fffff80001dab5c6 nt!IopQueryName+0x26
fffff80001da32a0 nt!ObpQueryNameString+0xb0
fffff80001d6d183 nt!SePopulateProcessImageName+0xa3
fffff80001d6d060 nt!SeLocateProcessImageName+0x28
fffff80001b42c67 nt! ?? ::FNODOBFM::`string’+0x404a3
fffff80001db90ca nt!PspInsertThread+0x61a

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dd462a nt!IopCloseFile+0x14a
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dd458b nt!IopCloseFile+0xab
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009316b50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009316b50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009310ab0
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009310ab0
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000120, Thread fffffa80091b1870
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001de81b4 nt!IopXxxControlFile+0xc61
fffff80001da5892 nt!NtFsControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000118, Thread fffffa80091b1870
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001de7916 nt!IopXxxControlFile+0x3c6
fffff80001da5892 nt!NtFsControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000120, Thread fffffa80091b1870
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add472 nt!IopCompleteRequest+0x402
fffff80001a97cbd nt!IopPostProcessIrp+0x4d
fffff80001db48c7 nt!IoRemoveIoCompletion+0xe7
fffff80001ab3e46 nt!NtWaitForWorkViaWorkerFactory+0x285
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000118, Thread fffffa8009198b50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001db5c46 nt!NtReadFile+0x534
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001acc7e4 nt!IopfCompleteRequest+0x454
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff880014373ea Ntfs+0xc3ea
fffff88001437a68 Ntfs+0xca68
fffff80001f73c16 nt!IovCallDriver+0x566
fffff88000db3bcf fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88000db26df fltmgr!FltpDispatch+0xcf
fffff80001f73c16 nt!IovCallDriver+0x566
fffff80001aeff05 nt!IoPageRead+0x255

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001aefd33 nt!IoPageRead+0x83
fffff80001aef9d9 nt!MiIssueHardFault+0x255
fffff80001ad637a nt!MmAccessFault+0x146a
fffff80001ac6d6e nt!KiPageFault+0x16e

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80069f8040
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001b0cd58 nt!CcDeleteSharedCacheMap+0x224
fffff80001b0d57e nt!CcWriteBehind+0x54e
fffff80001b0dbb8 nt!CcWorkerThread+0x1c8
fffff80001ad1ca9 nt!ExpWorkerThread+0x111
fffff80001d6934a nt!PspSystemThreadStartup+0x5a
fffff80001ab9946 nt!KiStartSystemThread+0x16

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80069f8040
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001b0cd58 nt!CcDeleteSharedCacheMap+0x224
fffff80001b0d57e nt!CcWriteBehind+0x54e
fffff80001b0dbb8 nt!CcWorkerThread+0x1c8
fffff80001ad1ca9 nt!ExpWorkerThread+0x111
fffff80001d6934a nt!PspSystemThreadStartup+0x5a

Finished parsing all pool tracking information.

[Scott_Noone_OSR]

the system crashed right away, it was caused by the pcanywhere driver
aw_host5.sys, it tried to free the memory where bytes after the end of the
allocation have been overwritten

Excellent! Much better than waiting a month

You need to figure out where this buffer came from so you can try to narrow
down whose fault it is. Based on the stack, it looks like the SystemBuffer
field of the IRP might be the issue. Maybe they copied more bytes than were
specified as the OutputBufferSize? Digging out the IRP from the stack should
tell you.

From the driver verifier pool allocation log, it tried to free the memory
never allocated, how can it do that?

I wouldn’t get too caught up in that part of it. I suspect that it’s just a
Verifier artifact of some sort. What version of the O/S is this and which
drivers did you enable Verifier on?

without the driver verifier, it can work for a month and crash with
different error.

This is a data corruption, which means it can go unnoticed for quite some
time before the system crashes.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Hi Scott,

I finally convinced my client to enable driver, after reboot, the system
crashed right away, it was caused by the pcanywhere driver aw_host5.sys, it
tried to free the memory where bytes after the end of the allocation have
been overwritten. From the driver verifier pool allocation log, it tried to
free the memory never allocated, how can it do that? without the driver
verifier, it can work for a month and crash with different error.

kd> !analyze
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C1, {fffff98008406ff0, fffff98008406ff4, 8d0004, 24}

Page 20bb8d not present in the dump file. Type “.hh dbgerr004” for details
Probably caused by : aw_host5.sys ( aw_host5+1575 )

Followup: MachineOwner

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

SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
Special pool has detected memory corruption. Typically the current thread’s
stack backtrace will reveal the guilty party.
Arguments:
Arg1: fffff98008406ff0, address trying to free
Arg2: fffff98008406ff4, address where bits are corrupted
Arg3: 00000000008d0004, (reserved)
Arg4: 0000000000000024, caller is freeing an address where bytes after the
end of the allocation have been overwritten

Debugging Details:

Page 20bb8d not present in the dump file. Type “.hh dbgerr004” for details

BUGCHECK_STR: 0xC1_24

SPECIAL_POOL_CORRUPTION_TYPE: 24

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: awhost32.exe

CURRENT_IRQL: 1

IRP_ADDRESS: fffff98004bdcf3b

LAST_CONTROL_TRANSFER: from fffff80001bd0c74 to fffff80001ac8c40

STACK_TEXT:
fffff88006a704c8 fffff80001bd0c74 : 00000000000000c1 fffff98008406ff0
fffff98008406ff4 00000000008d0004 : nt!KeBugCheckEx
fffff88006a704d0 fffff80001bfc93b : fffff80001a53000 0000000020206f49
000000000000937c fffffa800933f950 : nt!MmFreeSpecialPool+0x374
fffff88006a70610 fffff80001add63e : 0000000000000000 fffff98004bdcfb0
fffff98004bdcee0 fffff98004bdcfb0 : nt!ExDeferredFreePool+0xf33
fffff88006a706c0 fffff80001acc9fa : fffff98004bdcfb3 0000000000000001
0000000000000001 fffff80001b8b923 : nt!IopCompleteRequest+0x5ce
fffff88006a70790 fffff80001f6d19f : fffff98004bdcee0 0000000000000000
fffff98004bdce00 0000000000000000 : nt!IopfCompleteRequest+0x66a
fffff88006a70880 fffff8800322d575 : fffff80000000001 fffffa80093222d0
0000000000000000 fffff98004bdcee0 : nt!IovCompleteRequest+0x19f
fffff88006a70950 fffff80001f73c16 : 00000000046b0000 fffff98004bdcee0
fffff98004bdcee0 fffffa8007b74bd0 : aw_host5+0x1575
fffff88006a709b0 fffff80001de7b57 : fffffa800933f950 fffff88006a70ca0
fffffa800933f950 fffffa80093222d0 : nt!IovCallDriver+0x566
fffff88006a70a10 fffff80001de83b6 : 0000000000000000 0000000000000000
0000000000000001 0000000000000000 : nt!IopXxxControlFile+0x607
fffff88006a70b40 fffff80001ac7ed3 : fffffa800809fb30 0000000000000001
fffffa8009336a50 fffff80001dc3734 : nt!NtDeviceIoControlFile+0x56
fffff88006a70bb0 0000000074812e09 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000442f0f8 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x74812e09

STACK_COMMAND: kb

FOLLOWUP_IP:
aw_host5+1575
fffff880`0322d575 8bc3 mov eax,ebx

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: aw_host5+1575

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: aw_host5

IMAGE_NAME: aw_host5.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d97d75

FAILURE_BUCKET_ID: X64_0xC1_24_VRF_aw_host5+1575

BUCKET_ID: X64_0xC1_24_VRF_aw_host5+1575

Followup: MachineOwner

0: kd> !verifier 0x80 fffff98008406ff0

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
0xfffff98008406ff0.

======================================================================
Pool block fffff98008406ff0, Size 0000000000000010, Thread fffffa8009336a50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001add63e nt!IopCompleteRequest+0x5ce
fffff80001acc9fa nt!IopfCompleteRequest+0x66a
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff8800322d575 aw_host5+0x1575
fffff80001f73c16 nt!IovCallDriver+0x566
fffff80001de7b57 nt!IopXxxControlFile+0x607
fffff80001de83b6 nt!NtDeviceIoControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001dd4e57 nt!IopSynchronousServiceTail+0x147
fffff80001db5d43 nt!NtReadFile+0x631
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001db5c46 nt!NtReadFile+0x534
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa800931c8b0
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dd462a nt!IopCloseFile+0x14a
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa800931c8b0
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dd458b nt!IopCloseFile+0xab
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001acc9fa nt!IopfCompleteRequest+0x66a
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff8800143ae84 Ntfs+0xfe84
fffff880014ba7f5 Ntfs+0x8f7f5
fffff880014b8346 Ntfs+0x8d346
fffff880014b8b14 Ntfs+0x8db14
fffff80001f73c16 nt!IovCallDriver+0x566
fffff88000db3bcf fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001d79b0f nt!IopGetFileInformation+0x4f
fffff80001daafd7 nt!IopQueryNameInternal+0x19f
fffff80001dab5c6 nt!IopQueryName+0x26
fffff80001da32a0 nt!ObpQueryNameString+0xb0
fffff80001d6d183 nt!SePopulateProcessImageName+0xa3
fffff80001d6d060 nt!SeLocateProcessImageName+0x28
fffff80001b42c67 nt! ?? ::FNODOBFM::`string’+0x404a3
fffff80001db90ca nt!PspInsertThread+0x61a

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dd462a nt!IopCloseFile+0x14a
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b1060
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dd458b nt!IopCloseFile+0xab
fffff80001dcba0a nt!IopParseDevice+0x1de1
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001da6f36 nt!NtQueryAttributesFile+0x145
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009316b50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dcb398 nt!IopParseDevice+0x176f
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009316b50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001dcaa0f nt!IopParseDevice+0xde6
fffff80001dc6a78 nt!ObpLookupObjectName+0x588
fffff80001dc7c96 nt!ObOpenObjectByName+0x306
fffff80001dc959c nt!IopCreateFile+0x2bc
fffff80001dd4b64 nt!NtCreateFile+0x78
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009310ab0
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8009310ab0
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa8008f6bb50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001dc3184 nt!ObpCloseHandleTableEntry+0xc4
fffff80001dc3734 nt!ObpCloseHandle+0x94
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000120, Thread fffffa80091b1870
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add5bc nt!IopCompleteRequest+0x54c
fffff80001de81b4 nt!IopXxxControlFile+0xc61
fffff80001da5892 nt!NtFsControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000118, Thread fffffa80091b1870
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001de7916 nt!IopXxxControlFile+0x3c6
fffff80001da5892 nt!NtFsControlFile+0x56
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000120, Thread fffffa80091b1870
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001add472 nt!IopCompleteRequest+0x402
fffff80001a97cbd nt!IopPostProcessIrp+0x4d
fffff80001db48c7 nt!IoRemoveIoCompletion+0xe7
fffff80001ab3e46 nt!NtWaitForWorkViaWorkerFactory+0x285
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406ee0, Size 0000000000000118, Thread fffffa8009198b50
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001db5c46 nt!NtReadFile+0x534
fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001acc7e4 nt!IopfCompleteRequest+0x454
fffff80001f6d19f nt!IovCompleteRequest+0x19f
fffff880014373ea Ntfs+0xc3ea
fffff88001437a68 Ntfs+0xca68
fffff80001f73c16 nt!IovCallDriver+0x566
fffff88000db3bcf fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88000db26df fltmgr!FltpDispatch+0xcf
fffff80001f73c16 nt!IovCallDriver+0x566
fffff80001aeff05 nt!IoPageRead+0x255

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80080b2640
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001aefd33 nt!IoPageRead+0x83
fffff80001aef9d9 nt!MiIssueHardFault+0x255
fffff80001ad637a nt!MmAccessFault+0x146a
fffff80001ac6d6e nt!KiPageFault+0x16e

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80069f8040
fffff80001f6893a nt!VfFreePoolNotification+0x4a
fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
fffff80001f72026 nt!VfIoFreeIrp+0xe6
fffff80001f725ec nt!IovFreeIrpPrivate+0x5c
fffff80001dc85fe nt!IopDeleteFile+0x14e
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001b0cd58 nt!CcDeleteSharedCacheMap+0x224
fffff80001b0d57e nt!CcWriteBehind+0x54e
fffff80001b0dbb8 nt!CcWorkerThread+0x1c8
fffff80001ad1ca9 nt!ExpWorkerThread+0x111
fffff80001d6934a nt!PspSystemThreadStartup+0x5a
fffff80001ab9946 nt!KiStartSystemThread+0x16

Pool block fffff98008406cf0, Size 0000000000000310, Thread fffffa80069f8040
fffff80001f68cc6 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001f68dd0 nt!ViIrpAllocate+0x40
fffff80001f723a8 nt!ViIrpAllocateLockedPacket+0x28
fffff80001f724c3 nt!VfIoAllocateIrp1+0x23
fffff80001f72a92 nt!IovAllocateIrp+0x52
fffff80001adcdb6 nt!IopAllocateIrpMustSucceed+0x16
fffff80001dc852c nt!IopDeleteFile+0x7c
fffff80001ad2174 nt!ObfDereferenceObject+0xd4
fffff80001b0cd58 nt!CcDeleteSharedCacheMap+0x224
fffff80001b0d57e nt!CcWriteBehind+0x54e
fffff80001b0dbb8 nt!CcWorkerThread+0x1c8
fffff80001ad1ca9 nt!ExpWorkerThread+0x111
fffff80001d6934a nt!PspSystemThreadStartup+0x5a

Finished parsing all pool tracking information.

[ben_tsang]

Thanks Scott,

From the dump file, do you know what command I can figure out the buffer came from? Also I don’t know how to dig out he IRP from the stack trace, is there a way to do that?

My OS is windows 2008 R2, the driver verifier is enabled for my own driver.

Ben

[Scott_Noone_OSR]

What’s the output of !thread? The IRP might still be queued to thread at this point.

-scott
OSR

[ben_tsang]

Thanks scott,

here is the output:

0: kd> !thread
THREAD fffffa8009336a50 Cid 056c.0608 Teb: 000000007ef92000 Win32Thread: 0000000000000000 RUNNING on processor 0
IRP List:
fffff98004bdcee0: (0006,0118) Flags: 40060070 Mdl: 00000000
Not impersonating
DeviceMap fffff8a000007dc0
Owning Process fffffa800809fb30 Image: awhost32.exe
Attached Process N/A Image: N/A
Wait Start TickCount 4492 Ticks: 0
Context Switch Count 7 IdealProcessor: 2
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x00000000743229e1
Stack Init fffff88006a70db0 Current fffff88006a6fe00
Base fffff88006a71000 Limit fffff88006a6b000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff88006a704c8 fffff80001bd0c74 : 00000000000000c1 fffff98008406ff0 fffff98008406ff4 00000000008d0004 : nt!KeBugCheckEx
fffff88006a704d0 fffff80001bfc93b : fffff80001a53000 0000000020206f49 000000000000937c fffffa800933f950 : nt!MmFreeSpecialPool+0x374
fffff88006a70610 fffff80001add63e : 0000000000000000 fffff98004bdcfb0 fffff98004bdcee0 fffff98004bdcfb0 : nt!ExDeferredFreePool+0xf33
fffff88006a706c0 fffff80001acc9fa : fffff98004bdcfb3 0000000000000001 0000000000000001 fffff80001b8b923 : nt!IopCompleteRequest+0x5ce
fffff88006a70790 fffff80001f6d19f : fffff98004bdcee0 0000000000000000 fffff98004bdce00 0000000000000000 : nt!IopfCompleteRequest+0x66a
fffff88006a70880 fffff8800322d575 : fffff80000000001 fffffa80093222d0 0000000000000000 fffff98004bdcee0 : nt!IovCompleteRequest+0x19f
fffff88006a70950 fffff80001f73c16 : 00000000046b0000 fffff98004bdcee0 fffff98004bdcee0 fffffa8007b74bd0 : aw_host5+0x1575
fffff88006a709b0 fffff80001de7b57 : fffffa800933f950 fffff88006a70ca0 fffffa800933f950 fffffa80093222d0 : nt!IovCallDriver+0x566
fffff88006a70a10 fffff80001de83b6 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 : nt!IopXxxControlFile+0x607
fffff88006a70b40 fffff80001ac7ed3 : fffffa800809fb30 0000000000000001 fffffa8009336a50 fffff80001dc3734 : nt!NtDeviceIoControlFile+0x56
fffff88006a70bb0 0000000074812e09 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff88006a70c20) 000000000442f0f8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x74812e09

!IRP fffff98004bdcee0 1
Irp is active with 1 stacks 3 is current (= 0xfffff98004bdd040)
No Mdl: System buffer=fffff98008406ff0: Thread fffffa8009336a50: Irp is completed.
Flags = 40060070
ThreadListEntry.Flink = fffffa8009336e40
ThreadListEntry.Blink = fffffa8009336e40
IoStatus.Status = 00000000
IoStatus.Information = 00000008
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 0452eec4
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 01f03c58
&Tail.Overlay.DeviceQueueEntry = fffff98004bdcf58
Tail.Overlay.Thread = fffffa8009336a50
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffff98004bdd040
Tail.Overlay.OriginalFileObject = fffffa800933f950
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[e, 0] 0 10 fffffa8007b74bd0 00000000 00000000-00000000
\Driver\AW_HOST
Args: 00000000 00000000 00000000 00000000

0: kd>dd fffff98008406ff0
fffff98008406ff0 046b0000 00000000 8d8d8d8d 8d8d8d8d fffff98008407000 ??? ??? ??? ???
fffff98008407010 ???????? ???????? ???????? ???????? fffff98008407020 ??? ??? ??? ???
fffff98008407030 ???????? ???????? ???????? ???????? fffff98008407040 ??? ??? ??? ???
fffff98008407050 ???????? ???????? ???????? ???????? fffff98008407060 ??? ??? ??? ???

[Scott_Noone_OSR]

It is definitely the system buffer associated with the IRP. The information field is 8, so they’re trying to copy 8 bytes back to the user. Can you dump out the parameters from the current stack location and get the output buffer length? That should tell you if they’re over copying.

-scott
OSR

[ben_tsang]

Thanks scott,

I have a few questions:

1. for the stack trace, it is deviceIoControl IRP, it tried to free the memory, why it needs to free the memory?
   fffff80001f6893a nt!VfFreePoolNotification+0x4a
   fffff80001bfc7fa nt!ExDeferredFreePool+0xdc1
   fffff80001add63e nt!IopCompleteRequest+0x5ce
   fffff80001acc9fa nt!IopfCompleteRequest+0x66a
   fffff80001f6d19f nt!IovCompleteRequest+0x19f
   fffff8800322d575 aw_host5+0x1575
   fffff80001f73c16 nt!IovCallDriver+0x566
   fffff80001de7b57 nt!IopXxxControlFile+0x607
   fffff80001de83b6 nt!NtDeviceIoControlFile+0x56
   fffff80001ac7ed3 nt!KiSystemServiceCopyEnd+0x13

2. If someone tries to read the memory more than it allocated, it will corrupt the memory it read? I thought only write will corrupt the memory.

3. I tried to dump out the parameters from the current stack to get the output buffer length, the stack only shows 4 arguments, which one is the output buffer length? is fffffa80`09336a50 is the buffer length parameter? it’s value is 6.

Child-SP RetAddr : Args to Child
fffff88006a70b40 fffff80001ac7ed3 : fffffa800809fb30 0000000000000001 fffffa8009336a50 fffff80001dc3734 : nt!NtDeviceIoControlFile+0x56

0: kd> dd fffffa800809fb30 fffffa800809fb30 00580003 00000000 091803a0 fffffa80
fffffa800809fb40 091803a0 fffffa80 0809fb48 fffffa80 fffffa800809fb50 0809fb48 fffffa80 e6298000 00000001
fffffa800809fb60 0809d858 fffffa80 09103358 fffffa80 fffffa800809fb70 00000000 00000000 00040001 fffff800
fffffa800809fb80 0000000f 00000000 00000000 00000000 fffffa800809fb90 00000000 00000000 00000000 00000000
fffffa800809fba0 0809fba0 fffffa80 0809fba0 fffffa80 0: kd\> dd fffffa8009336a50
fffffa8009336a50 00000006 00000000 09336a58 fffffa80 fffffa8009336a60 09336a58 fffffa80 00412a5f 00000000
fffffa8009336a70 17c52ea0 00000000 06a70db0 fffff880 fffffa8009336a80 06a6b000 fffff880 06a6fe00 fffff880
fffffa8009336a90 00000000 00000000 00000101 00000001 fffffa8009336aa0 09336aa0 fffffa80 09336aa0 fffffa80
fffffa8009336ab0 09336ab0 fffffa80 09336ab0 fffffa80 fffffa8009336ac0 0809fb30 fffffa80 09000000 00000000
0: kd> dd fffff80001dc3734 fffff80001dc3734 245c8b48 6c8b4850 8b485824 48602474
fffff80001dc3744 4130c483 5f5c415d b58b48c3 00000200 fffff80001dc3754 45353b48 0fffeb68 fbf7e784 ed8b4cff
fffff80001dc3764 909098eb 90909090 90909090 28ec8348 fffff80001dc3774 03fcc2f7 7c740000 245c8948 74894830
fffff80001dc3784 89483824 4820247c 8b48fa8b f8cae8f1 fffff80001dc3794 8548ffff 483c74c0 0d0fd88b 038b480b
fffff800`01dc37a4 267401a8 ff488d48 b10f48f0 d7850f0b

[OSR_Community_User]

> 1. for the stack trace, it is deviceIoControl IRP, it tried to free the memory, why it needs to free the

memory?

To free the .SystemBuffer I think.

2. If someone tries to read the memory more than it allocated, it will corrupt the memory it read?

If the virtual address is valid - then this will not cause any adverse effects.

But, if it is invalid (not mapped by PTEs) - then you will crash.

3. I tried to dump out the parameters from the current stack to get the output buffer length, the stack
   only shows 4 arguments

!irp is a good thing for such dumps.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

[ben_tsang]

Thanks Maxim,

Another few questions:

1. My original issue is the BSOD caused by freeing the corrupted memory, so the read memory passed over the allocated ranged, it won’t generate the following BSOD?

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.

2. I already had Irp output, could you explain a bit detail to dump the parameters?

!IRP fffff98004bdcee0 1
Irp is active with 1 stacks 3 is current (= 0xfffff98004bdd040)
No Mdl: System buffer=fffff98008406ff0: Thread fffffa8009336a50: Irp is
completed.
Flags = 40060070
ThreadListEntry.Flink = fffffa8009336e40
ThreadListEntry.Blink = fffffa8009336e40
IoStatus.Status = 00000000
IoStatus.Information = 00000008
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 0452eec4
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 01f03c58
&Tail.Overlay.DeviceQueueEntry = fffff98004bdcf58
Tail.Overlay.Thread = fffffa8009336a50
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffff98004bdd040
Tail.Overlay.OriginalFileObject = fffffa800933f950
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[e, 0] 0 10 fffffa8007b74bd0 00000000 00000000-00000000
\Driver\AW_HOST
Args: 00000000 00000000 00000000 00000000

[OSR_Community_User]

Use Verifier’s Special Pool to catch the place where you’re introducing corruption.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Thanks Maxim,
>
> Another few questions:
>
> 1. My original issue is the BSOD caused by freeing the corrupted memory, so the read memory passed over the allocated ranged, it won’t generate the following BSOD?
>
> 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.
>
> 2. I already had Irp output, could you explain a bit detail to dump the parameters?
>
> !IRP fffff98004bdcee0 1
> Irp is active with 1 stacks 3 is current (= 0xfffff98004bdd040)
> No Mdl: System buffer=fffff98008406ff0: Thread fffffa8009336a50: Irp is
> completed.
> Flags = 40060070
> ThreadListEntry.Flink = fffffa8009336e40
> ThreadListEntry.Blink = fffffa8009336e40
> IoStatus.Status = 00000000
> IoStatus.Information = 00000008
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 0452eec4
> UserEvent = 00000000
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 00000000
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 01f03c58
> &Tail.Overlay.DeviceQueueEntry = fffff98004bdcf58
> Tail.Overlay.Thread = fffffa8009336a50
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 00000000
> Tail.Overlay.ListEntry.Blink = 00000000
> Tail.Overlay.CurrentStackLocation = fffff98004bdd040
> Tail.Overlay.OriginalFileObject = fffffa800933f950
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [e, 0] 0 10 fffffa8007b74bd0 00000000 00000000-00000000
> \Driver\AW_HOST
> Args: 00000000 00000000 00000000 00000000
>

[ben_tsang]

Thanks Maxim,

That’s what I did, I enabled the driver verifier, I got the BSOD and tried to analized the output as scott said to dump the parameters to get the system buffer length.

But I don’t know how to get the system buffer length from the current stack.

[Pavel_Lebedinsky]

Did you enable verifier without rebooting the system? Normally when verifier is enabled, deferred pool frees (ExDeferredFreePool) should be disabled.

Try enabling verifier for all drivers (verifier.exe /standard /all) and rebooting. This should get you closer to the source of the corruption.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, December 29, 2013 5:11 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] IRP IRP_MJ_MDL_READ/IRP_MJ_MDL_READ_COMPLETE BSOD

Thanks Maxim,

That’s what I did, I enabled the driver verifier, I got the BSOD and tried to analized the output as scott said to dump the parameters to get the system buffer length.

But I don’t know how to get the system buffer length from the current stack.

---

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

[Scott_Noone_OSR]

The current stack location is at fffff98004bdd040 and the data type is IO_STACK_LOCATION. Output buffer length is at Parameters.DeviceIoControl.OutputBufferLength.

-scott
OSR

[OSR_Community_User]

> Thanks Maxim,

Another few questions:

1. My original issue is the BSOD caused by freeing the corrupted memory,
   so the read memory passed over the allocated ranged, it won’t generate the
   following BSOD?

I cannot locate the original message, but the message you are getting for
the BSOD simply states that the heap has been damaged. Note carefully
that it says “may not be due to the caller”. You can do something that
causes someone else to malfunction and damage the heap (that is, the bug
is still in your code) or you could have damaged the memory twenty minutes
ago and it is just now being detected. It does NOT mean the current IRP
caused the damage; only that there WAS damage and it is just now being
detected. While the most likely cause is the current IRP, it is not the
ONLY cause; I have seen students cause memory damage that was not detected
for a good five minutes (that’s a geological epoch in computer years).
Essentially, you have to suspect EVERY action in your driver from the time
DriverEntry was called. Note that, as I said, the MOST LIKELY cause is
the most recent IRP, but you could bash your head against the wall for
weeks because the real IRP culprit was twenty or fifty IRPs in the past.

All the message says is that there was damage. And the damage was just
now discovered.

Enabling special pool for your driver will increase the likelihood that,
if it is your driver causing the damage, you will find it more quickly.

I use the analogy that someone removed a manhole cover on the sidewalk,
perhaps years ago, and nobody noticed until you were texting, not paying
attention to where you were walking, and you fell in. It is not your
fault you fell into the hole. The problem is to now find out who removed
the manhole cover. Converting computer years to human years, it could
have been in the time of your great^N-grandfather’s lifetime, for fairly
large N (N > 3, for example).
joe

joe

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.

2. I already had Irp output, could you explain a bit detail to dump the
   parameters?

!IRP fffff98004bdcee0 1
Irp is active with 1 stacks 3 is current (= 0xfffff98004bdd040)
No Mdl: System buffer=fffff98008406ff0: Thread fffffa8009336a50: Irp is
completed.
Flags = 40060070
ThreadListEntry.Flink = fffffa8009336e40
ThreadListEntry.Blink = fffffa8009336e40
IoStatus.Status = 00000000
IoStatus.Information = 00000008
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 0452eec4
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 01f03c58
&Tail.Overlay.DeviceQueueEntry = fffff98004bdcf58
Tail.Overlay.Thread = fffffa8009336a50
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffff98004bdd040
Tail.Overlay.OriginalFileObject = fffffa800933f950
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[e, 0] 0 10 fffffa8007b74bd0 00000000 00000000-00000000
\Driver\AW_HOST
Args: 00000000 00000000 00000000 00000000

---

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

[ben_tsang]

Hi Scott,

I tried to dump the current stack with following command, seems the address not good.

0: kd> dt _IO_STACK_LOCATION fffff98004bdd040
nt!_IO_STACK_LOCATION
+0x000 MajorFunction : ??
+0x001 MinorFunction : ??
+0x002 Flags : ??
+0x003 Control : ??
+0x008 Parameters :
+0x028 DeviceObject : ???
+0x030 FileObject : ???
+0x038 CompletionRoutine : ???
+0x040 Context : ???
Memory read error fffff98004bdd080

I also want to know if it read pass over the system buffer length, it will corrupt the memory?

Thanks
Ben

[Scott_Noone_OSR]

That makes sense, the IRP is complete at this point so the current I/O stack
is no longer valid. You’ll need to figure out the parameters from the
execution stack of the caller. If you can put this dump someplace that I can
look at it I can try.

I also want to know if it read pass over the system buffer length, it will
corrupt the memory?

No.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Hi Scott,

I tried to dump the current stack with following command, seems the address
not good.

0: kd> dt _IO_STACK_LOCATION fffff98004bdd040
nt!_IO_STACK_LOCATION
+0x000 MajorFunction : ??
+0x001 MinorFunction : ??
+0x002 Flags : ??
+0x003 Control : ??
+0x008 Parameters :
+0x028 DeviceObject : ???
+0x030 FileObject : ???
+0x038 CompletionRoutine : ???
+0x040 Context : ???
Memory read error fffff98004bdd080

I also want to know if it read pass over the system buffer length, it will
corrupt the memory?

Thanks
Ben