SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

NTDEV
1

I am hitting a bug check which indicates
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION.

I can reproduce it by disabling/enabling the driver
with the special pool flag set in static verfier.

Although it is happening only on 64-bit system I don’t
think it is related to the platform.

Under what circumstances would this happen?
What is special memory pool?

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: fffffabec6d62f90, address trying to free

Arg2: fffffabec6d62ff8, address where bits are
corrupted

Arg3: 00000000007f4068, (reserved)

Arg4: 0000000000000024, caller is freeing an address
where bytes after the end of the allocation have been
overwritten

Debugging Details:

*** Error in in reading nt!_ETHREAD @ 0000000000000000

*** Error in in reading nt!_ETHREAD @ 0000000000000000

BUGCHECK_STR: 0xC1_24

SPECIAL_POOL_CORRUPTION_TYPE: 24

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 2

LOCK_ADDRESS: fffff800011b5ae0 – (!locks
fffff800011b5ae0)

Resource @ nt!IopDeviceTreeLock (0xfffff800011b5ae0)
Shared 1 owning threads

Contention Count = 1

Threads: fffffadfe7952760-01<*>

1 total locks, 1 locks currently held

PNP_TRIAGE:

Lock address : 0xfffff800011b5ae0

Thread Count : 1

Thread address: 0xfffffadfe7952760

Thread wait : 0xf85a

LAST_CONTROL_TRANSFER: from fffff800010c8ede to
fffff8000104b350

STACK_TEXT:

fffffadfe4a70b48 fffff800010c8ede :
fffffabec6d62f90 0000000000000000 00000000000000c1 fffff8000106144e : nt!RtlpBreakWithStatusInstruction

fffffadfe4a70b50 fffff800010ca4c4 :
fffff80000000003 00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 : nt!KiBugCheckDebugBreak+0x1e

fffffadfe4a70bb0 fffff800010502d4 :
fffffadfe4a71260 fffffadfe4a71258 fffffadfe4a72000 fffff800013d2f48 : nt!KeBugCheck2+0x676

fffffadfe4a71200 fffff800013e6d74 :
00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 00000000007f4068 : nt!KeBugCheckEx+0x104

fffffadfe4a71240 fffff80001184292 :
fffffabec6d62f90 fffffabec5a70d30 0000000000000001 fffffadfe79cd2e0 : nt!MmFreeSpecialPool+0x334

fffffadfe4a712c0 fffffadfe1e82502 :
fffffabec6d1aff0 fffffabec6d64de0 fffffadfe66598a0 fffffabec5a70d30 : nt!ExFreePoolWithTag+0x15c

fffffadfe4a71380 fffffadfe1eab2ac :
fffffabec6d62f90 0000000000000284 fffffadfe4a713d8 0000000000000018 : mydriver!operator delete+0x42
[c:\projects\mydriver\software\source\capture\cp.h @
85]

fffffadfe4a713b0 fffffadfe1e86191 :
fffffabec6d62f90 fffffadf00000001 0000000000000000 0000000000000000 : mydriver!GenTunerDemod::`scalar
deleting destructor’+0x2c

fffffadfe4a713e0 fffffadfe1e845af :
fffffabec5cd6e60 fffffadfe698aae0 fffffa80004a7fd0 fffffadfe669e140 : mydriver!Device::unInit+0x4f1
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 1685]

fffffadfe4a716d0 fffffadfe1e676ee :
fffffadfe6a197f0 fffffabec5a70d30 fffffadfe69e7320 fffffadfe6a19730 :
mydriver!Device::dispatchPnpStop+0x1f
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 922]

fffffadfe4a71700 fffffadfe1e5f2f5 :
fffffadfe66598a0 fffffadfe4a717d0 fffffadfe6a19730 fffffabec5a70d30 : ks!CKsDevice::PnpStop+0xaf

fffffadfe4a71760 fffff800013c6255 :
fffffadfe66598a0 fffffadfe4a717d0 fffffabec5a70d30 fffffadfe6b56bf0 : ks!CKsDevice::DispatchPnp+0xf0

fffffadfe4a717a0 fffffadfe4c2b814 :
fffffadfe6b15900 fffffabec5a70d30 0000000000000000 fffffabec5a70d30 : nt!IovCallDriver+0x1b5

fffffadfe4a71810 fffff800013c6255 :
fffffadfe6afde90 fffffadfe4a718a0 fffffabec5a70d30 fffffadfe6a7cbf0 :
ksthunk!CKernelFilterDevice::DispatchIrp+0x294

fffffadfe4a71870 fffff80001226573 :
fffffadfe4a71b07 fffffabec5a70d30 fffffadfe6a7cb00 fffffabec5a70d30 : nt!IovCallDriver+0x1b5

fffffadfe4a718e0 fffff800010c494c :
fffffadfe6a7cb00 fffffa8001c12e20 fffffadfe7973e40 fffffadfe7973e40 : nt!IopSynchronousCall+0x14a

fffffadfe4a71950 fffff80001336e85 :
000094c0e44b9b90 0000000000000000 fffffa8001c22a70 0000000080000000 : nt!IopRemoveLockedDeviceNode+0x98d

fffffadfe4a71b00 fffff8000133b9db :
fffffadfdde4fae8 0000000000000000 fffffa800220b0b0 fffffa8002e6e784 :
nt!IopDeleteLockedDeviceNodes+0x135

fffffadfe4a71b60 fffff800012b3364 :
0000000000000000 fffffadfe7984bb0 0000000000000001 fffffa8001c22a70 :
nt!PiProcessQueryRemoveAndEject+0x1471

fffffadfe4a71c90 fffff80001056d6c :
fffffadfe6723180 fffff80001225960 fffffadfe7952760 fffff800011a69b8 : nt!PiWalkDeviceList+0x255

fffffadfe4a71d00 fffff80001272bae :
fffffadfe7952760 0000000000000080 fffffadfe7952760 fffffadfe4673680 : nt!ExpWorkerThread+0x13b

fffffadfe4a71d70 fffff8000102d016 :
fffffadfe466b180 fffffadfe7952760 fffffadfe4673680 0000000000000000 : nt!PspSystemThreadStartup+0x3e

fffffadfe4a71dd0 0000000000000000 :
0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:

mydriver!operator delete+42
[c:\projects\mydriver\software\source\capture\cp.h @
85]

fffffadf`e1e82502 4883c428 add rsp,0x28

FAULTING_SOURCE_CODE:

81: if( p )

82: {

83: ExFreePool( p );

84: }

85: }

86:

87: inline void * _cdecl operator new( size_t sz
)

88: {

89: PVOID p = ExAllocatePoolWithTag(
NonPagedPool, sz, ‘txnC’ );

90: DbgLogMicroTrace((“generic replacement new
size %d got = %p\n”, sz, p ) );

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: mydriver!operator delete+42

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4429932d

FAILURE_BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

Followup: MachineOwner

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2

Seems obvious enough. Your overloaded delete operator is attempting to
touch or free bogus memory. Why this is happening is entirely dependent on
what your driver is doing. You have a serious (fatal) bug in your memory
management.

Special pool is part of how Driver Verifier / Windows noticed the illegal
memory access. The main relevant facts are right there in the bugcheck
analysis. Look at the stack trace, and look at the memory that you are
passing to ExFreePoolWithTag. You’ll need to do some homework, and
investigate what that pointer is, why it is being freed, whether it might
already have been freed, etc. You should also check and make sure that your
driver is not corrupting the memory immediately before or after the memory
block that you are freeing.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Saurabh
Sent: Tuesday, March 28, 2006 5:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

I am hitting a bug check which indicates
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION.

I can reproduce it by disabling/enabling the driver with the special pool
flag set in static verfier.

Although it is happening only on 64-bit system I don’t think it is related
to the platform.

Under what circumstances would this happen?
What is special memory pool?

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: fffffabec6d62f90, address trying to free

Arg2: fffffabec6d62ff8, address where bits are corrupted

Arg3: 00000000007f4068, (reserved)

Arg4: 0000000000000024, caller is freeing an address where bytes after the
end of the allocation have been overwritten

Debugging Details:

*** Error in in reading nt!_ETHREAD @ 0000000000000000

*** Error in in reading nt!_ETHREAD @ 0000000000000000

BUGCHECK_STR: 0xC1_24

SPECIAL_POOL_CORRUPTION_TYPE: 24

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 2

LOCK_ADDRESS: fffff800011b5ae0 – (!locks
fffff800011b5ae0)

Resource @ nt!IopDeviceTreeLock (0xfffff800011b5ae0) Shared 1 owning
threads

Contention Count = 1

Threads: fffffadfe7952760-01<*>

1 total locks, 1 locks currently held

PNP_TRIAGE:

Lock address : 0xfffff800011b5ae0

Thread Count : 1

Thread address: 0xfffffadfe7952760

Thread wait : 0xf85a

LAST_CONTROL_TRANSFER: from fffff800010c8ede to fffff8000104b350

STACK_TEXT:

fffffadfe4a70b48 fffff800010c8ede :
fffffabec6d62f90 0000000000000000 00000000000000c1 fffff8000106144e :
nt!RtlpBreakWithStatusInstruction

fffffadfe4a70b50 fffff800010ca4c4 :
fffff80000000003 00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 : nt!KiBugCheckDebugBreak+0x1e

fffffadfe4a70bb0 fffff800010502d4 :
fffffadfe4a71260 fffffadfe4a71258 fffffadfe4a72000 fffff800013d2f48 : nt!KeBugCheck2+0x676

fffffadfe4a71200 fffff800013e6d74 :
00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 00000000007f4068 : nt!KeBugCheckEx+0x104

fffffadfe4a71240 fffff80001184292 :
fffffabec6d62f90 fffffabec5a70d30 0000000000000001 fffffadfe79cd2e0 :
nt!MmFreeSpecialPool+0x334

fffffadfe4a712c0 fffffadfe1e82502 :
fffffabec6d1aff0 fffffabec6d64de0 fffffadfe66598a0 fffffabec5a70d30 :
nt!ExFreePoolWithTag+0x15c

fffffadfe4a71380 fffffadfe1eab2ac :
fffffabec6d62f90 0000000000000284 fffffadfe4a713d8 0000000000000018 : mydriver!operator delete+0x42
[c:\projects\mydriver\software\source\capture\cp.h @ 85]

fffffadfe4a713b0 fffffadfe1e86191 :
fffffabec6d62f90 fffffadf00000001 0000000000000000 0000000000000000 :
mydriver!GenTunerDemod::`scalar deleting destructor’+0x2c

fffffadfe4a713e0 fffffadfe1e845af :
fffffabec5cd6e60 fffffadfe698aae0 fffffa80004a7fd0 fffffadfe669e140 :
mydriver!Device::unInit+0x4f1
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 1685]

fffffadfe4a716d0 fffffadfe1e676ee :
fffffadfe6a197f0 fffffabec5a70d30 fffffadfe69e7320 fffffadfe6a19730 :
mydriver!Device::dispatchPnpStop+0x1f
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 922]

fffffadfe4a71700 fffffadfe1e5f2f5 :
fffffadfe66598a0 fffffadfe4a717d0 fffffadfe6a19730 fffffabec5a70d30 :
ks!CKsDevice::PnpStop+0xaf

fffffadfe4a71760 fffff800013c6255 :
fffffadfe66598a0 fffffadfe4a717d0 fffffabec5a70d30 fffffadfe6b56bf0 :
ks!CKsDevice::DispatchPnp+0xf0

fffffadfe4a717a0 fffffadfe4c2b814 :
fffffadfe6b15900 fffffabec5a70d30 0000000000000000 fffffabec5a70d30 :
nt!IovCallDriver+0x1b5

fffffadfe4a71810 fffff800013c6255 :
fffffadfe6afde90 fffffadfe4a718a0 fffffabec5a70d30 fffffadfe6a7cbf0 :
ksthunk!CKernelFilterDevice::DispatchIrp+0x294

fffffadfe4a71870 fffff80001226573 :
fffffadfe4a71b07 fffffabec5a70d30 fffffadfe6a7cb00 fffffabec5a70d30 :
nt!IovCallDriver+0x1b5

fffffadfe4a718e0 fffff800010c494c :
fffffadfe6a7cb00 fffffa8001c12e20 fffffadfe7973e40 fffffadfe7973e40 :
nt!IopSynchronousCall+0x14a

fffffadfe4a71950 fffff80001336e85 :
000094c0e44b9b90 0000000000000000 fffffa8001c22a70 0000000080000000 :
nt!IopRemoveLockedDeviceNode+0x98d

fffffadfe4a71b00 fffff8000133b9db :
fffffadfdde4fae8 0000000000000000 fffffa800220b0b0 fffffa8002e6e784 :
nt!IopDeleteLockedDeviceNodes+0x135

fffffadfe4a71b60 fffff800012b3364 :
0000000000000000 fffffadfe7984bb0 0000000000000001 fffffa8001c22a70 :
nt!PiProcessQueryRemoveAndEject+0x1471

fffffadfe4a71c90 fffff80001056d6c :
fffffadfe6723180 fffff80001225960 fffffadfe7952760 fffff800011a69b8 : nt!PiWalkDeviceList+0x255

fffffadfe4a71d00 fffff80001272bae :
fffffadfe7952760 0000000000000080 fffffadfe7952760 fffffadfe4673680 :
nt!ExpWorkerThread+0x13b

fffffadfe4a71d70 fffff8000102d016 :
fffffadfe466b180 fffffadfe7952760 fffffadfe4673680 0000000000000000 :
nt!PspSystemThreadStartup+0x3e

fffffadfe4a71dd0 0000000000000000 :
0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:

mydriver!operator delete+42
[c:\projects\mydriver\software\source\capture\cp.h @ 85]

fffffadf`e1e82502 4883c428 add rsp,0x28

FAULTING_SOURCE_CODE:

81: if( p )

82: {

83: ExFreePool( p );

84: }

85: }

86:

87: inline void * _cdecl operator new( size_t sz
)

88: {

89: PVOID p = ExAllocatePoolWithTag(
NonPagedPool, sz, ‘txnC’ );

90: DbgLogMicroTrace((“generic replacement new
size %d got = %p\n”, sz, p ) );

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: mydriver!operator delete+42

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4429932d

FAILURE_BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

Followup: MachineOwner

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

Saurabh wrote:

I am hitting a bug check which indicates
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION.

I can reproduce it by disabling/enabling the driver
with the special pool flag set in static verfier.

Although it is happening only on 64-bit system I don’t
think it is related to the platform.

Under what circumstances would this happen?
What is special memory pool?

When you turn on verifier with the special pool flag, all of your memory
allocations come from a “special pool”, in which it takes extra steps to
detect overwrites above or below the memory.

I notice that it’s deleting a GenTunerDemod. Is it possible
GenTunerDemod was allocated using a placement new from existing memory
that was handed to you in DispatchAdd? If so, you MUST NOT do a
“delete” on that memory. You didn’t allocate it, so you don’t know
where it came from. You can run the desctructor:

demod->~GenTunerDemod();

but you cannot delete it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Actually I think the key is here: " Arg4: 0000000000000024, caller is
freeing an address where bytes after the end of the allocation have been
overwritten"

This is a classic buffer overrun condition, not stale pointer condition.
You (our OP, not you Arlie) allocated some number of bytes and then
proceeded to write past the end of that allocation.

Verifier was kind enough to provide the additional clues:
Arg1: fffffabec6d62f90, address trying to free

Arg2: fffffabec6d62ff8, address where bits are corrupted

All you need to do is figure out what the original allocation size is,
and then look at the crap your driver is spewing around 104 bytes (0x68)
past the start of the buffer. Then just figure out why you are doing
that.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, March 28, 2006 5:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

Seems obvious enough. Your overloaded delete operator is attempting to
touch or free bogus memory. Why this is happening is entirely dependent
on
what your driver is doing. You have a serious (fatal) bug in your
memory
management.

Special pool is part of how Driver Verifier / Windows noticed the
illegal
memory access. The main relevant facts are right there in the bugcheck
analysis. Look at the stack trace, and look at the memory that you are
passing to ExFreePoolWithTag. You’ll need to do some homework, and
investigate what that pointer is, why it is being freed, whether it
might
already have been freed, etc. You should also check and make sure that
your
driver is not corrupting the memory immediately before or after the
memory
block that you are freeing.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Saurabh
Sent: Tuesday, March 28, 2006 5:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

I am hitting a bug check which indicates
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION.

I can reproduce it by disabling/enabling the driver with the special
pool
flag set in static verfier.

Although it is happening only on 64-bit system I don’t think it is
related
to the platform.

Under what circumstances would this happen?
What is special memory pool?

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: fffffabec6d62f90, address trying to free

Arg2: fffffabec6d62ff8, address where bits are corrupted

Arg3: 00000000007f4068, (reserved)

Arg4: 0000000000000024, caller is freeing an address where bytes after
the
end of the allocation have been overwritten

Debugging Details:

*** Error in in reading nt!_ETHREAD @ 0000000000000000

*** Error in in reading nt!_ETHREAD @ 0000000000000000

BUGCHECK_STR: 0xC1_24

SPECIAL_POOL_CORRUPTION_TYPE: 24

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 2

LOCK_ADDRESS: fffff800011b5ae0 – (!locks
fffff800011b5ae0)

Resource @ nt!IopDeviceTreeLock (0xfffff800011b5ae0) Shared 1 owning
threads

Contention Count = 1

Threads: fffffadfe7952760-01<*>

1 total locks, 1 locks currently held

PNP_TRIAGE:

Lock address : 0xfffff800011b5ae0

Thread Count : 1

Thread address: 0xfffffadfe7952760

Thread wait : 0xf85a

LAST_CONTROL_TRANSFER: from fffff800010c8ede to fffff8000104b350

STACK_TEXT:

fffffadfe4a70b48 fffff800010c8ede :
fffffabec6d62f90 0000000000000000 00000000000000c1 fffff8000106144e
:
nt!RtlpBreakWithStatusInstruction

fffffadfe4a70b50 fffff800010ca4c4 :
fffff80000000003 00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 : nt!KiBugCheckDebugBreak+0x1e

fffffadfe4a70bb0 fffff800010502d4 :
fffffadfe4a71260 fffffadfe4a71258 fffffadfe4a72000 fffff800013d2f48 : nt!KeBugCheck2+0x676

fffffadfe4a71200 fffff800013e6d74 :
00000000000000c1 fffffabec6d62f90 fffffabec6d62ff8 00000000007f4068 : nt!KeBugCheckEx+0x104

fffffadfe4a71240 fffff80001184292 :
fffffabec6d62f90 fffffabec5a70d30 0000000000000001 fffffadfe79cd2e0
:
nt!MmFreeSpecialPool+0x334

fffffadfe4a712c0 fffffadfe1e82502 :
fffffabec6d1aff0 fffffabec6d64de0 fffffadfe66598a0 fffffabec5a70d30
:
nt!ExFreePoolWithTag+0x15c

fffffadfe4a71380 fffffadfe1eab2ac :
fffffabec6d62f90 0000000000000284 fffffadfe4a713d8 0000000000000018 : mydriver!operator delete+0x42
[c:\projects\mydriver\software\source\capture\cp.h @ 85]

fffffadfe4a713b0 fffffadfe1e86191 :
fffffabec6d62f90 fffffadf00000001 0000000000000000 0000000000000000
:
mydriver!GenTunerDemod::`scalar deleting destructor’+0x2c

fffffadfe4a713e0 fffffadfe1e845af :
fffffabec5cd6e60 fffffadfe698aae0 fffffa80004a7fd0 fffffadfe669e140
:
mydriver!Device::unInit+0x4f1
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 1685]

fffffadfe4a716d0 fffffadfe1e676ee :
fffffadfe6a197f0 fffffabec5a70d30 fffffadfe69e7320 fffffadfe6a19730
:
mydriver!Device::dispatchPnpStop+0x1f
[c:\projects\mydriver\software\source\capture\devi.cpp
@ 922]

fffffadfe4a71700 fffffadfe1e5f2f5 :
fffffadfe66598a0 fffffadfe4a717d0 fffffadfe6a19730 fffffabec5a70d30
:
ks!CKsDevice::PnpStop+0xaf

fffffadfe4a71760 fffff800013c6255 :
fffffadfe66598a0 fffffadfe4a717d0 fffffabec5a70d30 fffffadfe6b56bf0
:
ks!CKsDevice::DispatchPnp+0xf0

fffffadfe4a717a0 fffffadfe4c2b814 :
fffffadfe6b15900 fffffabec5a70d30 0000000000000000 fffffabec5a70d30
:
nt!IovCallDriver+0x1b5

fffffadfe4a71810 fffff800013c6255 :
fffffadfe6afde90 fffffadfe4a718a0 fffffabec5a70d30 fffffadfe6a7cbf0
:
ksthunk!CKernelFilterDevice::DispatchIrp+0x294

fffffadfe4a71870 fffff80001226573 :
fffffadfe4a71b07 fffffabec5a70d30 fffffadfe6a7cb00 fffffabec5a70d30
:
nt!IovCallDriver+0x1b5

fffffadfe4a718e0 fffff800010c494c :
fffffadfe6a7cb00 fffffa8001c12e20 fffffadfe7973e40 fffffadfe7973e40
:
nt!IopSynchronousCall+0x14a

fffffadfe4a71950 fffff80001336e85 :
000094c0e44b9b90 0000000000000000 fffffa8001c22a70 0000000080000000
:
nt!IopRemoveLockedDeviceNode+0x98d

fffffadfe4a71b00 fffff8000133b9db :
fffffadfdde4fae8 0000000000000000 fffffa800220b0b0 fffffa8002e6e784 :
nt!IopDeleteLockedDeviceNodes+0x135

fffffadfe4a71b60 fffff800012b3364 :
0000000000000000 fffffadfe7984bb0 0000000000000001 fffffa8001c22a70
:
nt!PiProcessQueryRemoveAndEject+0x1471

fffffadfe4a71c90 fffff80001056d6c :
fffffadfe6723180 fffff80001225960 fffffadfe7952760 fffff800011a69b8 : nt!PiWalkDeviceList+0x255

fffffadfe4a71d00 fffff80001272bae :
fffffadfe7952760 0000000000000080 fffffadfe7952760 fffffadfe4673680
:
nt!ExpWorkerThread+0x13b

fffffadfe4a71d70 fffff8000102d016 :
fffffadfe466b180 fffffadfe7952760 fffffadfe4673680 0000000000000000
:
nt!PspSystemThreadStartup+0x3e

fffffadfe4a71dd0 0000000000000000 :
0000000000000000 0000000000000000 0000000000000000 0000000000000000
:
nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:

mydriver!operator delete+42
[c:\projects\mydriver\software\source\capture\cp.h @ 85]

fffffadf`e1e82502 4883c428 add rsp,0x28

FAULTING_SOURCE_CODE:

81: if( p )

82: {

83: ExFreePool( p );

84: }

85: }

86:

87: inline void * _cdecl operator new( size_t sz
)

88: {

89: PVOID p = ExAllocatePoolWithTag(
NonPagedPool, sz, ‘txnC’ );

90: DbgLogMicroTrace((“generic replacement new
size %d got = %p\n”, sz, p ) );

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: mydriver!operator delete+42

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4429932d

FAILURE_BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

BUCKET_ID:
X64_0xC1_24_VRF_mydriver!operator_delete+42

Followup: MachineOwner

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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