We are trying to handle pnp requests for a network adapter from our virtual SCSI Miniport driver. For this purpose we have we have used IORegisterPlugnplaynotification for two event categories , one is with EventCategoryInterfaceChange and another one is EventCategoryTargetDeviceChange. While we get a callback notification for the first case but we don’t get callback notification in the second case.
Code Snippets -
First Case
status = IoRegisterPlugPlayNotification(EventCategoryDeviceInterfaceChange,
PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES,
(PVOID)NVCACHE_GUID_TYPE,
OsrDriverObject,
(PDRIVER_NOTIFICATION_CALLBACK_ROUTINE)PnpNotifyCallback,
pAE,
&pAE->DeviceInterfaceNotificationEntry); status = IoGetDeviceObjectPointer(&pAE->SymbolicLinkName,
STANDARD_RIGHTS_ALL,
&thisDeviceFileObject,
&thisDeviceObject);
if (!NT_SUCCESS(status)) {
goto Exit;
}
SECOND CASE:
status = IoRegisterPlugPlayNotification(EventCategoryTargetDeviceChange,
PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES,
thisDeviceFileObject,
OsrDriverObject,
(PDRIVER_NOTIFICATION_CALLBACK_ROUTINE)PnpNotifyTargetDeviceChangeCallback,
pAE,
&pAE->TargetDeviceNotificationEntry);
Also what is the right way to establish a proper power event relationship between Network Adapter and our Virtual Scsi miniport driver, so that power requests for the network adapter can be handled in our Virtual SCSI miniport driver.
Please help.
We are trying to handle pnp requests for a network adapter from our virtual SCSI Miniport driver.
What larger problem are you trying to solve? Also, how is the NIC enumerated and which way does the dependency go between the two devices (i.e. does the NIC depend on the SCSI miniport or the other way around)?
While we get a callback notification for the first case but we don’t get callback notification in the second case.
Which PnP requests are you trying to handle? You say you don’t get ANY notifications, but EventCategoryTargetDeviceChange only reports a subset of PnP operations (specifically remove events).
Also what is the right way to establish a proper power event relationship between Network Adapter and our Virtual Scsi miniport driver
The only way I know of to guarantee a power relationship is by creating a PnP relationship between the devices (children always need to power down before the parent). By way of implementation the system power down sequence goes in order:
- Root enumerated, pageable devices (DO_POWER_PAGABLE set)
- Non-root enumerated, pagable devices (DO_POWER_PAGABLE set)
- Root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
- Non-root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
I wouldn’t bet my life on that, though i’d say it’s generally safe to assume that pageable devices will power down before the non-pageable ones.
You need to define your problem more though to know if any of that is going to help you.
You can now specify power relations (as of win7 so it has been a while 
), https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/irp-mn-query-device-relations , outside of the pnp tree relationship
Bent from my phone
From: Scott_Noone_(OSR)
Sent: Friday, October 19, 2018 7:17:46 AM
To: Doron Holan
Subject: Re: [NTDEV] IoRegisterPlugnPlayNotification Does Not work for EventCategoryTargetDeviceChange
OSR https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.osr.com%2F&data=02|01|doron.holan%40microsoft.com|c218044431fa4073677f08d635cda4e5|72f988bf86f141af91ab2d7cd011db47|1|0|636755554689030032&sdata=vjVlXotJyFvUg5s3kSTwO%2BlB8Uh7qvQhqr%2Fwtn2b9ck%3D&reserved=0
Scott_Noone_(OSR) commented on IoRegisterPlugnPlayNotification Does Not work for EventCategoryTargetDeviceChange
> We are trying to handle pnp requests for a network adapter from our virtual SCSI Miniport driver.
What larger problem are you trying to solve? Also, how is the NIC enumerated and which way does the dependency go between the two devices (i.e. does the NIC depend on the SCSI miniport or the other way around)?
> While we get a callback notification for the first case but we don’t get callback notification in the second case.
Which PnP requests are you trying to handle? You say you don’t get ANY notifications, but EventCategoryTargetDeviceChange only reports a subset of PnP operations (specifically remove events).
> Also what is the right way to establish a proper power event relationship between Network Adapter and our Virtual Scsi miniport driver
The only way I know of to guarantee a power relationship is by creating a PnP relationship between the devices (children always need to power down before the parent). By way of implementation the system power down sequence goes in order:
* Root enumerated, pageable devices (DO_POWER_PAGABLE set)
* Non-root enumerated, pagable devices (DO_POWER_PAGABLE set)
* Root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
* Non-root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
I wouldn’t bet my life on that, though i’d say it’s generally safe to assume that pageable devices will power down before the non-pageable ones.
You need to define your problem more though to know if any of that is going to help you.
You can now specify power relations
Fine, be that way.
Also, good to know, thanks!
@“Scott_Noone_(OSR)” said:
You can now specify power relations
Fine, be that way.
Also, good to know, thanks!
@“Scott_Noone_(OSR)” said:
We are trying to handle pnp requests for a network adapter from our virtual SCSI Miniport driver.
What larger problem are you trying to solve? Also, how is the NIC enumerated and which way does the dependency go between the two devices (i.e. does the NIC depend on the SCSI miniport or the other way around)?
While we get a callback notification for the first case but we don’t get callback notification in the second case.
Which PnP requests are you trying to handle? You say you don’t get ANY notifications, but EventCategoryTargetDeviceChange only reports a subset of PnP operations (specifically remove events).
Also what is the right way to establish a proper power event relationship between Network Adapter and our Virtual Scsi miniport driver
The only way I know of to guarantee a power relationship is by creating a PnP relationship between the devices (children always need to power down before the parent). By way of implementation the system power down sequence goes in order:
- Root enumerated, pageable devices (DO_POWER_PAGABLE set)
- Non-root enumerated, pagable devices (DO_POWER_PAGABLE set)
- Root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
- Non-root enumerated, non-pageable devices (DO_POWER_PAGABLE clear)
I wouldn’t bet my life on that, though i’d say it’s generally safe to assume that pageable devices will power down before the non-pageable ones.
You need to define your problem more though to know if any of that is going to help you.
@Scott_Noone_(OSR)
Thanks a lot for your Input & Insights.
As you asked , i will describe the problem in detail.
We are trying to mount a remote storage device through tcp/ip . So basically we are consumer of Network Adapter in a way and are holding some resources of the Network Adapter all the time. Now this causes issue when system request a hibernation. In this case we are supposed to release all the resources of the Network Adapter so that it can handle the hibernation properly. But we have no way of knowing when the Network Adapter is getting the hibernation request. Till now we were trying with IOregisterPlugnPlayNotification with TargetDeviceChanged. But not getting the callback.
We also that felt an alternate approach could be to create a power-event based relationship between the Network Adapter and our scsi miniport driver, so that we get notified whenever the network adapter gets hibernate request so that we can release the network resources.
Please let us know if you have more insights on this.
devd3003 wrote:
We also that felt an alternate approach could be to create a power-event based relationship between the Network Adapter and our scsi miniport driver, so that we get notified whenever the network adapter gets hibernate request so that we can release the network resources.
Interesting. Why would your case be any different from a user-mode
socket client? Network adapters are perfectly capable of hibernating
with a bunch of user-mode clients attached. What resources do you need
to hold that is causing this interference?
Yeah, generally, you don’t need to attach yourself to the network adapter’s device. Usually, you just need to open a socket. (Via WSK, if in kernel mode.) Then TCPIP hides from you the messy business of talking to NDIS. (Who himself hides from TCPIP the even messier business of dealing with a device.)
In fact, you don’t want to tie yourself to a particular device. Consider a failover situation: you might have multiple network adapter card devices on the system, and an IP address can shift from one to the other. You want yourself to float with the IP address – this problem is solved by binding to a socket, not to a network adapter.
Another wrinkle: recent versions of Windows have network interfaces with no PNP device backing them. These are full-fledged, first-class network interfaces, with an IP address, an ifDescr, and all the other trappings… there’s just no PNP device in the tree for them. These guys mean that your networking application shouldn’t try to fiddle with the PNP device underlying the network interface, because there might not be one to fiddle.