Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

If we are registering for pnp request using
IoRegisterPlugPlayNotification, then will we be getting notification
for any of the below irp sent to the respective device object.
IRP_MN_QUERY_STOP_DEVICE
IRP_MN_CANCEL_STOP_DEVICE
IRP_MN_STOP_DEVICE

thanks
santosh k

Life is Small and Lots of Things to Learn
Lets Share the Knowledge

The IRP_MN_XXX go to the device object always. I think you are confused
by the fact that IoRegisterPlugPlayNotification is used not to get
information about your device, but about devices your driver depends on.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“santosh katvate” wrote in message
news:xxxxx@ntdev:

> If we are registering for pnp request using
> IoRegisterPlugPlayNotification, then will we be getting notification
> for any of the below irp sent to the respective device object.
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_CANCEL_STOP_DEVICE
> IRP_MN_STOP_DEVICE
>
> thanks
> santosh k
> –
> Life is Small and Lots of Things to Learn
> Lets Share the Knowledge

Hi Don

Actually there are two drivers communicating using Inteface mechanism.
My doubt was whether the second driver which has registered for pnp
callback notification will receive any notification, if the first
driver receives below given irps
IRP_MN_QUERY_STOP_DEVICE
IRP_MN_CANCEL_STOP_DEVICE
IRP_MN_STOP_DEVICE

Also is it safe to call
IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, FALSE); in
IRP_MN_STOP_DEVICE and then call
IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, TRUE); in
IRP_MN_START_DEVICE.

thanks
santosh k

No the registration is for interfaces so there is no notification for
these. You should be doing the calls to IoSetDeviceInterfaceState and
in particular that is how you will have some notification that first
device is stopping.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“santosh katvate” wrote in message
news:xxxxx@ntdev:

> Hi Don
>
> Actually there are two drivers communicating using Inteface mechanism.
> My doubt was whether the second driver which has registered for pnp
> callback notification will receive any notification, if the first
> driver receives below given irps
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_CANCEL_STOP_DEVICE
> IRP_MN_STOP_DEVICE
>
>
> Also is it safe to call
> IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, FALSE); in
> IRP_MN_STOP_DEVICE and then call
> IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, TRUE); in
> IRP_MN_START_DEVICE.
>
> thanks
> santosh k

thx i understand it better now, i have one more doubt.
Is IoSetDeviceInterfaceState() function call synchronous with
notification callback functions.?

i.e. If i call IoSetDeviceInterfaceState(&pDevExtension->InterfaceName,
FALSE);, then is it guaranteed that all the notification callback
rountines has completed there execution and then only the
IoSetDeviceInterfaceState call will return back to the caller code.

thanks
santosh k

Pnp stop should be 100% transparent to all clients of the driver receiving the stop. Iosetdeviceinterfacestate(false) does not call back into components who have registed plug play notifications nor does it close any handles open to your device.

What problem are you trying to solve?

d

dent from a phpne with no keynoard

-----Original Message-----
From: santosh katvate
Sent: October 21, 2010 5:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

thx i understand it better now, i have one more doubt.
Is IoSetDeviceInterfaceState() function call synchronous with
notification callback functions.?

i.e. If i call IoSetDeviceInterfaceState(&pDevExtension->InterfaceName,
FALSE);, then is it guaranteed that all the notification callback
rountines has completed there execution and then only the
IoSetDeviceInterfaceState call will return back to the caller code.

thanks
santosh k


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

Doron, MSDN says “If a call to IoSetDeviceInterfaceState successfully exposes a device interface instance, the system notifies any components that registered for PnP notification of a device class change. ““Similarly, if a call to this routine disables an existing device interface instance, the system sends appropriate notifications.”””

which is in conflict with your statement "Iosetdeviceinterfacestate(false) does not call back into components who have registed plug play notifications ".

I thought the client will be notified using GUID_DEVICE_INTERFACE_REMOVAL whenever the interface is disabled - be it when IoSetDeviceInterfaceState (false) is called or when the device is removed.

Can you please clarify? Thank you.

GUID_DEVICE_INTERFACE_REMOVAL is only sent when the device stack gets a pnp removal or surprise removal. It is a common hope that you cn use device interface state to handle pnp stop, but it is not.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@yahoo.com
Sent: October 21, 2010 8:56 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

Doron, MSDN says “If a call to IoSetDeviceInterfaceState successfully exposes a device interface instance, the system notifies any components that registered for PnP notification of a device class change. ““Similarly, if a call to this routine disables an existing device interface instance, the system sends appropriate notifications.”””

which is in conflict with your statement "Iosetdeviceinterfacestate(false) does not call back into components who have registed plug play notifications ".

I thought the client will be notified using GUID_DEVICE_INTERFACE_REMOVAL whenever the interface is disabled - be it when IoSetDeviceInterfaceState (false) is called or when the device is removed.

Can you please clarify? Thank you.


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

> IoRegisterPlugPlayNotification, then will we be getting notification

for any of the below irp sent to the respective device object.
IRP_MN_QUERY_STOP_DEVICE
IRP_MN_CANCEL_STOP_DEVICE
IRP_MN_STOP_DEVICE

No, only for query remove and remove.


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

> Also is it safe to call

IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, FALSE); in
IRP_MN_STOP_DEVICE and then call
IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, TRUE); in
IRP_MN_START_DEVICE.

What is the need in this?

STOP is hardware resource rebalancing. It must be transparent to the apps. What is the need to revoke/recreate the names due to this?


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

>GUID_DEVICE_INTERFACE_REMOVAL is only sent when the device stack gets a pnp removal or

surprise removal.

Am I correct in the following sequence:

  • device (which has active devinterface symlinks) is decided to be removed by PnP code in kernel
  • GUID_DEVICE_INTERFACE_REMOVAL is sent
  • all kinds of veto are checked
  • MN_QUERY_REMOVE is sent to the stack itself
  • if this succeeds too - MN_REMOVE is sent
  • and only here, the driver calls IoSetDeviceInterfaceState(FALSE)

Or with surprise removal:

  • removal is detected from the new BusRelations
  • GUID_DEVICE_INTERFACE_REMOVAL is sent since the device has active interfaces
  • MN_SURPRISE_REMOVAL is sent
  • and only here, the driver calls IoSetDeviceInterfaceState(FALSE)

Is this correct?


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

Mostly correct, the query removal guid is used at the start of the graceful remove path

  • device (which has active devinterface symlinks) is decided to be removed by PnP code in kernel
    ==> - GUID_DEVICE_INTERFACE_QUERY_REMOVAL is sent

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, October 21, 2010 12:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

GUID_DEVICE_INTERFACE_REMOVAL is only sent when the device stack gets a
pnp removal or surprise removal.

Am I correct in the following sequence:

  • device (which has active devinterface symlinks) is decided to be removed by PnP code in kernel
  • GUID_DEVICE_INTERFACE_REMOVAL is sent
  • all kinds of veto are checked
  • MN_QUERY_REMOVE is sent to the stack itself
  • if this succeeds too - MN_REMOVE is sent
  • and only here, the driver calls IoSetDeviceInterfaceState(FALSE)

Or with surprise removal:

  • removal is detected from the new BusRelations
  • GUID_DEVICE_INTERFACE_REMOVAL is sent since the device has active interfaces
  • MN_SURPRISE_REMOVAL is sent
  • and only here, the driver calls IoSetDeviceInterfaceState(FALSE)

Is this correct?


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


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

Hi Doron/Maxim

Overview:
First Driver#: It is the actual driver of hardware
Second Driver#: It sends command which result in hardware access and
r/w of register.

Protocol to follow for the communication:

  1. First Driver#: IRP_MN_START_DEVICE
  2. First Driver# Call
    IoSetDeviceInterfaceState(&pDevExtension->InterfaceName, TRUE);
  3. Second Driver#: pnp notification callback function gets called.
    which then exchanges each other interface function pointers.
  4. First Driver#: Receives IRP_MN_QUERY_STOP_DEVICE
  5. First Driver#: Should make use of function pointer to make call
    into Second_Driver to stop the device.
  6. First Driver#: If Recieives IRP_MN_CANCEL_STOP_DEVICE then should
    make use of function pointer to make call into Second_Driver to start
    the device communication.

So looks like for query_stop_device OR stop_device irp driver needs to
communicate this state to second/paired driver.

Question#1:
Can i use IoSetDeviceInterfaceState(FALSE) for step-5 and
IoSetDeviceInterfaceState(TRUE) for step-6.

Question#2:
I have IoSetDeviceInterfaceState(TRUE) in function for
IRP_MN_START_DEVICE, and IoSetDeviceInterfaceState(FALSE) in
IRP_MN_SURPRISE_REMOVAL/IRP_MN_REMOVE_DEVICE.
So if i receive IRP_MN_STOP_DEVICE then IRP_MN_START_DEVICE, so will
my “Inteface Arrival” function get called? OR
IoSetDeviceInterfaceState(TRUE) in function for IRP_MN_START_DEVICE
will not notify to its client, since inteface is still TRUE.

thanks
santosh k

> So looks like for query_stop_device OR stop_device irp driver needs to

communicate this state to second/paired driver.

No need. Query stop and stop must be transparent to the client driver.


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

hi Maxim

No need. Query stop and stop must be transparent to the client driver.

For query_stop irp we should stop the device.
But since second driver is continuosly sending commands to first
driver using fn pointer exchanged as part of “Device Interfaces
mechanism”, i need to somehow communicate this state to second driver
so that it will not send any more command to first driver.
Let me know if my understanding is correct.

thanks
santosh k

> For query_stop irp we should stop the device.

But since second driver is continuosly sending commands to first
driver using fn pointer exchanged as part of “Device Interfaces
mechanism”, i need to somehow communicate

No need. Just queue the requests from the second driver till next MN_START_DEVICE.


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

The direct function pointer interface that you create should be able to pend requests made when it is called. That way you just pend them in the driver being stopped, not the driver making the call

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of santosh katvate
Sent: Sunday, October 24, 2010 9:33 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:RE:Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

hi Maxim

No need. Query stop and stop must be transparent to the client driver.

For query_stop irp we should stop the device.
But since second driver is continuosly sending commands to first driver using fn pointer exchanged as part of “Device Interfaces mechanism”, i need to somehow communicate this state to second driver so that it will not send any more command to first driver.
Let me know if my understanding is correct.

thanks
santosh k


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

Hi Doron

The direct function pointer interface that you create should be able to pend requests made when it is called. ?That way you just pend them in the driver being stopped, not the driver making the call

i can pend it when i receive irp_mn_query_stop_device , but if i
receive irp_mn_stop_device then at least i will have to convey this to
second driver. Since it will keep on sending me requests and expecting
a response which will not be possible if the device is stopped.
Is this understanding correct?

thanks
santosh k

>second driver. Since it will keep on sending me requests and expecting

a response which will not be possible if the device is stopped.
Is this understanding correct?

Yes. The response will follow when the device is restarted.


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

The stop should be entirely 100% transparent to the second driver. The stop is temporary, is the second driver setting a timer to cancel the request if it takes too long?

d

dent from a phpne with no keynoard

-----Original Message-----
From: santosh katvate
Sent: October 24, 2010 10:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:RE:Doubt in pnp notfication received for IoRegisterPlugPlayNotification function.

Hi Doron

> The direct function pointer interface that you create should be able to pend requests made when it is called. That way you just pend them in the driver being stopped, not the driver making the call
>
i can pend it when i receive irp_mn_query_stop_device , but if i
receive irp_mn_stop_device then at least i will have to convey this to
second driver. Since it will keep on sending me requests and expecting
a response which will not be possible if the device is stopped.
Is this understanding correct?

thanks
santosh k


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