Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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

Doron_HolanDoron_Holan Member - All Emails Posts: 10,441
Definitely a calm into a wdf driver after the remove irp has been processed. You need to wait on the remlock after sending the remove irp

d

Bent from my phone
________________________________
From: Scott Noone
Sent: ?11/?25/?2013 12:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Conflicting statements in MSDN about IoReleaseRemoveLockAndWait

Do you have any timer DPCs in your drivers? It looks to me like someone is
calling into a WDF driver after the device has been removed. From the stack
I can't tell what either of the drivers are though (tail call optimization
obscures the caller, the framework owning the entry points obscures the
callee).

I set a breakpoint on this routine on my test system and at this point RCX
should contain a device object (RCX+40 is the DeviceExtension field, WDF is
trying to access some header before this field). !devobj @rcx or "dt
nt!_device_object @rcx' might tell you the driver, which would shed some
light on things.

-scott
OSR

wrote in message news:xxxxx@ntdev...

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:
fffff880`0203ca08 fffff800`01dc9a12 : ffffffff`ffffffd0 fffff880`0201ff40
00000000`00000065 fffff800`01d13888 : nt!RtlpBreakWithStatusInstruction
fffff880`0203ca10 fffff800`01dca7fe : 00000000`00000003 00000000`00000000
fffff800`01d140e0 00000000`000000d1 : nt!KiBugCheckDebugBreak+0x12
fffff880`0203ca70 fffff800`01cd8d04 : fffffa80`036e9e20 fffff880`00e60872
00000000`00000001 fffff800`01d550c4 : nt!KeBugCheck2+0x71e
fffff880`0203d140 fffff800`01cd81a9 : 00000000`0000000a ffffffff`ffffffd0
00000000`00000002 00000000`00000000 : nt!KeBugCheckEx+0x104
fffff880`0203d180 fffff800`01cd6e20 : 00000000`00000000 00000000`a0000003
fffff980`1f920e10 fffff980`0b642e10 : nt!KiBugCheckDispatch+0x69
fffff880`0203d2c0 fffff880`010d0862 : fffffa80`03d40370 00000000`00000002
fffffa80`0473ff40 fffff800`0217ee96 : nt!KiPageFault+0x260
fffff880`0203d450 fffff880`010d0aa6 : fffff980`0b642e10 00000000`00000002
fffffa80`03d40370 fffff880`0203dc18 : Wdf01000!FxDevice::Dispatch+0x22
fffff880`0203d490 fffff800`02182d26 : fffff980`0b642e10 00000000`00000002
fffffa80`03d40370 e83f03ff`ffe00007 :
Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff880`0203d4d0 fffff800`01ce384c : fffff880`0203d5f0 00000000`00000000
00000000`00000001 fffffa80`0473ff40 : nt!IovCallDriver+0x566
fffff880`0203d530 fffff800`01ce36e6 : fffffa80`04360748 fffffa80`04360748
00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff880`0203d5a0 fffff800`01ce35ce : 00000014`79a9100e fffff880`0203dc18
00000000`00089683 fffff880`020185e8 : nt!KiProcessExpiredTimerList+0xc6
fffff880`0203dbf0 fffff800`01ce33b7 : 0000140b`8ff202c5 0000140b`00089683
0000140b`8ff20263 00000000`00000083 : nt!KiTimerExpiration+0x1be
fffff880`0203dc90 fffff800`01cd090a : fffff880`02015180 fffff880`0201ff40
00000000`00000001 fffff800`00000000 : nt!KiRetireDpcList+0x277
fffff880`0203dd40 00000000`00000000 : fffff880`0203e000 fffff880`02038000
fffff880`0203dd00 00000000`00000000 : 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
fffff880`059aac50 fffff800`01cce612 : 00000000`00000017 fffffa80`044153c0
00000000`00000000 00000000`00000008 : nt!KiSwapContext+0x7a
fffff880`059aad90 fffff800`01cdf98f : fffffa80`02ca6001 fffffa80`040621b0
00000000`00000000 00000000`00000000 : nt!KiCommitThreadWait+0x1d2
fffff880`059aae20 fffff880`013e08fa : 00000000`00000000 00000000`00000000
fffffa80`04062000 fffffa80`04062100 : nt!KeWaitForSingleObject+0x19f
fffff880`059aaec0 fffff880`013dcb08 : fffffa80`03d40370 00000000`00000000
00000000`00000002 fffff880`013d7110 : CLASSPNP!ClassRemoveDevice+0x12a
fffff880`059aaf00 fffff800`02182d26 : fffffa80`040621b0 fffffa80`02ca6038
fffff980`1f614c60 fffff800`0217e48e : CLASSPNP! ??
::NNGAKEGL::`string'+0x17a6
fffff880`059aaf90 fffff800`021855ea : fffff980`1f614e50 fffffa80`04062060
fffffa80`044372a0 fffffa80`018fc320 : nt!IovCallDriver+0x566
fffff880`059aaff0 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
fffffa80`044372a0 fffffa80`0421a0b0 : nt!ViFilterDispatchPnp+0xea
fffff880`059ab020 fffff880`017e270c : fffff980`1f614c60 00000000`00000002
fffff980`1f614f18 fffffa80`0421a0b0 : nt!IovCallDriver+0x566
fffff880`059ab080 fffff880`017e6298 : fffffa80`02d26830 fffff980`1f614c60
fffffa80`02d26830 fffffa80`032a1410 :
DcsDf!DiskPerfForwardIrpSynchronous+0xac
fffff880`059ab110 fffff880`017e5778 : fffffa80`02d26830 fffff980`1f614c60
00000000`00000000 00000000`00000000 : DcsDf!DiskPerfRemoveDevice+0x58
fffff880`059ab150 fffff800`02182d26 : fffffa80`02d26830 fffff980`1f614c60
fffff980`1f614c60 fffff800`0217e48e : DcsDf!DiskPerfDispatchPnp+0x148
fffff880`059ab1d0 fffff800`021855ea : fffff980`1f614ee0 fffffa80`02d26830
fffffa80`042f5af0 fffffa80`032a1410 : nt!IovCallDriver+0x566
fffff880`059ab230 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
fffffa80`042f5af0 fffffa80`03212a70 : nt!ViFilterDispatchPnp+0xea
fffff880`059ab260 fffff880`014b6926 : fffff980`1f614c60 00000000`00000002
fffff980`1f614fa8 fffffa80`03212a70 : nt!IovCallDriver+0x566
fffff880`059ab2c0 fffff880`014b82c5 : fffffa80`03405060 fffff980`1f614c60
fffff880`059ab3f0 fffff880`059ab3d8 : DcsPMF!PMFForwardIrpSynchronous+0xd6
fffff880`059ab340 fffff880`014b8d78 : fffffa80`03405060 fffff980`1f614c60
00000000`00000003 00000000`00000000 : DcsPMF!PMFRemoveDevice+0x2e5
fffff880`059ab510 fffff800`02182d26 : fffffa80`03405060 fffff980`1f614c60
fffff980`1f614c60 fffff800`0217e48e : DcsPMF!PMFDispatchPnp+0x738
fffff880`059ab5d0 fffff800`021855ea : fffff980`1f614f70 fffffa80`03405060
fffffa80`03fd2700 fffffa80`043d6eb0 : nt!IovCallDriver+0x566
fffff880`059ab630 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
fffffa80`03fd2700 fffffa80`03b2a010 : nt!ViFilterDispatchPnp+0xea
fffff880`059ab660 fffff880`0108530e : fffff980`1f614c60 fffff980`1f614fb8
00000000`00000000 fffffa80`03b2a010 : nt!IovCallDriver+0x566
fffff880`059ab6c0 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
fffffa80`039c0330 00000000`c00000bb : partmgr!PmPnp+0xfe
fffff880`059ab710 fffff800`01f46d11 : fffffa80`039c0330 fffff880`059ab828
00000000`c00000bb fffffa80`03b44010 : nt!IovCallDriver+0x566
fffff880`059ab770 fffff800`020c5681 : fffffa80`04743060 00000000`00000000
fffffa80`047384a0 00000000`00000801 : nt!IopSynchronousCall+0xe1
fffff880`059ab7e0 fffff800`01ddb063 : fffff8a0`023b6f20 fffff8a0`023b6f20
00000000`00000018 00000000`00000000 : nt!IopRemoveDevice+0x101
fffff880`059ab8a0 fffff800`020c51d4 : fffffa80`047384a0 00000000`00000000
00000000`00000002 00000000`00000000 : nt!PnpRemoveLockedDeviceNode+0x1a3
fffff880`059ab8f0 fffff800`020c52e0 : 00000000`00000000 fffffa80`04743000
fffff8a0`074b8900 fffff800`01edca80 : nt!PnpDeleteLockedDeviceNode+0x44
fffff880`059ab920 fffff800`020c53d9 : fffffa80`04601602 fffffa80`04601600
00000000`00000001 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0xa0
fffff880`059ab990 fffff800`020c5551 : fffffa80`04601600 00000000`00000000
fffffa80`04601600 00000000`00010286 : nt!PnpDelayedRemoveWorker+0x79
fffff880`059ab9e0 fffff800`01ddb289 : 00000000`00000000 fffffa80`035e0a50
00000000`00000001 00000000`00000000 : nt!PnpChainDereferenceComplete+0x131
fffff880`059aba20 fffff800`02156570 : 00000000`00000000 fffffa80`04738400
fffff8a0`0398cef0 00000000`00000001 : nt!PnpIsChainDereferenced+0xc9
fffff880`059abaa0 fffff800`0215680c : fffff880`059abc78 00000000`00010200
fffff880`059abc00 00000000`00000000 : nt!PnpProcessQueryRemoveAndEject+0xff0
fffff880`059abbe0 fffff800`0203f9ae : 00000000`00000000 fffffa80`0466eb00
fffff8a0`0398cef0 fffff880`059abc00 : nt!PnpProcessTargetDeviceEvent+0x4c
fffff880`059abc10 fffff800`01ce2251 : fffff800`01f45b98 fffff8a0`0398cef0
fffff800`01e7e2d8 fffff800`01e7e2d8 : nt! ?? ::NNGAKEGL::`string'+0x552ab
fffff880`059abc70 fffff800`01f76ede : 00000000`00000000 fffffa80`044153c0
00000000`00000080 fffffa80`01876890 : nt!ExpWorkerThread+0x111
fffff880`059abd00 fffff800`01cc9906 : fffff880`02015180 fffffa80`044153c0
fffffa80`028dcb50 00000000`00000202 : nt!PspSystemThreadStartup+0x5a
fffff880`059abd40 00000000`00000000 : fffff880`059ac000 fffff880`059a6000
fffff880`059aa8a0 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
d

Comments

  • Alex_GrigAlex_Grig Member Posts: 3,238
    The remove lock is most useful for the I/O requests and other callbacks that you issue. You can't really use it to track the requests that come from the upper level drivers.

    IRP_MN_REMOVE_DEVICE only arrives when all external references on the stack are released (last IRP completed and last IRP_MJ_CLOSE completed because of that).

    You also may use the remove lock to block the internal requests and callbacks (timers, etc). After you call IoReleaseRemoveLockAndWait any new calls to IoAcquireRemoveLock will fail. Because of that, you need to make sure you call it and block your new IRPs before the lower device gets REMOVE_REVICE. With that, you need to call IoCancelIrp on all your IRPs.

    There are two approaches, depending on how you acquiesce your driver. You need to guarantee your driver is quiet (will not touch registers or issue new requests) before you forward the REMOVE_DEVICE down. You may cancel the IRPs you created and sent to the lower driver, or you may rely on the lower driver to do that on REMOVE_DEVICE (but you may not know if you can).

    IoReleaseRemoveLockAndWait helps you to keep your driver quiet, so you may want to call it before passing REMOVE down. But you have to cancel your own IRPs before calling it.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,159
    <QUOTE>
    Definitely a calm into a wdf driver after the remove irp has been processed.
    You need to wait on the remlock after sending the remove irp
    </QUOTE>

    If that's the case, wouldn't that mean you have to wait on the remove lock
    *before* sending the remove IRP? Otherwise the window is there between
    remove and wait and I/Os arriving at the device.


    -scott
    OSR


    "Doron Holan" <xxxxx@microsoft.com> wrote in message
    news:xxxxx@ntdev...
    Definitely a calm into a wdf driver after the remove irp has been processed.
    You need to wait on the remlock after sending the remove irp

    d

    Bent from my phone
    From: Scott Noone
    Sent: ý11/ý25/ý2013 12:00 PM
    To: Windows System Software Devs Interest List
    Subject: Re:[ntdev] Conflicting statements in MSDN about
    IoReleaseRemoveLockAndWait


    Do you have any timer DPCs in your drivers? It looks to me like someone is
    calling into a WDF driver after the device has been removed. From the stack
    I can't tell what either of the drivers are though (tail call optimization
    obscures the caller, the framework owning the entry points obscures the
    callee).

    I set a breakpoint on this routine on my test system and at this point RCX
    should contain a device object (RCX+40 is the DeviceExtension field, WDF is
    trying to access some header before this field). !devobj @rcx or "dt
    nt!_device_object @rcx' might tell you the driver, which would shed some
    light on things.

    -scott
    OSR

    wrote in message news:xxxxx@ntdev...

    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:
    fffff880`0203ca08 fffff800`01dc9a12 : ffffffff`ffffffd0 fffff880`0201ff40
    00000000`00000065 fffff800`01d13888 : nt!RtlpBreakWithStatusInstruction
    fffff880`0203ca10 fffff800`01dca7fe : 00000000`00000003 00000000`00000000
    fffff800`01d140e0 00000000`000000d1 : nt!KiBugCheckDebugBreak+0x12
    fffff880`0203ca70 fffff800`01cd8d04 : fffffa80`036e9e20 fffff880`00e60872
    00000000`00000001 fffff800`01d550c4 : nt!KeBugCheck2+0x71e
    fffff880`0203d140 fffff800`01cd81a9 : 00000000`0000000a ffffffff`ffffffd0
    00000000`00000002 00000000`00000000 : nt!KeBugCheckEx+0x104
    fffff880`0203d180 fffff800`01cd6e20 : 00000000`00000000 00000000`a0000003
    fffff980`1f920e10 fffff980`0b642e10 : nt!KiBugCheckDispatch+0x69
    fffff880`0203d2c0 fffff880`010d0862 : fffffa80`03d40370 00000000`00000002
    fffffa80`0473ff40 fffff800`0217ee96 : nt!KiPageFault+0x260
    fffff880`0203d450 fffff880`010d0aa6 : fffff980`0b642e10 00000000`00000002
    fffffa80`03d40370 fffff880`0203dc18 : Wdf01000!FxDevice::Dispatch+0x22
    fffff880`0203d490 fffff800`02182d26 : fffff980`0b642e10 00000000`00000002
    fffffa80`03d40370 e83f03ff`ffe00007 :
    Wdf01000!FxDevice::DispatchWithLock+0xa6
    fffff880`0203d4d0 fffff800`01ce384c : fffff880`0203d5f0 00000000`00000000
    00000000`00000001 fffffa80`0473ff40 : nt!IovCallDriver+0x566
    fffff880`0203d530 fffff800`01ce36e6 : fffffa80`04360748 fffffa80`04360748
    00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
    fffff880`0203d5a0 fffff800`01ce35ce : 00000014`79a9100e fffff880`0203dc18
    00000000`00089683 fffff880`020185e8 : nt!KiProcessExpiredTimerList+0xc6
    fffff880`0203dbf0 fffff800`01ce33b7 : 0000140b`8ff202c5 0000140b`00089683
    0000140b`8ff20263 00000000`00000083 : nt!KiTimerExpiration+0x1be
    fffff880`0203dc90 fffff800`01cd090a : fffff880`02015180 fffff880`0201ff40
    00000000`00000001 fffff800`00000000 : nt!KiRetireDpcList+0x277
    fffff880`0203dd40 00000000`00000000 : fffff880`0203e000 fffff880`02038000
    fffff880`0203dd00 00000000`00000000 : 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
    fffff880`059aac50 fffff800`01cce612 : 00000000`00000017 fffffa80`044153c0
    00000000`00000000 00000000`00000008 : nt!KiSwapContext+0x7a
    fffff880`059aad90 fffff800`01cdf98f : fffffa80`02ca6001 fffffa80`040621b0
    00000000`00000000 00000000`00000000 : nt!KiCommitThreadWait+0x1d2
    fffff880`059aae20 fffff880`013e08fa : 00000000`00000000 00000000`00000000
    fffffa80`04062000 fffffa80`04062100 : nt!KeWaitForSingleObject+0x19f
    fffff880`059aaec0 fffff880`013dcb08 : fffffa80`03d40370 00000000`00000000
    00000000`00000002 fffff880`013d7110 : CLASSPNP!ClassRemoveDevice+0x12a
    fffff880`059aaf00 fffff800`02182d26 : fffffa80`040621b0 fffffa80`02ca6038
    fffff980`1f614c60 fffff800`0217e48e : CLASSPNP! ??
    ::NNGAKEGL::`string'+0x17a6
    fffff880`059aaf90 fffff800`021855ea : fffff980`1f614e50 fffffa80`04062060
    fffffa80`044372a0 fffffa80`018fc320 : nt!IovCallDriver+0x566
    fffff880`059aaff0 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
    fffffa80`044372a0 fffffa80`0421a0b0 : nt!ViFilterDispatchPnp+0xea
    fffff880`059ab020 fffff880`017e270c : fffff980`1f614c60 00000000`00000002
    fffff980`1f614f18 fffffa80`0421a0b0 : nt!IovCallDriver+0x566
    fffff880`059ab080 fffff880`017e6298 : fffffa80`02d26830 fffff980`1f614c60
    fffffa80`02d26830 fffffa80`032a1410 :
    DcsDf!DiskPerfForwardIrpSynchronous+0xac
    fffff880`059ab110 fffff880`017e5778 : fffffa80`02d26830 fffff980`1f614c60
    00000000`00000000 00000000`00000000 : DcsDf!DiskPerfRemoveDevice+0x58
    fffff880`059ab150 fffff800`02182d26 : fffffa80`02d26830 fffff980`1f614c60
    fffff980`1f614c60 fffff800`0217e48e : DcsDf!DiskPerfDispatchPnp+0x148
    fffff880`059ab1d0 fffff800`021855ea : fffff980`1f614ee0 fffffa80`02d26830
    fffffa80`042f5af0 fffffa80`032a1410 : nt!IovCallDriver+0x566
    fffff880`059ab230 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
    fffffa80`042f5af0 fffffa80`03212a70 : nt!ViFilterDispatchPnp+0xea
    fffff880`059ab260 fffff880`014b6926 : fffff980`1f614c60 00000000`00000002
    fffff980`1f614fa8 fffffa80`03212a70 : nt!IovCallDriver+0x566
    fffff880`059ab2c0 fffff880`014b82c5 : fffffa80`03405060 fffff980`1f614c60
    fffff880`059ab3f0 fffff880`059ab3d8 : DcsPMF!PMFForwardIrpSynchronous+0xd6
    fffff880`059ab340 fffff880`014b8d78 : fffffa80`03405060 fffff980`1f614c60
    00000000`00000003 00000000`00000000 : DcsPMF!PMFRemoveDevice+0x2e5
    fffff880`059ab510 fffff800`02182d26 : fffffa80`03405060 fffff980`1f614c60
    fffff980`1f614c60 fffff800`0217e48e : DcsPMF!PMFDispatchPnp+0x738
    fffff880`059ab5d0 fffff800`021855ea : fffff980`1f614f70 fffffa80`03405060
    fffffa80`03fd2700 fffffa80`043d6eb0 : nt!IovCallDriver+0x566
    fffff880`059ab630 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
    fffffa80`03fd2700 fffffa80`03b2a010 : nt!ViFilterDispatchPnp+0xea
    fffff880`059ab660 fffff880`0108530e : fffff980`1f614c60 fffff980`1f614fb8
    00000000`00000000 fffffa80`03b2a010 : nt!IovCallDriver+0x566
    fffff880`059ab6c0 fffff800`02182d26 : fffff980`1f614c60 00000000`00000002
    fffffa80`039c0330 00000000`c00000bb : partmgr!PmPnp+0xfe
    fffff880`059ab710 fffff800`01f46d11 : fffffa80`039c0330 fffff880`059ab828
    00000000`c00000bb fffffa80`03b44010 : nt!IovCallDriver+0x566
    fffff880`059ab770 fffff800`020c5681 : fffffa80`04743060 00000000`00000000
    fffffa80`047384a0 00000000`00000801 : nt!IopSynchronousCall+0xe1
    fffff880`059ab7e0 fffff800`01ddb063 : fffff8a0`023b6f20 fffff8a0`023b6f20
    00000000`00000018 00000000`00000000 : nt!IopRemoveDevice+0x101
    fffff880`059ab8a0 fffff800`020c51d4 : fffffa80`047384a0 00000000`00000000
    00000000`00000002 00000000`00000000 : nt!PnpRemoveLockedDeviceNode+0x1a3
    fffff880`059ab8f0 fffff800`020c52e0 : 00000000`00000000 fffffa80`04743000
    fffff8a0`074b8900 fffff800`01edca80 : nt!PnpDeleteLockedDeviceNode+0x44
    fffff880`059ab920 fffff800`020c53d9 : fffffa80`04601602 fffffa80`04601600
    00000000`00000001 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0xa0
    fffff880`059ab990 fffff800`020c5551 : fffffa80`04601600 00000000`00000000
    fffffa80`04601600 00000000`00010286 : nt!PnpDelayedRemoveWorker+0x79
    fffff880`059ab9e0 fffff800`01ddb289 : 00000000`00000000 fffffa80`035e0a50
    00000000`00000001 00000000`00000000 : nt!PnpChainDereferenceComplete+0x131
    fffff880`059aba20 fffff800`02156570 : 00000000`00000000 fffffa80`04738400
    fffff8a0`0398cef0 00000000`00000001 : nt!PnpIsChainDereferenced+0xc9
    fffff880`059abaa0 fffff800`0215680c : fffff880`059abc78 00000000`00010200
    fffff880`059abc00 00000000`00000000 : nt!PnpProcessQueryRemoveAndEject+0xff0
    fffff880`059abbe0 fffff800`0203f9ae : 00000000`00000000 fffffa80`0466eb00
    fffff8a0`0398cef0 fffff880`059abc00 : nt!PnpProcessTargetDeviceEvent+0x4c
    fffff880`059abc10 fffff800`01ce2251 : fffff800`01f45b98 fffff8a0`0398cef0
    fffff800`01e7e2d8 fffff800`01e7e2d8 : nt! ?? ::NNGAKEGL::`string'+0x552ab
    fffff880`059abc70 fffff800`01f76ede : 00000000`00000000 fffffa80`044153c0
    00000000`00000080 fffffa80`01876890 : nt!ExpWorkerThread+0x111
    fffff880`059abd00 fffff800`01cc9906 : fffff880`02015180 fffffa80`044153c0
    fffffa80`028dcb50 00000000`00000202 : nt!PspSystemThreadStartup+0x5a
    fffff880`059abd40 00000000`00000000 : fffff880`059ac000 fffff880`059a6000
    fffff880`059aa8a0 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

    -scott
    OSR

  • Thierry_LaurentThierry_Laurent Member Posts: 7
    Scott: this is the state of the device and driver object at the time of the BSOD.

    Thank you.
    Thierry

    1: kd> !devobj @rcx
    Device object (fffffa8003d40370) is for:
    \Driver\storflt DriverObject fffffa8002c97e70
    Current Irp 00000000 RefCount 0 Type 0000002d Flags 00000010
    DevExt 00000000 DevObjExt fffffa8003d404e8
    ExtensionFlags (0x9400080a) DOE_DELETE_PENDING, DOE_REMOVE_PROCESSED,
    DOE_DESIGNATED_FDO
    Unknown flags 0x14000800
    AttachedDevice (Upper) fffffa8004062060 \Driver\Disk
    Device queue is not busy.

    1: kd> dt nt!_device_object @rcx
    +0x000 Type : 0n3
    +0x002 Size : 0x178
    +0x004 ReferenceCount : 0n0
    +0x008 DriverObject : 0xfffffa80`02c97e70 _DRIVER_OBJECT
    +0x010 NextDevice : 0xfffffa80`04014040 _DEVICE_OBJECT
    +0x018 AttachedDevice : 0xfffffa80`04062060 _DEVICE_OBJECT
    +0x020 CurrentIrp : (null)
    +0x028 Timer : (null)
    +0x030 Flags : 0x10
    +0x034 Characteristics : 0x180
    +0x038 Vpb : (null)
    +0x040 DeviceExtension : (null)
    +0x048 DeviceType : 0x2d
    +0x04c StackSize : 3 ''
    +0x050 Queue : <unnamed-tag>
    +0x098 AlignmentRequirement : 3
    +0x0a0 DeviceQueue : _KDEVICE_QUEUE
    +0x0c8 Dpc : _KDPC
    +0x108 ActiveThreadCount : 0
    +0x110 SecurityDescriptor : (null)
    +0x118 DeviceLock : _KEVENT
    +0x130 SectorSize : 0
    +0x132 Spare1 : 1
    +0x138 DeviceObjectExtension : 0xfffffa80`03d404e8 _DEVOBJ_EXTENSION
    +0x140 Reserved : (null)

    1: kd> dt nt!_driver_object 0xfffffa80`02c97e70
    +0x000 Type : 0n4
    +0x002 Size : 0n336
    +0x008 DeviceObject : 0xfffffa80`03d40370 _DEVICE_OBJECT
    +0x010 Flags : 0x12
    +0x018 DriverStart : 0xfffff880`01800000 Void
    +0x020 DriverSize : 0x10000
    +0x028 DriverSection : 0xfffffa80`0186f3d0 Void
    +0x030 DriverExtension : 0xfffffa80`02c97fc0 _DRIVER_EXTENSION
    +0x038 DriverName : _UNICODE_STRING "\Driver\storflt"
    +0x048 HardwareDatabase : 0xfffff800`021a5558 _UNICODE_STRING "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM"
    +0x050 FastIoDispatch : (null)
    +0x058 DriverInit : 0xfffff880`018020a4 long vmstorfl!FxDriverEntry+0
    +0x060 DriverStartIo : (null)
    +0x068 DriverUnload : 0xfffff880`01802074 void vmstorfl!FxStubDriverUnload+0
    +0x070 MajorFunction : [28] 0xfffff880`010d0a00 long Wdf01000!FxDevice::DispatchWithLock+0
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE