[OSR-DETECTED-SPAM] RE:Conflicting statements in MSDN about IoReleaseRemoveLockAndWait

NTDEV
1

I see that “wait for private event” pattern all over the place, and I’m
not sure that every use I see is valid. It is a fallback to the old
“sequencing is syntax and syntax is sequencing” fallacy. Why not just do
the necessary work in the completion routine? It is particularly nasty
when it involves devices with unbounded wait times being called from the
dispatch routines, because it means that even if the user requested
FILE_FLAG_OVERLAPPED so the thread would not block, it blocks anyway.

I once saw a similar crash, with a very high address. It turns out the
address (which was much lower than the one shown here) was the device
register address. I suggested that it was intermittent PCI bus failure;
that somehow, the device failed to acknowledge the PCI address within the
specified number of bus cycles, so an access failure was generated. This
was only because for hundreds of thousands of reads, that address returned
valid data from the device. I offer this only for examination; the
address shown here is suspiciously like an address you might see if a
bogus address was passed to, say, the storage allocator, which is
attempting to use the pre-address “header” bytes to do something. Say,
for example, a NULL pointer; subtract off some value to look at some
header field, and the address shown is what would be computed.
joe

Thank you Scott.

My driver is WDM. I can recreate the BSOD but not regularly. Every time I
can though it shows my driver’s stack to be in the call passing the remove
IRP down, hence my suspicion on the ordering.
I will put my stack as well but first is the !analyze -v output. I have
driver verifier running on the machine and it did not detect anything
special.

<<
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffffffffffffd0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880010d0862, address which referenced memory

Debugging Details:

READ_ADDRESS: ffffffffffffffd0

CURRENT_IRQL: 2

FAULTING_IP:
Wdf01000!FxDevice::Dispatch+22
fffff880`010d0862 4c8b50d0 mov r10,qword ptr [rax-30h]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: fffff8800203d2c0 – (.trap 0xfffff8800203d2c0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8003d40370
rdx=fffff9800b642e10 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880010d0862 rsp=fffff8800203d450 rbp=0000000000000002
r8=fffffa8002c97e70 r9=0000000000000001 r10=fffff9800b642e10
r11=fffff9800b642e02 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
Wdf01000!FxDevice::Dispatch+0x22:
fffff880`010d0862 4c8b50d0 mov r10,qword ptr [rax-30h]
ds:dc18:ffd0=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001dc9a12 to fffff80001cd0a30

STACK_TEXT:
fffff8800203ca08 fffff80001dc9a12 : ffffffffffffffd0 fffff8800201ff40
0000000000000065 fffff80001d13888 : nt!RtlpBreakWithStatusInstruction
fffff8800203ca10 fffff80001dca7fe : 0000000000000003 0000000000000000
fffff80001d140e0 00000000000000d1 : nt!KiBugCheckDebugBreak+0x12
fffff8800203ca70 fffff80001cd8d04 : fffffa80036e9e20 fffff88000e60872
0000000000000001 fffff80001d550c4 : nt!KeBugCheck2+0x71e
fffff8800203d140 fffff80001cd81a9 : 000000000000000a ffffffffffffffd0
0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff8800203d180 fffff80001cd6e20 : 0000000000000000 00000000a0000003
fffff9801f920e10 fffff9800b642e10 : nt!KiBugCheckDispatch+0x69
fffff8800203d2c0 fffff880010d0862 : fffffa8003d40370 0000000000000002
fffffa800473ff40 fffff8000217ee96 : nt!KiPageFault+0x260
fffff8800203d450 fffff880010d0aa6 : fffff9800b642e10 0000000000000002
fffffa8003d40370 fffff8800203dc18 : Wdf01000!FxDevice::Dispatch+0x22
fffff8800203d490 fffff80002182d26 : fffff9800b642e10 0000000000000002
fffffa8003d40370 e83f03ffffe00007 :
Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff8800203d4d0 fffff80001ce384c : fffff8800203d5f0 0000000000000000
0000000000000001 fffffa800473ff40 : nt!IovCallDriver+0x566
fffff8800203d530 fffff80001ce36e6 : fffffa8004360748 fffffa8004360748
0000000000000000 0000000000000000 : nt!KiProcessTimerDpcTable+0x6c
fffff8800203d5a0 fffff80001ce35ce : 0000001479a9100e fffff8800203dc18
0000000000089683 fffff880020185e8 : nt!KiProcessExpiredTimerList+0xc6
fffff8800203dbf0 fffff80001ce33b7 : 0000140b8ff202c5 0000140b00089683
0000140b8ff20263 0000000000000083 : nt!KiTimerExpiration+0x1be
fffff8800203dc90 fffff80001cd090a : fffff88002015180 fffff8800201ff40
0000000000000001 fffff80000000000 : nt!KiRetireDpcList+0x277
fffff8800203dd40 0000000000000000 : fffff8800203e000 fffff88002038000
fffff8800203dd00 0000000000000000 : nt!KiIdleLoop+0x5a

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxDevice::Dispatch+22
fffff880`010d0862 4c8b50d0 mov r10,qword ptr [rax-30h]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: Wdf01000!FxDevice::Dispatch+22

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5010aa89

FAILURE_BUCKET_ID: X64_0xD1_VRF_Wdf01000!FxDevice::Dispatch+22

BUCKET_ID: X64_0xD1_VRF_Wdf01000!FxDevice::Dispatch+22

Followup: MachineOwner

>>

and the thread’s stack related to the PnP device removal that’s going
through my driver (DcsPMF and DcsDf) at the time of the BSOD (note: the
drivers send the IRP down and wait for its completion so if STATUS_PENDING
is returned there’s a WaitForSingleObject that wakes up when the IRP
completion routine sets a private event).

<<
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr : Args to Child
: Call Site
fffff880059aac50 fffff80001cce612 : 0000000000000017 fffffa80044153c0
0000000000000000 0000000000000008 : nt!KiSwapContext+0x7a
fffff880059aad90 fffff80001cdf98f : fffffa8002ca6001 fffffa80040621b0
0000000000000000 0000000000000000 : nt!KiCommitThreadWait+0x1d2
fffff880059aae20 fffff880013e08fa : 0000000000000000 0000000000000000
fffffa8004062000 fffffa8004062100 : nt!KeWaitForSingleObject+0x19f
fffff880059aaec0 fffff880013dcb08 : fffffa8003d40370 0000000000000000
0000000000000002 fffff880013d7110 : CLASSPNP!ClassRemoveDevice+0x12a
fffff880059aaf00 fffff80002182d26 : fffffa80040621b0 fffffa8002ca6038
fffff9801f614c60 fffff8000217e48e : CLASSPNP! ??
::NNGAKEGL::string'+0x17a6 fffff880059aaf90 fffff800021855ea : fffff9801f614e50 fffffa8004062060 fffffa80044372a0 fffffa80018fc320 : nt!IovCallDriver+0x566 fffff880059aaff0 fffff80002182d26 : fffff9801f614c60 0000000000000002 fffffa80044372a0 fffffa800421a0b0 : nt!ViFilterDispatchPnp+0xea fffff880059ab020 fffff880017e270c : fffff9801f614c60 0000000000000002 fffff9801f614f18 fffffa800421a0b0 : nt!IovCallDriver+0x566 fffff880059ab080 fffff880017e6298 : fffffa8002d26830 fffff9801f614c60 fffffa8002d26830 fffffa80032a1410 : DcsDf!DiskPerfForwardIrpSynchronous+0xac fffff880059ab110 fffff880017e5778 : fffffa8002d26830 fffff9801f614c60 0000000000000000 0000000000000000 : DcsDf!DiskPerfRemoveDevice+0x58 fffff880059ab150 fffff80002182d26 : fffffa8002d26830 fffff9801f614c60 fffff9801f614c60 fffff8000217e48e : DcsDf!DiskPerfDispatchPnp+0x148 fffff880059ab1d0 fffff800021855ea : fffff9801f614ee0 fffffa8002d26830 fffffa80042f5af0 fffffa80032a1410 : nt!IovCallDriver+0x566 fffff880059ab230 fffff80002182d26 : fffff9801f614c60 0000000000000002 fffffa80042f5af0 fffffa8003212a70 : nt!ViFilterDispatchPnp+0xea fffff880059ab260 fffff880014b6926 : fffff9801f614c60 0000000000000002 fffff9801f614fa8 fffffa8003212a70 : nt!IovCallDriver+0x566 fffff880059ab2c0 fffff880014b82c5 : fffffa8003405060 fffff9801f614c60 fffff880059ab3f0 fffff880059ab3d8 : DcsPMF!PMFForwardIrpSynchronous+0xd6 fffff880059ab340 fffff880014b8d78 : fffffa8003405060 fffff9801f614c60 0000000000000003 0000000000000000 : DcsPMF!PMFRemoveDevice+0x2e5 fffff880059ab510 fffff80002182d26 : fffffa8003405060 fffff9801f614c60 fffff9801f614c60 fffff8000217e48e : DcsPMF!PMFDispatchPnp+0x738 fffff880059ab5d0 fffff800021855ea : fffff9801f614f70 fffffa8003405060 fffffa8003fd2700 fffffa80043d6eb0 : nt!IovCallDriver+0x566 fffff880059ab630 fffff80002182d26 : fffff9801f614c60 0000000000000002 fffffa8003fd2700 fffffa8003b2a010 : nt!ViFilterDispatchPnp+0xea fffff880059ab660 fffff8800108530e : fffff9801f614c60 fffff9801f614fb8 0000000000000000 fffffa8003b2a010 : nt!IovCallDriver+0x566 fffff880059ab6c0 fffff80002182d26 : fffff9801f614c60 0000000000000002 fffffa80039c0330 00000000c00000bb : partmgr!PmPnp+0xfe fffff880059ab710 fffff80001f46d11 : fffffa80039c0330 fffff880059ab828 00000000c00000bb fffffa8003b44010 : nt!IovCallDriver+0x566 fffff880059ab770 fffff800020c5681 : fffffa8004743060 0000000000000000 fffffa80047384a0 0000000000000801 : nt!IopSynchronousCall+0xe1 fffff880059ab7e0 fffff80001ddb063 : fffff8a0023b6f20 fffff8a0023b6f20 0000000000000018 0000000000000000 : nt!IopRemoveDevice+0x101 fffff880059ab8a0 fffff800020c51d4 : fffffa80047384a0 0000000000000000 0000000000000002 0000000000000000 : nt!PnpRemoveLockedDeviceNode+0x1a3 fffff880059ab8f0 fffff800020c52e0 : 0000000000000000 fffffa8004743000 fffff8a0074b8900 fffff80001edca80 : nt!PnpDeleteLockedDeviceNode+0x44 fffff880059ab920 fffff800020c53d9 : fffffa8004601602 fffffa8004601600 0000000000000001 0000000000000000 : nt!PnpDeleteLockedDeviceNodes+0xa0 fffff880059ab990 fffff800020c5551 : fffffa8004601600 0000000000000000 fffffa8004601600 0000000000010286 : nt!PnpDelayedRemoveWorker+0x79 fffff880059ab9e0 fffff80001ddb289 : 0000000000000000 fffffa80035e0a50 0000000000000001 0000000000000000 : nt!PnpChainDereferenceComplete+0x131 fffff880059aba20 fffff80002156570 : 0000000000000000 fffffa8004738400 fffff8a00398cef0 0000000000000001 : nt!PnpIsChainDereferenced+0xc9 fffff880059abaa0 fffff8000215680c : fffff880059abc78 0000000000010200 fffff880059abc00 0000000000000000 : nt!PnpProcessQueryRemoveAndEject+0xff0 fffff880059abbe0 fffff8000203f9ae : 0000000000000000 fffffa800466eb00 fffff8a00398cef0 fffff880059abc00 : nt!PnpProcessTargetDeviceEvent+0x4c fffff880059abc10 fffff80001ce2251 : fffff80001f45b98 fffff8a00398cef0 fffff80001e7e2d8 fffff80001e7e2d8 : nt! ?? ::NNGAKEGL::string’+0x552ab
fffff880059abc70 fffff80001f76ede : 0000000000000000 fffffa80044153c0
0000000000000080 fffffa8001876890 : nt!ExpWorkerThread+0x111
fffff880059abd00 fffff80001cc9906 : fffff88002015180 fffffa80044153c0
fffffa80028dcb50 0000000000000202 : nt!PspSystemThreadStartup+0x5a
fffff880059abd40 0000000000000000 : fffff880059ac000 fffff880059a6000
fffff880059aa8a0 0000000000000000 : nt!KxStartSystemThread+0x16
>>

NTDEV is sponsored by OSR

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

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

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

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

2

Weird. My messages are now classified as "spam?

I posted something to a blog a couple days ago, saying that I was looking
for a cheap wireless chip, and it was rejected because I used the word
“cheap”, which it called a “spamword”. So I changed it to “minimally
expensive” and it went through (I added that the post had been rejected
because it had cee-aitch-ee-ay-pee in it, just to embarrass the site
managers)

Another thing that looks a bit suspicious: that 0x00000000`00000002. It
could be just a flag, or it could be a bad address. Could there be
another path munging this IRP and possibly even completing it while this
path thinks it still has a valid pointer? The “2” might be a storage
manager flag, or some storage manager value, or something random because
that address now refers to an object of type B (for some value of B)
instead of an IRP.
joe

I see that “wait for private event” pattern all over the place, and I’m
not sure that every use I see is valid. It is a fallback to the old
“sequencing is syntax and syntax is sequencing” fallacy. Why not just do
the necessary work in the completion routine? It is particularly nasty
when it involves devices with unbounded wait times being called from the
dispatch routines, because it means that even if the user requested
FILE_FLAG_OVERLAPPED so the thread would not block, it blocks anyway.

I once saw a similar crash, with a very high address. It turns out the
address (which was much lower than the one shown here) was the device
register address. I suggested that it was intermittent PCI bus failure;
that somehow, the device failed to acknowledge the PCI address within the
specified number of bus cycles, so an access failure was generated. This
was only because for hundreds of thousands of reads, that address returned
valid data from the device. I offer this only for examination; the
address shown here is suspiciously like an address you might see if a
bogus address was passed to, say, the storage allocator, which is
attempting to use the pre-address “header” bytes to do something. Say,
for example, a NULL pointer; subtract off some value to look at some
header field, and the address shown is what would be computed.
joe

> Thank you Scott.
>
> My driver is WDM. I can recreate the BSOD but not regularly. Every time
> I
> can though it shows my driver’s stack to be in the call passing the
> remove
> IRP down, hence my suspicion on the ordering.
> I will put my stack as well but first is the !analyze -v output. I have
> driver verifier running on the machine and it did not detect anything
> special.
>
> <<
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: ffffffffffffffd0, memory referenced
> Arg2: 0000000000000002, IRQL
> Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
> Arg4: fffff880010d0862, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: ffffffffffffffd0
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> Wdf01000!FxDevice::Dispatch+22
> fffff880010d0862 4c8b50d0 mov r10,qword ptr [rax-30h] \> \> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT \> \> BUGCHECK_STR: 0xD1 \> \> PROCESS_NAME: System \> \> TRAP_FRAME: fffff8800203d2c0 -- (.trap 0xfffff8800203d2c0) \> NOTE: The trap frame does not contain all registers. \> Some register values may be zeroed or incorrect. \> rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8003d40370 \> rdx=fffff9800b642e10 rsi=0000000000000000 rdi=0000000000000000 \> rip=fffff880010d0862 rsp=fffff8800203d450 rbp=0000000000000002 \> r8=fffffa8002c97e70 r9=0000000000000001 r10=fffff9800b642e10 \> r11=fffff9800b642e02 r12=0000000000000000 r13=0000000000000000 \> r14=0000000000000000 r15=0000000000000000 \> iopl=0 nv up ei pl zr na po nc \> Wdf01000!FxDevice::Dispatch+0x22: \> fffff880010d0862 4c8b50d0 mov r10,qword ptr [rax-30h]
> ds:dc18:ffd0=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from fffff80001dc9a12 to fffff80001cd0a30
>
> STACK_TEXT:
> fffff8800203ca08 fffff80001dc9a12 : ffffffffffffffd0 \> fffff8800201ff40
> 0000000000000065 fffff80001d13888 : nt!RtlpBreakWithStatusInstruction
> fffff8800203ca10 fffff80001dca7fe : 0000000000000003 \> 0000000000000000
> fffff80001d140e0 00000000000000d1 : nt!KiBugCheckDebugBreak+0x12
> fffff8800203ca70 fffff80001cd8d04 : fffffa80036e9e20 \> fffff88000e60872
> 0000000000000001 fffff80001d550c4 : nt!KeBugCheck2+0x71e
> fffff8800203d140 fffff80001cd81a9 : 000000000000000a \> ffffffffffffffd0
> 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
> fffff8800203d180 fffff80001cd6e20 : 0000000000000000 \> 00000000a0000003
> fffff9801f920e10 fffff9800b642e10 : nt!KiBugCheckDispatch+0x69
> fffff8800203d2c0 fffff880010d0862 : fffffa8003d40370 \> 0000000000000002
> fffffa800473ff40 fffff8000217ee96 : nt!KiPageFault+0x260
> fffff8800203d450 fffff880010d0aa6 : fffff9800b642e10 \> 0000000000000002
> fffffa8003d40370 fffff8800203dc18 : Wdf01000!FxDevice::Dispatch+0x22
> fffff8800203d490 fffff80002182d26 : fffff9800b642e10 \> 0000000000000002
> fffffa8003d40370 e83f03ffffe00007 :
> Wdf01000!FxDevice::DispatchWithLock+0xa6
> fffff8800203d4d0 fffff80001ce384c : fffff8800203d5f0 \> 0000000000000000
> 0000000000000001 fffffa800473ff40 : nt!IovCallDriver+0x566
> fffff8800203d530 fffff80001ce36e6 : fffffa8004360748 \> fffffa8004360748
> 0000000000000000 0000000000000000 : nt!KiProcessTimerDpcTable+0x6c
> fffff8800203d5a0 fffff80001ce35ce : 0000001479a9100e \> fffff8800203dc18
> 0000000000089683 fffff880020185e8 : nt!KiProcessExpiredTimerList+0xc6
> fffff8800203dbf0 fffff80001ce33b7 : 0000140b8ff202c5 \> 0000140b00089683
> 0000140b8ff20263 0000000000000083 : nt!KiTimerExpiration+0x1be
> fffff8800203dc90 fffff80001cd090a : fffff88002015180 \> fffff8800201ff40
> 0000000000000001 fffff80000000000 : nt!KiRetireDpcList+0x277
> fffff8800203dd40 0000000000000000 : fffff8800203e000 \> fffff88002038000
> fffff8800203dd00 0000000000000000 : nt!KiIdleLoop+0x5a
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> Wdf01000!FxDevice::Dispatch+22
> fffff880010d0862 4c8b50d0 mov r10,qword ptr [rax-30h] \> \> SYMBOL_STACK_INDEX: 6 \> \> SYMBOL_NAME: Wdf01000!FxDevice::Dispatch+22 \> \> FOLLOWUP_NAME: MachineOwner \> \> MODULE_NAME: Wdf01000 \> \> IMAGE_NAME: Wdf01000.sys \> \> DEBUG_FLR_IMAGE_TIMESTAMP: 5010aa89 \> \> FAILURE_BUCKET_ID: X64_0xD1_VRF_Wdf01000!FxDevice::Dispatch+22 \> \> BUCKET_ID: X64_0xD1_VRF_Wdf01000!FxDevice::Dispatch+22 \> \> Followup: MachineOwner \> --------- \>\>\> \> \> and the thread's stack related to the PnP device removal that's going \> through my driver (DcsPMF and DcsDf) at the time of the BSOD (note: the \> drivers send the IRP down and wait for its completion so if \> STATUS_PENDING \> is returned there's a WaitForSingleObject that wakes up when the IRP \> completion routine sets a private event). \> \> \<\< \> \*\*\* Stack trace for last set context - .thread/.cxr resets it \> Child-SP RetAddr : Args to Child \> : Call Site \> fffff880059aac50 fffff80001cce612 : 0000000000000017
> fffffa80044153c0 \> 0000000000000000 0000000000000008 : nt!KiSwapContext+0x7a \> fffff880059aad90 fffff80001cdf98f : fffffa8002ca6001
> fffffa80040621b0 \> 0000000000000000 0000000000000000 : nt!KiCommitThreadWait+0x1d2 \> fffff880059aae20 fffff880013e08fa : 0000000000000000
> 0000000000000000 \> fffffa8004062000 fffffa8004062100 : nt!KeWaitForSingleObject+0x19f \> fffff880059aaec0 fffff880013dcb08 : fffffa8003d40370
> 0000000000000000 \> 0000000000000002 fffff880013d7110 : CLASSPNP!ClassRemoveDevice+0x12a \> fffff880059aaf00 fffff80002182d26 : fffffa80040621b0
> fffffa8002ca6038 \> fffff9801f614c60 fffff8000217e48e : CLASSPNP! ?? \> ::NNGAKEGL::string’+0x17a6
> fffff880059aaf90 fffff800021855ea : fffff9801f614e50 \> fffffa8004062060
> fffffa80044372a0 fffffa80018fc320 : nt!IovCallDriver+0x566
> fffff880059aaff0 fffff80002182d26 : fffff9801f614c60 \> 0000000000000002
> fffffa80044372a0 fffffa800421a0b0 : nt!ViFilterDispatchPnp+0xea
> fffff880059ab020 fffff880017e270c : fffff9801f614c60 \> 0000000000000002
> fffff9801f614f18 fffffa800421a0b0 : nt!IovCallDriver+0x566
> fffff880059ab080 fffff880017e6298 : fffffa8002d26830 \> fffff9801f614c60
> fffffa8002d26830 fffffa80032a1410 :
> DcsDf!DiskPerfForwardIrpSynchronous+0xac
> fffff880059ab110 fffff880017e5778 : fffffa8002d26830 \> fffff9801f614c60
> 0000000000000000 0000000000000000 : DcsDf!DiskPerfRemoveDevice+0x58
> fffff880059ab150 fffff80002182d26 : fffffa8002d26830 \> fffff9801f614c60
> fffff9801f614c60 fffff8000217e48e : DcsDf!DiskPerfDispatchPnp+0x148
> fffff880059ab1d0 fffff800021855ea : fffff9801f614ee0 \> fffffa8002d26830
> fffffa80042f5af0 fffffa80032a1410 : nt!IovCallDriver+0x566
> fffff880059ab230 fffff80002182d26 : fffff9801f614c60 \> 0000000000000002
> fffffa80042f5af0 fffffa8003212a70 : nt!ViFilterDispatchPnp+0xea
> fffff880059ab260 fffff880014b6926 : fffff9801f614c60 \> 0000000000000002
> fffff9801f614fa8 fffffa8003212a70 : nt!IovCallDriver+0x566
> fffff880059ab2c0 fffff880014b82c5 : fffffa8003405060 \> fffff9801f614c60
> fffff880059ab3f0 fffff880059ab3d8 :
> DcsPMF!PMFForwardIrpSynchronous+0xd6
> fffff880059ab340 fffff880014b8d78 : fffffa8003405060 \> fffff9801f614c60
> 0000000000000003 0000000000000000 : DcsPMF!PMFRemoveDevice+0x2e5
> fffff880059ab510 fffff80002182d26 : fffffa8003405060 \> fffff9801f614c60
> fffff9801f614c60 fffff8000217e48e : DcsPMF!PMFDispatchPnp+0x738
> fffff880059ab5d0 fffff800021855ea : fffff9801f614f70 \> fffffa8003405060
> fffffa8003fd2700 fffffa80043d6eb0 : nt!IovCallDriver+0x566
> fffff880059ab630 fffff80002182d26 : fffff9801f614c60 \> 0000000000000002
> fffffa8003fd2700 fffffa8003b2a010 : nt!ViFilterDispatchPnp+0xea
> fffff880059ab660 fffff8800108530e : fffff9801f614c60 \> fffff9801f614fb8
> 0000000000000000 fffffa8003b2a010 : nt!IovCallDriver+0x566
> fffff880059ab6c0 fffff80002182d26 : fffff9801f614c60 \> 0000000000000002
> fffffa80039c0330 00000000c00000bb : partmgr!PmPnp+0xfe
> fffff880059ab710 fffff80001f46d11 : fffffa80039c0330 \> fffff880059ab828
> 00000000c00000bb fffffa8003b44010 : nt!IovCallDriver+0x566
> fffff880059ab770 fffff800020c5681 : fffffa8004743060 \> 0000000000000000
> fffffa80047384a0 0000000000000801 : nt!IopSynchronousCall+0xe1
> fffff880059ab7e0 fffff80001ddb063 : fffff8a0023b6f20 \> fffff8a0023b6f20
> 0000000000000018 0000000000000000 : nt!IopRemoveDevice+0x101
> fffff880059ab8a0 fffff800020c51d4 : fffffa80047384a0 \> 0000000000000000
> 0000000000000002 0000000000000000 : nt!PnpRemoveLockedDeviceNode+0x1a3
> fffff880059ab8f0 fffff800020c52e0 : 0000000000000000 \> fffffa8004743000
> fffff8a0074b8900 fffff80001edca80 : nt!PnpDeleteLockedDeviceNode+0x44
> fffff880059ab920 fffff800020c53d9 : fffffa8004601602 \> fffffa8004601600
> 0000000000000001 0000000000000000 : nt!PnpDeleteLockedDeviceNodes+0xa0
> fffff880059ab990 fffff800020c5551 : fffffa8004601600 \> 0000000000000000
> fffffa8004601600 0000000000010286 : nt!PnpDelayedRemoveWorker+0x79
> fffff880059ab9e0 fffff80001ddb289 : 0000000000000000 \> fffffa80035e0a50
> 0000000000000001 0000000000000000 :
> nt!PnpChainDereferenceComplete+0x131
> fffff880059aba20 fffff80002156570 : 0000000000000000 \> fffffa8004738400
> fffff8a00398cef0 0000000000000001 : nt!PnpIsChainDereferenced+0xc9
> fffff880059abaa0 fffff8000215680c : fffff880059abc78 \> 0000000000010200
> fffff880059abc00 0000000000000000 :
> nt!PnpProcessQueryRemoveAndEject+0xff0
> fffff880059abbe0 fffff8000203f9ae : 0000000000000000 \> fffffa800466eb00
> fffff8a00398cef0 fffff880059abc00 :
> nt!PnpProcessTargetDeviceEvent+0x4c
> fffff880059abc10 fffff80001ce2251 : fffff80001f45b98 \> fffff8a00398cef0
> fffff80001e7e2d8 fffff80001e7e2d8 : nt! ??
> ::NNGAKEGL::string'+0x552ab \> fffff880059abc70 fffff80001f76ede : 0000000000000000
> fffffa80044153c0 \> 0000000000000080 fffffa8001876890 : nt!ExpWorkerThread+0x111 \> fffff880059abd00 fffff80001cc9906 : fffff88002015180
> fffffa80044153c0 \> fffffa80028dcb50 0000000000000202 : nt!PspSystemThreadStartup+0x5a \> fffff880059abd40 0000000000000000 : fffff880059ac000
> fffff880059a6000 \> fffff880059aa8a0 00000000`00000000 : nt!KxStartSystemThread+0x16
>>>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

NTDEV is sponsored by OSR

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

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

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

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