IRP_MN_STOP_DEVICE on WHQL rebalance test

OSR_Community_User · February 25, 2009, 4:04am

Hi forks,

When WHQL rebalance test for my virtual NDIS miniport driver for Xen windows para-virtual driver, I meet a problem on how to deal with IRP_MN_STOP_DEVICE. From WDK document for this IRP, I know that I need to release memory and something others which I allocate or bind for this device and set appropriate device power state in my bus driver. In NDIS miniport driver, I need to halt the NIC and release resource attach on this device. I think I have done all of these but maybe loss something. So WHQL test will fail on ‘FailReStart’ test case. In WLK document I know that this test case will send following IRPs to device.

a… IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the drivers. The test already covered the case where this IRP is failed.)
a… IRP_MN_QUERY_RESOURCE_REQUIREMENTS
a… IRP_MN_FILTER_RESOURCE_REQUIREMENTS (If the actual resource requirement are null, filter assign fake resource requirement, so there is a stop and a start.)
a… IRP_MN_STOP_DEVICE
a… IRP_MN_START_DEVICE (The filter fails this IRP while going up. This action causes the surprise remove IRP.)
a… IRP_MN_SURPRISE_REMOVAL
a… IRP_MN_REMOVE

The problem I meet is that after filter fails IRP_MN_START_DEVICE, my bus driver cannot get IRP_MN_SURPRISE_REMOVAL IRP for that PDO. And device manager say that ‘this device is working properly’. It seems that PnP manager didn’t know this device is stopped. From my bus driver debug log I know that after IRP_MN_STOP_DEVICE, I get a QDR/busRelastions IRP, I report this PDO to PnP manager. I guess I miss something to set to this PDO, to tell PnP manager that this device is stopped. How can I do that?

Thanks
wayne

OSR_Community_User · February 25, 2009, 6:47am

From WDK document I find that ‘PnP manager will send surprise_remove/remove after all open handles are closed’. What’s the ‘all open handles’ mean? Use ObReferenceObject() will add a open handle?

Thanks
wayne

OSR_Community_User · February 25, 2009, 8:11am

From: “Wayne.Gong”
> From WDK document I find that ‘PnP manager will send
> surprise_remove/remove after all open handles are closed’. What’s the ‘all
> open handles’ mean? Use ObReferenceObject() will add a open handle?

Open handles are those created by CreateFile and a variety of kernel-mode
functions. Referencing the object doesn’t add a handle and doesn’t affect
whether a REMOVE_DEVICE will be sent by the PnP Manager, although it does
prevent the DEVICE_OBJECT from being released back to the memory pool.

–
Walter Oney
Attorney at Law (Massachusetts)
www.oneylaw.com
Any U.S. tax advice in this communication is not intended or written to be
used, and cannot be used, for the purpose of avoiding tax penalties or in
connection with marketing or promotional materials.

Alex_Grig · February 25, 2009, 10:20am

SURPRISE_REMOVAL should not wait for all handles closed.

Pavel_A1 · February 25, 2009, 11:24am

Wayne.Gong wrote:

Hi forks,

When WHQL rebalance test for my virtual NDIS miniport driver for Xen
windows para-virtual driver, I meet a problem on how to deal with
IRP_MN_STOP_DEVICE. From WDK document for this IRP, I know that I need
to release memory and something others which I allocate or bind for this
device and set appropriate device power state in my bus driver. In NDIS
miniport driver, I need to halt the NIC and release resource attach on
this device. I think I have done all of these but maybe loss
something. So WHQL test will fail on ‘FailReStart’ test case. In WLK
document I know that this test case will send following IRPs to device.

IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the

drivers. The test already covered the case where this IRP is failed.)

IRP_MN_QUERY_RESOURCE_REQUIREMENTS

IRP_MN_FILTER_RESOURCE_REQUIREMENTS (If the actual resource requirement

are null, filter assign fake resource requirement, so there is a stop
and a start.)

IRP_MN_STOP_DEVICE

IRP_MN_START_DEVICE (The filter fails this IRP while going up. This

action causes the surprise remove IRP.)

IRP_MN_SURPRISE_REMOVAL

IRP_MN_REMOVE

The problem I meet is that after filter fails IRP_MN_START_DEVICE, my
bus driver cannot get IRP_MN_SURPRISE_REMOVAL IRP for that PDO. And
device manager say that ‘this device is working properly’. It seems that
PnP manager didn’t know this device is stopped. From my bus driver debug
log I know that after IRP_MN_STOP_DEVICE, I get a QDR/busRelastions IRP,
I report this PDO to PnP manager. I guess I miss something to set to
this PDO, to tell PnP manager that this device is stopped. How can I do
that?

Thanks
wayne

Maxim_S_Shatskih · February 25, 2009, 5:48pm

Surprise remove is sent immediately when the device is detected to be lost.

“Remove device” is sent when all file objects referencing the stack will be destroyed.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Wayne.Gong” wrote in message news:xxxxx@ntdev…
From WDK document I find that ‘PnP manager will send surprise_remove/remove after all open handles are closed’. What’s the ‘all open handles’ mean? Use ObReferenceObject() will add a open handle?

Thanks
wayne

Maxim_S_Shatskih · February 25, 2009, 5:48pm

> functions. Referencing the object doesn’t add a handle and doesn’t affect

whether a REMOVE_DEVICE will be sent by the PnP Manager, although it does
prevent the DEVICE_OBJECT from being released back to the memory pool.

Referencing device object - yes.

Referencing file object continues the life of the file object till deref, and thus delays REMOVE_DEVICE till deref.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · February 25, 2009, 8:53pm

> Surprise remove is sent immediately when the device is detected to

be lost.

How to tell PnP manager that the device is detected to be lost? I mean
when resource rebalanced.

The problem is that my bus driver didn’t get surprise remove IRP for
that PDO. PnpDTest told me that fail restart test is fail and the error
code is 0. I guess that means after STOP_DEVICE, the NIC controller in
device manager is still ‘working properly’. So when pnpDTest fail
START_DEVICE, pnp manager didn’t send surprise remove IRP to bus driver.
I don’t know how to tell pnp manager that the PDO cannot work properly
after stop device.

Thanks
Wayne

OSR_Community_User · February 25, 2009, 8:56pm

xxxxx@broadcom.com wrote:

SURPRISE_REMOVAL should not wait for all handles closed.

If so, I think I need to find some function call or flags to tell PnP
manager that such device can be and need to surprise remove when
resource balancing. Any idea about how to do that?

Thanks
wayne

Maxim_S_Shatskih · February 25, 2009, 8:58pm

> How to tell PnP manager that the device is detected to be lost? I mean

when resource rebalanced.

IoInvalidateDeviceRelations, then, in MN_QUERY_RELATIONS, do not put the lost device in relations.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Doron_Holan · February 25, 2009, 9:12pm

If stop_device is failed in the stack, a surprise remove should come automaticaly. I woulf break into the debugger and run !locks to see if any thread is blocking pnp and preventing the surprise remove from being sent

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Wayne Gong
Sent: Wednesday, February 25, 2009 5:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP_MN_STOP_DEVICE on WHQL rebalance test

xxxxx@broadcom.com wrote:
> SURPRISE_REMOVAL should not wait for all handles closed.

If so, I think I need to find some function call or flags to tell PnP
manager that such device can be and need to surprise remove when
resource balancing. Any idea about how to do that?

Thanks
wayne

—
NTDEV is sponsored by OSR

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

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

OSR_Community_User · February 25, 2009, 9:45pm

Maxim S. Shatskih wrote:

> How to tell PnP manager that the device is detected to be lost? I mean
> when resource rebalanced.
>

IoInvalidateDeviceRelations, then, in MN_QUERY_RELATIONS, do not put the lost device in relations.

Yes, that method can notify PnP manager send surprise remove to bus
driver and then remove. But that’s the normal method used to
remove/delete device. Does it suitable for PnPDTtest? PnPDTest doc said
after it fail the new start device, PnP manager will send surprise
remove and then remove.

Thanks
wayne

OSR_Community_User · February 25, 2009, 9:52pm

Doron Holan wrote:

If stop_device is failed in the stack, a surprise remove should come automaticaly. I woulf break into the debugger and run !locks to see if any thread is blocking pnp and preventing the surprise remove from being sent

Do you mean to fail stop_device or just a typo for start_device? When I
developing my drivers at very beginning, I found that when OS boot up,
if I fail start_device, a surprise remove actually come immediately. But
it doesn’t happen when resource rebalanced. I will try to use windbg to
get more info. Would you please guide me how to use !locks to find
specific info I need to check?

Thanks
wayne

Doron_Holan · February 25, 2009, 10:14pm

Run !locks in whatever scenario you think you should be getting a pnp irp and you are not. The output of !locks will give you the owner of the pnp lock if it is currently held. Run !thread (thread pointer) and it will give you the callstack which may tel you who is blocking pnp from sending you the remove

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Wayne Gong
Sent: Wednesday, February 25, 2009 6:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP_MN_STOP_DEVICE on WHQL rebalance test

Doron Holan wrote:
> If stop_device is failed in the stack, a surprise remove should come automaticaly. I woulf break into the debugger and run !locks to see if any thread is blocking pnp and preventing the surprise remove from being sent

Do you mean to fail stop_device or just a typo for start_device? When I
developing my drivers at very beginning, I found that when OS boot up,
if I fail start_device, a surprise remove actually come immediately. But
it doesn’t happen when resource rebalanced. I will try to use windbg to
get more info. Would you please guide me how to use !locks to find
specific info I need to check?

Thanks
wayne

—
NTDEV is sponsored by OSR

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

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

OSR_Community_User · February 25, 2009, 11:00pm

Doron Holan wrote:

Run !locks in whatever scenario you think you should be getting a pnp irp and you are not. The output of !locks will give you the owner of the pnp lock if it is currently held. Run !thread (thread pointer) and it will give you the callstack which may tel you who is blocking pnp from sending you the remove

!locks tells me that no locks is held when my bus driver is waiting for
surprise remove after pnpdtest fail restart_device. !locks -v tells me
that all locks are available. Any more doc I need to read?

thanks
wayne

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held
locks…
3313 total locks
kd>

OSR_Community_User · February 25, 2009, 11:09pm

PnPDTest log from DegView is,

00000107 6.70947504 PNPFILTR: FilterCompletionRoutine Completed,
event set.
00000108 6.70948839 PNPFILTR: Time taken for IRP_MN_STOP_DEVICE to
get processed for the PDO FFFFFA8000A04060 is 1843 miliseconds
00000109 6.70949459 PNPFILTR: Completing FilterStop with status
0x0 for stack with PDO 0xa04060
00000110 6.71651268 XenPCI: FDO:IRP_MN_QUERY_DEVICE_RELATIONS
IRP:0xFFFFFA80012ED820
00000111 6.71652079 XenPCI: BusRelations
00000112 6.71662855 XenPCI:–>[XenPciPnPFDOQueryBusRelationWorker]
00000113 6.71675205 XenPCI: Get xenhide interface successful,
update PDO list
00000114 6.71675634 XenPCI: probe device
00000115 6.71676111 XenPCI:–>[XenPciDeleteUnconnectedDevice]
00000116 6.71954918 XenPCI:<–[XenPciDeleteUnconnectedDevice]
00000117 6.71984005 XenPCI: An exsit device, path:
device/vbd/768
00000118 6.71984529 XenPCI: An exsit device, path:
device/vbd/5632
00000119 6.71993446 XenPCI: An exsit device, path: device/vif/0
00000120 6.72006130 XenPCI: XenPciPnPFDOQueryBusRelationWorker:
child device count: 3
00000121 6.72006845 XenPCI:<–[XenPciPnPFDOQueryBusRelationWorker]
00000122 6.72030544 PNPFILTR: Received IRP_MN_START_DEVICE for
stack with PDO 0xFFFFFA8000A04060
00000123 6.72031069 PNPFILTR: Failing IRP_MN_START_DEVICE as
requested . PDO = 0xFFFFFA8000A04060
00000124 6.72050428 XenVBD: Inquiry to a disk device.
PDO:FFFFFA8000B05920
00000125 6.72063923 XenVBD: Inquiry to a disk device.
PDO:FFFFFA8000B05920
00000126 6.72064400 XenVBD: INQUIRY->VPD_SERIAL_NUMBER
00000127 6.72073221 XenPCI: PDO:IRP_MN_QUERY_DEVICE_RELATIONS
IRP:0xFFFFFA80012ED820
00000128 6.72073793 XenPCI: BusRelations, IRP status:0x0
00000129 6.72097445 XenVBD: Inquiry to a disk device.
PDO:FFFFFA8000B05520
00000130 6.72106409 XenVBD: Inquiry to a disk device.
PDO:FFFFFA8000B05520
00000131 6.72106934 XenVBD: INQUIRY->VPD_SERIAL_NUMBER
00000132 6.72115278 XenPCI: PDO:IRP_MN_QUERY_DEVICE_RELATIONS
IRP:0xFFFFFA800155D870
00000133 6.72115803 XenPCI: BusRelations, IRP status:0x0
00000134 104.85504913 PNPFILTR: WARNING: Query Result Timed out on
Surprise Remove. Device did not get a Remove IRP
00000135 104.85506439 PNPFILTR: Number of IRPs Stored… 7
00000136 104.85509491 PNPFILTR: Query Result - Releasing the
remove
00000137 104.85510254 PNPFILTR: Query Result -Result Stored Event
set
00000138 104.85592651 [2332] Relevant Sequence of Irps:
00000139 104.85611725 [2332] IRP_MN_QUERY_PNP_DEVICE_STATE
00000140 104.85629272 [2332] IRP_MN_QUERY_STOP_DEVICE
00000141 104.85647583 [2332] IRP_MN_QUERY_RESOURCE_REQUIREMENTS
00000142 104.85665131 [2332] IRP_MN_FILTER_RESOURCE_REQUIREMENTS
00000143 104.85681915 [2332] IRP_MN_QUERY_INTERFACE
00000144 104.85700226 [2332] IRP_MN_STOP_DEVICE
00000145 104.85717773 [2332] IRP_MN_START_DEVICE
00000146 104.85888672 [2332] Assert: Device node status not as
expected: problem code 0
00000147 104.85888672 [2332]
File=d:\4271t\testsrc\basetest\pnp\pnpdtest\user\pnpdtest.c, Line=323

Thanks
wayne

OSR_Community_User · February 25, 2009, 11:17pm

Sorry for the log is unreadable.

PNPFILTR: FilterCompletionRoutine Completed, event set.
PNPFILTR: Time taken for IRP_MN_STOP_DEVICE to get processed for the PDO
FFFFFA8000A04060 is 1843 miliseconds
PNPFILTR: Completing FilterStop with status 0x0 for stack with PDO
0xa04060

My bus driver FDO receive a QDR/busRelations.

PNPFILTR: Received IRP_MN_START_DEVICE for stack with PDO
0xFFFFFA8000A04060
PNPFILTR: Failing IRP_MN_START_DEVICE as requested . PDO =
0xFFFFFA8000A04060

PNPFILTR: WARNING: Query Result Timed out on Surprise Remove. Device did
not get a Remove IRP
PNPFILTR: Number of IRPs Stored… 7
PNPFILTR: Query Result - Releasing the remove
PNPFILTR: Query Result -Result Stored Event set
[2332] Relevant Sequence of Irps:
[2332] IRP_MN_QUERY_PNP_DEVICE_STATE
[2332] IRP_MN_QUERY_STOP_DEVICE
[2332] IRP_MN_QUERY_RESOURCE_REQUIREMENTS
[2332] IRP_MN_FILTER_RESOURCE_REQUIREMENTS
[2332] IRP_MN_QUERY_INTERFACE
[2332] IRP_MN_STOP_DEVICE
[2332] IRP_MN_START_DEVICE
[2332] Assert: Device node status not as expected: problem code 0
[2332] File=d:\4271t\testsrc\basetest\pnp\pnpdtest\user\pnpdtest.c,
Line=323

Thanks
Wayne