Is this the expected behaviour? Is it possible to avoid this?

Praveen_Kumar_Amritaluru · November 22, 2006, 8:03am

Hi Doron,

I have some requests pending in my KMDF bd.
As a result when IRP_MN_QUERY_REMOVE callback fn gets executed, I return STATUS_UNSUCCESSFUL
as can be seen from the log below.

This results in framework cancelling the request. This same request for querying happens twice.
But once the operation completes, a window pops up:

“To finish removing your hardware, you must restart your computer.
Do you want to restart your computer now?”

Is this expected behaviour even on WDM driver? I dont get why this results in a suggsetion to restart the computer?
How about genuine cases when there is some operation being done by the driver/device and as a result query_remove is
not allowed…
What if user goes ahead and restarts w/o knowing that there is some operation being carried out?

I think this behaviour is not KMDF specific.

Thanks,
-Praveen

kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 100
There are 65 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE 76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingChild from WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0BusWakeOwner from WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove

Praveen_Kumar_Amritaluru · November 22, 2006, 8:08am

The child-device created by BD is a network device. When I choose not to restart the computer,
the network device disappears in “network wizard connections”, though device manager displays them.

Device Manager mentions that:

“Device is working properly.The drivers will be uninstalled when this machine is restarted. Any changes you make will not be preserved”.

Is this behaviour expected one when remove is not allowed by driver/cancelled by framework as a result?

Regds,
-Praveen

“Praveen Kumar Amritaluru” wrote in message news:xxxxx@ntdev…
Hi Doron,

I have some requests pending in my KMDF bd.
As a result when IRP_MN_QUERY_REMOVE callback fn gets executed, I return STATUS_UNSUCCESSFUL
as can be seen from the log below.

This results in framework cancelling the request. This same request for querying happens twice.
But once the operation completes, a window pops up:

“To finish removing your hardware, you must restart your computer.
Do you want to restart your computer now?”

Is this expected behaviour even on WDM driver? I dont get why this results in a suggsetion to restart the computer?
How about genuine cases when there is some operation being done by the driver/device and as a result query_remove is
not allowed…
What if user goes ahead and restarts w/o knowing that there is some operation being carried out?

I think this behaviour is not KMDF specific.

Thanks,
-Praveen

kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 100
There are 65 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE 76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingChild from WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0BusWakeOwner from WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove

Praveen_Kumar_Amritaluru · November 22, 2006, 8:25am

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg that appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some IRPs and processing them resulting in remove getting cancelled by framework automatically.

From the log it can be seen that when I choose to restart the computer, the framework is not calling EvtIoStop and giving me a chance to clear up (either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for removing the device… This can be seen from the log. No other evtcallback fn is getting executed
when system is restarted. Looks like framework has state machine wherein it sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the framework/PnP manager does incase of device removal (once QUERY_REMOVE succeeds).

This whole thing does not look like an expected behaviour… or something driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00 (2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00 (2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE 0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00 (2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00 (2) status c00000bb
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine’s keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the “g” key, then *
* press the “Enter” key now. This message might immediately reappear. If it *
* does, press “g” and “Enter” again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0

Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE 76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingChild from WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0BusWakeOwner from WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolSleeping from WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

Jake_Oshins · November 22, 2006, 4:00pm

You seem to be posting in real time as things occur to you, so I’m tempted
to wait for the next installment.

To answer your first question, IRP_MN_QUERY_REMOVE is sent to a driver when
the system needs to tear down the driver stack on a device. If you fail it,
then the only way to rebuild the driver stack is to reboot the machine.
That’s why you get the prompt.

In general, this is really bad user experience. You should find a way to
avoid failing this action.

Jake Oshins

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
Hi,

Here is what happens, if I choose to restart option in the pop-up mesg
that appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer, the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something
driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)

You are seeing this message because you pressed either

CTRL+C (if you run kd.exe) or,

CTRL+BREAK (if you run WinDBG),

on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key, then

press the “Enter” key now. This message might immediately reappear. If
it
does, press “g” and “Enter” again.

**********************
nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by
WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

Doron_Holan · November 24, 2006, 12:06am

I am having a little bit of hard time understanding what is going on here. Are you saying that you don’t get an EvtIoStop for each irp when you shutdown the machine? If so, the pnp state machine is not the place to look (since you don’t get a remove on shutdown), it would be the power state machine instead. KMDF will call EvtIoStop on each inflight power managed WDFREQUEST on shutdown (it is like an other S state transition). Is the bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to avoid this?

Hi,
?
?Here is? what happens, if I choose to restart option in the pop-up mesg that appeared
?when? “QUERY_REMOVE” was failed by my driver since it was holding some IRPs and processing them resulting in?remove getting?cancelled by framework automatically.
?
?From the log it can be seen that when I?choose to restart the computer, the framework?is not calling EvtIoStop and giving me a chance to clear up (either cancel/complete)
?the IRPs.? This is resulting in the?BSOD.
?
?Infact driver is not being given any chance to do cleanup work for removing the device… This can be seen from the log. No other evtcallback fn is getting executed
?when system is restarted. Looks like framework has state machine wherein it sees that state transition that happened is:
?
“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”
?
?And so it just goes ahead sends PowerIRPs w/o performing all jobs the framework/PnP manager does incase of device removal (once QUERY_REMOVE succeeds).
?
?
?This whole thing does not look like an expected behaviour… or something driver cannot manage/prevent BSOD.
?
?Please clarify.
?
Regards,
-Praveen
?
?
?
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00 (2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00 (2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE 0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00 (2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00 (2) status c00000bb
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
???
?? You are seeing this message because you pressed either???
??? CTRL+C (if you run kd.exe) or,???
??? CTRL+BREAK (if you run WinDBG),???
?? on your debugger machine’s keyboard.???
???
??? THIS IS NOT A BUG OR A SYSTEM CRASH???
???
* If you did not intend to break into the debugger, press the “g” key, then?? *
* press the “Enter” key now.? This message might immediately reappear.? If it *
* does, press “g” and “Enter” again.??? *
???
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
818726d0 cc??? int??? 3
kd> !WDFQUEUE 0x7B7C6CA0
?
Dumping WDFQUEUE 0x7b7c6ca0

Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
??? Number of driver owned requests: 2
??? Power transition in progress
??? Number of waiting requests: 0
?
??? Number of requests notified about power change: 2
??? !WDFREQUEST 0x75820fb0? !IRP 0x94448f20
??? !WDFREQUEST 0x7584d5f8? !IRP 0x94438f20
?
??? EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:
?
Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE 76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingChild from WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0BusWakeOwner from WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 IRP_MJ_POWER, Minor 0x2? IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 IRP_MJ_POWER, Minor 0x2? IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolSleeping from WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 IRP_MJ_POWER, Minor 0x2? IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

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

Doron_Holan · November 24, 2006, 12:11am

To clarify, you have a bus driver. It enumerates a child stack. You query remove the parent stack (which fails) and then the child stack (which is a NIC of some kind) disappears from the network connections UI (and is still running)?

What OS is this on?

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar Amritaluru
Sent: Wednesday, November 22, 2006 5:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to avoid this?

The child-device created by BD is a network device. When I choose not to restart the computer,
?the network device disappears in “network wizard connections”, though device manager displays them.
?
Device Manager mentions that:
?
“Device is working properly.The drivers will be uninstalled when this machine is restarted. Any changes you make will not be preserved”.
?
Is this behaviour expected one when remove is not allowed by driver/cancelled by framework as a result?
?
Regds,
-Praveen
?
?
“Praveen Kumar Amritaluru” wrote in message news:xxxxx@ntdev…
Hi Doron,
?
? I have some requests pending in my KMDF bd.
?As a result when IRP_MN_QUERY_REMOVE callback fn gets executed, I return STATUS_UNSUCCESSFUL
?as can be seen from the log below.
?
?This results in framework cancelling the request. This same request for querying happens twice.
?But once the operation completes, a window pops up:
?
?“To finish removing your hardware, you must restart your computer.
? Do you want to restart your computer now?”
?
?
?Is this expected behaviour even on WDM driver?? I dont get why this results in a suggsetion to restart the computer?
?How about genuine cases when there is some operation being done by the driver/device and as a result query_remove is
?not allowed…
?What if user goes ahead and restarts w/o knowing that there is some operation being carried out?
?
?I think this behaviour is not KMDF specific.
?
Thanks,
-Praveen
?
?
?
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:
?
Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is: C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 100
There are 65 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE 76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerStartingChild from WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering Power State WdfDevStatePowerD0BusWakeOwner from WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpQueryRemoveAskDriver from WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed, 0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8, IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStartedCancelRemove from WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 8:54am

Yes, this is on Vista - either build 5744(RC)/6000 (RTM).
I dont recollect whether the NIC was functioning.

The bug was in driver code and it was fixed. But I still have questions
which are unanswered about the behaviour when
QueryRemove fails or other possibly error condition.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
To clarify, you have a bus driver. It enumerates a child stack. You query
remove the parent stack (which fails) and then the child stack (which is a
NIC of some kind) disappears from the network connections UI (and is still
running)?

What OS is this on?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to avoid
this?

The child-device created by BD is a network device. When I choose not to
restart the computer,
the network device disappears in “network wizard connections”, though device
manager displays them.

Device Manager mentions that:

“Device is working properly.The drivers will be uninstalled when this
machine is restarted. Any changes you make will not be preserved”.

Is this behaviour expected one when remove is not allowed by
driver/cancelled by framework as a result?

Regds,
-Praveen

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
Hi Doron,

I have some requests pending in my KMDF bd.
As a result when IRP_MN_QUERY_REMOVE callback fn gets executed, I return
STATUS_UNSUCCESSFUL
as can be seen from the log below.

This results in framework cancelling the request. This same request for
querying happens twice.
But once the operation completes, a window pops up:

“To finish removing your hardware, you must restart your computer.
Do you want to restart your computer now?”

Is this expected behaviour even on WDM driver? I dont get why this results
in a suggsetion to restart the computer?
How about genuine cases when there is some operation being done by the
driver/device and as a result query_remove is
not allowed…
What if user goes ahead and restarts w/o knowing that there is some
operation being carried out?

I think this behaviour is not KMDF specific.

Thanks,
-Praveen

kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 100
There are 65 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by
WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 9:07am

The bugcheck is the one that occurs when I select to restart the machine
when the pop-up appears.

This is what I think is happening:

I try to disable the BD.
QueryRemove of FD is called.
Remove Device of FD is called. Goes through fine.
EvtIoStop() registered for BD gets called for pending IRPs. But BD does
not complete/cancel/acknowled these IRPs due to a bug in driver.
QueryRemove of BD is called. It returns failure.
Remove operation is cancelled.
Pnp Manager/IO Manager reinstalls FD when BD Query remove fails.
It then pops up a message asking for restart of computer.
I select the “OK” option.
But this time, though BD has not yet completed the IRPs yet, EvtIoStop
is not called now. Does framework assume in setp #4, that it should not call
EvtIostop next time power transition happens?
Neither is QueryRemove of BD is called.

I dont remember the exact sequeunce of steps 2-5.

While restarting, some time has passed. ITs very much possible that BD has
completed operation for which it was holding the IRPs and this time
PDEvtIoSto()
would go through properly and complete/cancle the pending IRPs.
But they are not getting called?

Thanks for clarifiction on
QUOTE
on shutdown (it is like an other S state transition).
UNQUOTE.
I understand now why QueryRemove is not getting called.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I am having a little bit of hard time understanding what is going on here.
Are you saying that you don’t get an EvtIoStop for each irp when you
shutdown the machine? If so, the pnp state machine is not the place to look
(since you don’t get a remove on shutdown), it would be the power state
machine instead. KMDF will call EvtIoStop on each inflight power managed
WDFREQUEST on shutdown (it is like an other S state transition). Is the
bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to avoid
this?

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg that
appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer, the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something
driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828 IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)

You are seeing this message because you pressed either
CTRL+C (if you run kd.exe) or,
CTRL+BREAK (if you run WinDBG),
on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key, then

press the “Enter” key now. This message might immediately reappear. If it

does, press “g” and “Enter” again.

****
nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828, IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by
WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully, WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

—
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

Doron_Holan · November 27, 2006, 10:40am

Is BD the parent and FD a child stack? Query remove does not work the
way you describe below. The entire device tree will see a query remove
(and must succeed it) before anyone sees a remove. The query remove is
sent to the leaf nodes first and then works its way up to the ancestor
root of the tree you want to remove.

Step 7 does not work this by reinstalling stacks. If the q.r. fails, no
stack is torn down.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 6:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

The bugcheck is the one that occurs when I select to restart the machine

when the pop-up appears.

This is what I think is happening:

I try to disable the BD.
QueryRemove of FD is called.
Remove Device of FD is called. Goes through fine.
EvtIoStop() registered for BD gets called for pending IRPs. But BD
does
not complete/cancel/acknowled these IRPs due to a bug in driver.
QueryRemove of BD is called. It returns failure.
Remove operation is cancelled.
Pnp Manager/IO Manager reinstalls FD when BD Query remove fails.
It then pops up a message asking for restart of computer.
I select the “OK” option.
But this time, though BD has not yet completed the IRPs yet,
EvtIoStop
is not called now. Does framework assume in setp #4, that it should not
call
EvtIostop next time power transition happens?
Neither is QueryRemove of BD is called.

I dont remember the exact sequeunce of steps 2-5.

While restarting, some time has passed. ITs very much possible that BD
has
completed operation for which it was holding the IRPs and this time
PDEvtIoSto()
would go through properly and complete/cancle the pending IRPs.
But they are not getting called?

Thanks for clarifiction on
QUOTE
on shutdown (it is like an other S state transition).
UNQUOTE.
I understand now why QueryRemove is not getting called.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I am having a little bit of hard time understanding what is going on
here.
Are you saying that you don’t get an EvtIoStop for each irp when you
shutdown the machine? If so, the pnp state machine is not the place to
look
(since you don’t get a remove on shutdown), it would be the power state
machine instead. KMDF will call EvtIoStop on each inflight power
managed
WDFREQUEST on shutdown (it is like an other S state transition). Is the

bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid
this?

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg
that
appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some
IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer,
the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for
removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein
it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something

driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)
************************************************************

You are seeing this message because you pressed either
CTRL+C (if you run kd.exe) or,
CTRL+BREAK (if you run WinDBG),
on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key,
then

press the “Enter” key now. This message might immediately reappear. If
it

does, press “g” and “Enter” again.
*
*****************************************************************

nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828,
IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by

WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj

0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from
FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0 from
WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully,
WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string
for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 12:07pm

> Is BD is parent and FD a child stack.
Yes.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

Probably its right that q.r is being failed by child itself. I dont
recollect the sequence.
But still dont understand why EvtIoStop should not be called, when q…r
fails.
For eg, if the system goes to sleep state w/o any remove operation performed
on the device (ie. query remove was never called on child/parent),
is it not true that EvtIoStop gets called in this case.
If its true, why should not EvtIoStop it when I do restart of system after a
q.r failure happens. It atleast gives a chance for Parent to clean up (its
IRPs in my case).

Is EvtIoStop in anyway translates to IR_MN_STOP_DEVICE handler routine on
kmdf/wdm? Still REMOVE operation cannot be equated to STOP operation?

Looks like I am missing something here or else I am not making my question
clear?

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Is BD the parent and FD a child stack? Query remove does not work the
way you describe below. The entire device tree will see a query remove
(and must succeed it) before anyone sees a remove. The query remove is
sent to the leaf nodes first and then works its way up to the ancestor
root of the tree you want to remove.

Step 7 does not work this by reinstalling stacks. If the q.r. fails, no
stack is torn down.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 6:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

The bugcheck is the one that occurs when I select to restart the machine

when the pop-up appears.

This is what I think is happening:
1. I try to disable the BD.
2. QueryRemove of FD is called.
3. Remove Device of FD is called. Goes through fine.
4. EvtIoStop() registered for BD gets called for pending IRPs. But BD
does
not complete/cancel/acknowled these IRPs due to a bug in driver.
5. QueryRemove of BD is called. It returns failure.
6. Remove operation is cancelled.
7. Pnp Manager/IO Manager reinstalls FD when BD Query remove fails.
8. It then pops up a message asking for restart of computer.
9. I select the “OK” option.
10. But this time, though BD has not yet completed the IRPs yet,
EvtIoStop
is not called now. Does framework assume in setp #4, that it should not
call
EvtIostop next time power transition happens?
11. Neither is QueryRemove of BD is called.

I dont remember the exact sequeunce of steps 2-5.

While restarting, some time has passed. ITs very much possible that BD
has
completed operation for which it was holding the IRPs and this time
PDEvtIoSto()
would go through properly and complete/cancle the pending IRPs.
But they are not getting called?

Thanks for clarifiction on
QUOTE
on shutdown (it is like an other S state transition).
UNQUOTE.
I understand now why QueryRemove is not getting called.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I am having a little bit of hard time understanding what is going on
here.
Are you saying that you don’t get an EvtIoStop for each irp when you
shutdown the machine? If so, the pnp state machine is not the place to
look
(since you don’t get a remove on shutdown), it would be the power state
machine instead. KMDF will call EvtIoStop on each inflight power
managed
WDFREQUEST on shutdown (it is like an other S state transition). Is the

bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid
this?

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg
that
appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some
IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer,
the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for
removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein
it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something

driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)
************************************************************

You are seeing this message because you pressed either
CTRL+C (if you run kd.exe) or,
CTRL+BREAK (if you run WinDBG),
on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key,
then

press the “Enter” key now. This message might immediately reappear. If
it

does, press “g” and “Enter” again.
*
*****************************************************************

nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828,
IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by

WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj

0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from
FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0 from
WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully,
WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string
for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

—
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

Doron_Holan · November 27, 2006, 12:20pm

EvtIoStop will not be called if someone lower in the device tree fails
q.r. If someone fails q.r., the remaining part of the tree that had not
seen a q.r. will not see one. EvtIoStop will not be called in the q.r.
path at all to begin with though; EvtIoStop is called during the remove
processing if there was a successful query remove. EvtIoStop will be
called in the IRP_MN_STOP_DEVICE path as well (it is called whenever we
power down the device, be it for pnp irps or power irps), but that
should not be relevant.

Are you saying that EvtIoStop is not being called after a failed q.r. on
your PDO or your FDO?

I am still a bit unclear what the problem is.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 9:07 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

Is BD is parent and FD a child stack.
Yes.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

Probably its right that q.r is being failed by child itself. I dont
recollect the sequence.
But still dont understand why EvtIoStop should not be called, when q…r
fails.
For eg, if the system goes to sleep state w/o any remove operation
performed
on the device (ie. query remove was never called on child/parent),
is it not true that EvtIoStop gets called in this case.
If its true, why should not EvtIoStop it when I do restart of system
after a
q.r failure happens. It atleast gives a chance for Parent to clean up
(its
IRPs in my case).

Is EvtIoStop in anyway translates to IR_MN_STOP_DEVICE handler routine
on
kmdf/wdm? Still REMOVE operation cannot be equated to STOP operation?

Looks like I am missing something here or else I am not making my
question
clear?

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Is BD the parent and FD a child stack? Query remove does not work the
way you describe below. The entire device tree will see a query remove
(and must succeed it) before anyone sees a remove. The query remove is
sent to the leaf nodes first and then works its way up to the ancestor
root of the tree you want to remove.

Step 7 does not work this by reinstalling stacks. If the q.r. fails, no
stack is torn down.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 6:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

The bugcheck is the one that occurs when I select to restart the machine

when the pop-up appears.

This is what I think is happening:
1. I try to disable the BD.
2. QueryRemove of FD is called.
3. Remove Device of FD is called. Goes through fine.
4. EvtIoStop() registered for BD gets called for pending IRPs. But BD
does
not complete/cancel/acknowled these IRPs due to a bug in driver.
5. QueryRemove of BD is called. It returns failure.
6. Remove operation is cancelled.
7. Pnp Manager/IO Manager reinstalls FD when BD Query remove fails.
8. It then pops up a message asking for restart of computer.
9. I select the “OK” option.
10. But this time, though BD has not yet completed the IRPs yet,
EvtIoStop
is not called now. Does framework assume in setp #4, that it should not
call
EvtIostop next time power transition happens?
11. Neither is QueryRemove of BD is called.

I dont remember the exact sequeunce of steps 2-5.

While restarting, some time has passed. ITs very much possible that BD
has
completed operation for which it was holding the IRPs and this time
PDEvtIoSto()
would go through properly and complete/cancle the pending IRPs.
But they are not getting called?

Thanks for clarifiction on
QUOTE
on shutdown (it is like an other S state transition).
UNQUOTE.
I understand now why QueryRemove is not getting called.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I am having a little bit of hard time understanding what is going on
here.
Are you saying that you don’t get an EvtIoStop for each irp when you
shutdown the machine? If so, the pnp state machine is not the place to
look
(since you don’t get a remove on shutdown), it would be the power state
machine instead. KMDF will call EvtIoStop on each inflight power
managed
WDFREQUEST on shutdown (it is like an other S state transition). Is the

bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid
this?

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg
that
appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some
IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer,
the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for
removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein
it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something

driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)
************************************************************

You are seeing this message because you pressed either
CTRL+C (if you run kd.exe) or,
CTRL+BREAK (if you run WinDBG),
on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key,
then

press the “Enter” key now. This message might immediately reappear. If
it

does, press “g” and “Enter” again.
*
*****************************************************************

nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828,
IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by

WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj

0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from
FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0 from
WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully,
WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string
for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

—
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

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 12:48pm

Doron,

I understand the point where EvtIoStop not getting called when q.r fails.
ie. remove/disable operation ends when q.r fails.

But i am talking about a case where I am trying to restart a system after
disable operation failed. When disable operation failed, ie. cancel
operation failed,
the device is supposed to be functional.

Now, when restart happens, device is going to be powered down. ie. system
and as well device (restart - no need to wakeup system unlike sleep) are
going to low-powered state.
In the normal case (when q.r did not fail), FDO of BD would have seen
EvtIoStop getting called.
In this case it was not getting called?

*** Why? Is this expected? How would driver perform things it had
scheduled to do in EvtIoStop** is my question?

Regards,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
EvtIoStop will not be called if someone lower in the device tree fails
q.r. If someone fails q.r., the remaining part of the tree that had not
seen a q.r. will not see one. EvtIoStop will not be called in the q.r.
path at all to begin with though; EvtIoStop is called during the remove
processing if there was a successful query remove. EvtIoStop will be
called in the IRP_MN_STOP_DEVICE path as well (it is called whenever we
power down the device, be it for pnp irps or power irps), but that
should not be relevant.

Are you saying that EvtIoStop is not being called after a failed q.r. on
your PDO or your FDO?

I am still a bit unclear what the problem is.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 9:07 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

> Is BD is parent and FD a child stack.
Yes.

>Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

Probably its right that q.r is being failed by child itself. I dont
recollect the sequence.
But still dont understand why EvtIoStop should not be called, when q…r
fails.
For eg, if the system goes to sleep state w/o any remove operation
performed
on the device (ie. query remove was never called on child/parent),
is it not true that EvtIoStop gets called in this case.
If its true, why should not EvtIoStop it when I do restart of system
after a
q.r failure happens. It atleast gives a chance for Parent to clean up
(its
IRPs in my case).

Is EvtIoStop in anyway translates to IR_MN_STOP_DEVICE handler routine
on
kmdf/wdm? Still REMOVE operation cannot be equated to STOP operation?

Looks like I am missing something here or else I am not making my
question
clear?

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Is BD the parent and FD a child stack? Query remove does not work the
way you describe below. The entire device tree will see a query remove
(and must succeed it) before anyone sees a remove. The query remove is
sent to the leaf nodes first and then works its way up to the ancestor
root of the tree you want to remove.

Step 7 does not work this by reinstalling stacks. If the q.r. fails, no
stack is torn down.

Step 10 … I think that the child stack is failing q.r. which is why
the parent is not seeing a q.r. If this assumption is correct, this is
why you are not seeing EvtIoStop being called on the parent.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 6:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

The bugcheck is the one that occurs when I select to restart the machine

when the pop-up appears.

This is what I think is happening:
1. I try to disable the BD.
2. QueryRemove of FD is called.
3. Remove Device of FD is called. Goes through fine.
4. EvtIoStop() registered for BD gets called for pending IRPs. But BD
does
not complete/cancel/acknowled these IRPs due to a bug in driver.
5. QueryRemove of BD is called. It returns failure.
6. Remove operation is cancelled.
7. Pnp Manager/IO Manager reinstalls FD when BD Query remove fails.
8. It then pops up a message asking for restart of computer.
9. I select the “OK” option.
10. But this time, though BD has not yet completed the IRPs yet,
EvtIoStop
is not called now. Does framework assume in setp #4, that it should not
call
EvtIostop next time power transition happens?
11. Neither is QueryRemove of BD is called.

I dont remember the exact sequeunce of steps 2-5.

While restarting, some time has passed. ITs very much possible that BD
has
completed operation for which it was holding the IRPs and this time
PDEvtIoSto()
would go through properly and complete/cancle the pending IRPs.
But they are not getting called?

Thanks for clarifiction on
QUOTE
on shutdown (it is like an other S state transition).
UNQUOTE.
I understand now why QueryRemove is not getting called.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I am having a little bit of hard time understanding what is going on
here.
Are you saying that you don’t get an EvtIoStop for each irp when you
shutdown the machine? If so, the pnp state machine is not the place to
look
(since you don’t get a remove on shutdown), it would be the power state
machine instead. KMDF will call EvtIoStop on each inflight power
managed
WDFREQUEST on shutdown (it is like an other S state transition). Is the

bugcheck you are posting during a shutdown?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Wednesday, November 22, 2006 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid
this?

Hi,

Here is what happens, if I choose to restart option in the pop-up mesg
that
appeared
when “QUERY_REMOVE” was failed by my driver since it was holding some
IRPs
and processing them resulting in remove getting cancelled by framework
automatically.

From the log it can be seen that when I choose to restart the computer,
the
framework is not calling EvtIoStop and giving me a chance to clear up
(either cancel/complete)
the IRPs. This is resulting in the BSOD.

Infact driver is not being given any chance to do cleanup work for
removing
the device… This can be seen from the log. No other evtcallback fn is
getting executed
when system is restarted. Looks like framework has state machine wherein
it
sees that state transition that happened is:

“WdfDevStatePnpStarted from WdfDevStatePnpStartedCancelRemove”

And so it just goes ahead sends PowerIRPs w/o performing all jobs the
framework/PnP manager does incase of device removal (once QUERY_REMOVE
succeeds).

This whole thing does not look like an expected behaviour… or something

driver cannot manage/prevent BSOD.

Please clarify.

Regards,
-Praveen

Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Error: ADAPTER_ReadPhy: Fatal error. Lock bit still set
Thread 0x8A687030 is waiting for all inflight requests on WDFQUEUE
0x7B7C6CA0 to be acknowledged
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=9F00CF00
(2) status 0
Power Irp Watchdog: warning for PDO=82B21700 Current=84839828
IRP=8A448F00
(2) status c00000bb
Break instruction exception - code 80000003 (first chance)
************************************************************

You are seeing this message because you pressed either
CTRL+C (if you run kd.exe) or,
CTRL+BREAK (if you run WinDBG),
on your debugger machine’s keyboard.

THIS IS NOT A BUG OR A SYSTEM CRASH

If you did not intend to break into the debugger, press the “g” key,
then

press the “Enter” key now. This message might immediately reappear. If
it

does, press “g” and “Enter” again.
*
*****************************************************************

nt!RtlpBreakWithStatusInstruction:
818726d0 cc int 3
kd> !WDFQUEUE 0x7B7C6CA0

Dumping WDFQUEUE 0x7b7c6ca0
=========================
Parallel, Power-managed, PowerStoppingDriverNotified, Can accept, Can
dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 2
Power transition in progress
Number of waiting requests: 0

Number of requests notified about power change: 2
!WDFREQUEST 0x75820fb0 !IRP 0x94448f20
!WDFREQUEST 0x7584d5f8 !IRP 0x94438f20

EvtIoDeviceControl: (0x88431c00) nvnwbx32!PDEvtIoDeviceControl
kd> !wdflogdump nvnwbx32.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\winddk\5744\tools\tracing\i386\wdf01005.tmf
Log at 8483a000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 60, 70, 100
There are 71 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828,
IRP_MJ_PNP,
0x00000000(IRP_MN_START_DEVICE) IRP 0x87492F20
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
7: FxPkgPnp::PnpMatchResources - Not enough interrupt objects created by

WDFDEVICE 0x7B7CA798
8: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarting from
WdfDevStatePwrPolObjectCreated
9: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798 !devobj

0x84839828 entering power idle state FxIdleStarted from FxIdleStopped
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
15: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleStartedPowerUp from
FxIdleStarted
16: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from
FxIdleStartedPowerUp
17: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
18: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerD0 from
WdfDevStatePowerDecideD0State
19: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingSucceeded
from WdfDevStatePwrPolStarting
20: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolStartingDecideS0Wake
from WdfDevStatePwrPolStartingSucceeded
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolStarted from
WdfDevStatePwrPolStartingDecideS0Wake
22: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7B7CA798
!devobj
0x84839828 entering power idle state FxIdleDisabled from FxIdleDisabled
23: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
24: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7B7CA798 !devobj 0x84839828

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
25: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
26: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not
have a
lock order defined in fx\inc\FxVerifierLock.hpp
27: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
28: FxChildList::ProcessBusRelations - PDO created successfully,
WDFDEVICE
76B0CB58 !devobj 895558F8
29: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x8757EF00
30: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
31: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
32: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
33: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingCheckDeviceType from
WdfDevStatePowerObjectCreated
34: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerStartingChild from
WdfDevStatePowerStartingCheckDeviceType
35: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingChild
36: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingConnectInterrupt from
WdfDevStatePowerD0Starting
37: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingDmaEnable from
WdfDevStatePowerD0StartingConnectInterrupt
38: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
39: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
40: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x76B0CB58 !devobj
0x895558F8
entering Power State WdfDevStatePowerD0BusWakeOwner from
WdfDevStatePowerDecideD0State
41: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
42: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x76B0CB58
!devobj 0x895558F8 entering not power policy owner state
WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
43: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
44: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
45: FxPkgPdo::_PnpQueryId - WDFDEVICE 76B0CB58 does not have a string
for
PnP query IdType #-1, 0xc00000bb(STATUS_NOT_SUPPORTED)
46: FxIoQueue::CancelForDriver - WDFREQUEST 0x7584D5F8 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
47: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x7584D5F8 on WDFQUEUE 0x7B7C6CA0
48: FxIoQueue::CancelForDriver - WDFREQUEST 0x75820FB0 was cancelled in
driver for WDFQUEUE 0x7B7C6CA0
49: FxIoQueue::ProcessCancelledRequests - Calling CancelRoutine routine
for
WDFREQUEST 0x75820FB0 on WDFQUEUE 0x7B7C6CA0
50: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9D83EF00
51: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
52: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
53: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
54: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
55: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x99878F00
56: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
57: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
58: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000001(IRP_MN_QUERY_REMOVE_DEVICE) IRP 0x9F18EF00
59: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveStaticCheck from
WdfDevStatePnpStarted
60: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpQueryRemoveAskDriver from
WdfDevStatePnpQueryRemoveStaticCheck
61: FxPkgPnp::PnpEventQueryRemoveAskDriver - EvtDeviceQueryRemove
failed,
0xc0000001(STATUS_UNSUCCESSFUL)
62: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpQueryRemoveAskDriver
63: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8,
IRP_MJ_PNP, 0x00000003(IRP_MN_CANCEL_REMOVE_DEVICE) IRP 0x9ED2EF00
64: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStartedCancelRemove from
WdfDevStatePnpStarted
65: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8

entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpStartedCancelRemove
66: FxPkgPnp::Dispatch - WDFDEVICE 0x76B0CB58 !devobj 0x895558F8
IRP_MJ_POWER, Minor 0x2 IRP 0x9F156ED8
67: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x9F00CF00
68: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state WdfDevStatePwrPolSleeping from
WdfDevStatePwrPolStarted
69: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828 entering power policy state
WdfDevStatePwrPolSleepingWakePowerDown from WdfDevStatePwrPolSleeping
70: FxPkgPnp::Dispatch - WDFDEVICE 0x7B7CA798 !devobj 0x84839828
IRP_MJ_POWER, Minor 0x2 IRP 0x8A448F00
71: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7B7CA798 !devobj
0x84839828
entering Power State WdfDevStatePowerGotoDx from WdfDevStatePowerD0
---- end of log ----

—
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

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 1:12pm

A typo in my last mail. I meant:

When disable operation failed, ie. cancel operation was called, the device
is supposed to be functional as it is in Pnpstarted state
(WdfDevStatePnpStarted)

and not:
When disable operation failed, ie. cancel

operation failed,
the device is supposed to be functional.

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
> Doron,
>
> I understand the point where EvtIoStop not getting called when q.r fails.
> ie. remove/disable operation ends when q.r fails.
>
> But i am talking about a case where I am trying to restart a system after
> disable operation failed. When disable operation failed, ie. cancel
> operation failed,
> the device is supposed to be functional.
>
> Now, when restart happens, device is going to be powered down. ie. system
> and as well device (restart - no need to wakeup system unlike sleep) are
> going to low-powered state.
> In the normal case (when q.r did not fail), FDO of BD would have seen
> EvtIoStop getting called.
> In this case it was not getting called?
>
> *Why? Is this expected? How would driver perform things it had
> scheduled to do in EvtIoStop is my question?
>
> Regards,
> -Praveen
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> EvtIoStop will not be called if someone lower in the device tree fails
> q.r. If someone fails q.r., the remaining part of the tree that had not
> seen a q.r. will not see one. EvtIoStop will not be called in the q.r.
> path at all to begin with though; EvtIoStop is called during the remove
> processing if there was a successful query remove. EvtIoStop will be
> called in the IRP_MN_STOP_DEVICE path as well (it is called whenever we
> power down the device, be it for pnp irps or power irps), but that
> should not be relevant.
>
> Are you saying that EvtIoStop is not being called after a failed q.r. on
> your PDO or your FDO?
>
> I am still a bit unclear what the problem is.
>
> d
>

Doron_Holan · November 27, 2006, 1:28pm

After the q.r. fails, the device *does* move back into the Pnp started
state (WdfDevStatePnpStarted), this is why I am confused as to why you
are not seeing an EvtIoStop later on.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 10:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

A typo in my last mail. I meant:

When disable operation failed, ie. cancel operation was called, the
device
is supposed to be functional as it is in Pnpstarted state
(WdfDevStatePnpStarted)

and not:
When disable operation failed, ie. cancel

operation failed,
the device is supposed to be functional.

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
> Doron,
>
> I understand the point where EvtIoStop not getting called when q.r
fails.
> ie. remove/disable operation ends when q.r fails.
>
> But i am talking about a case where I am trying to restart a system
after
> disable operation failed. When disable operation failed, ie. cancel
> operation failed,
> the device is supposed to be functional.
>
> Now, when restart happens, device is going to be powered down. ie.
system
> and as well device (restart - no need to wakeup system unlike sleep)
are
> going to low-powered state.
> In the normal case (when q.r did not fail), FDO of BD would have
seen
> EvtIoStop getting called.
> In this case it was not getting called?
>
> *Why? Is this expected? How would driver perform things it had
> scheduled to do in EvtIoStop is my question?
>
> Regards,
> -Praveen
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> EvtIoStop will not be called if someone lower in the device tree fails
> q.r. If someone fails q.r., the remaining part of the tree that had
not
> seen a q.r. will not see one. EvtIoStop will not be called in the
q.r.
> path at all to begin with though; EvtIoStop is called during the
remove
> processing if there was a successful query remove. EvtIoStop will be
> called in the IRP_MN_STOP_DEVICE path as well (it is called whenever
we
> power down the device, be it for pnp irps or power irps), but that
> should not be relevant.
>
> Are you saying that EvtIoStop is not being called after a failed q.r.
on
> your PDO or your FDO?
>
> I am still a bit unclear what the problem is.
>
> d
>

—
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

Praveen_Kumar_Amritaluru · November 27, 2006, 2:25pm

Hi D,

I have fixed issue in my driver. I should not be having any IRPs pending
with my BD.
So it does not impact me now until I hit upon this problem for some other
reason.
When I hit upon this/similar prob again, will share any info I find in this
NG.

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
After the q.r. fails, the device does move back into the Pnp started
state (WdfDevStatePnpStarted), this is why I am confused as to why you
are not seeing an EvtIoStop later on.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, November 27, 2006 10:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is this the expected behaviour? Is it possible to
avoid this?

A typo in my last mail. I meant:

When disable operation failed, ie. cancel operation was called, the
device
is supposed to be functional as it is in Pnpstarted state
(WdfDevStatePnpStarted)

and not:
When disable operation failed, ie. cancel
> operation failed,
> the device is supposed to be functional.

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
> Doron,
>
> I understand the point where EvtIoStop not getting called when q.r
fails.
> ie. remove/disable operation ends when q.r fails.
>
> But i am talking about a case where I am trying to restart a system
after
> disable operation failed. When disable operation failed, ie. cancel
> operation failed,
> the device is supposed to be functional.
>
> Now, when restart happens, device is going to be powered down. ie.
system
> and as well device (restart - no need to wakeup system unlike sleep)
are
> going to low-powered state.
> In the normal case (when q.r did not fail), FDO of BD would have
seen
> EvtIoStop getting called.
> In this case it was not getting called?
>
> *Why? Is this expected? How would driver perform things it had
> scheduled to do in EvtIoStop is my question?
>
> Regards,
> -Praveen
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> EvtIoStop will not be called if someone lower in the device tree fails
> q.r. If someone fails q.r., the remaining part of the tree that had
not
> seen a q.r. will not see one. EvtIoStop will not be called in the
q.r.
> path at all to begin with though; EvtIoStop is called during the
remove
> processing if there was a successful query remove. EvtIoStop will be
> called in the IRP_MN_STOP_DEVICE path as well (it is called whenever
we
> power down the device, be it for pnp irps or power irps), but that
> should not be relevant.
>
> Are you saying that EvtIoStop is not being called after a failed q.r.
on
> your PDO or your FDO?
>
> I am still a bit unclear what the problem is.
>
> d
>

—
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