Hello everyone!
I am interested in ways to emulate the physical removal of a device (generic abstract pnp-device) without actually removing it, followed by the emulation of enabling it. That is so that the system correctly thinks and processes that the device is deleted/inserted.
Any tips and ideas are welcome!!!
Thanks!
Device Manager Disable/Enable??
The PnPDTest tool also does this.
Peter
Thank you, Peter, but no, correctly emulation hardware remove/insert on kernel driver level. It’s possible? I.e. - virtual bus driver wich perfectly emulates device insert/remove and other…
Sure - write a bus driver and during its dynamic device enumeration,
randomly remove pdos from the enumeration list.
Mark Roddy
1 Like
Ok, I have the issue :
0. I’m bus upper filter driver on usb-hub;
- I perform IoInvalidateDeviceRelations[BusRelations] and to response on IRP_MN_QUERY_DEVICE_RELATIONS from PnP-manager remove some PDO : for emulating hardware remove action;
- All ok and device disappears from the device tree and Device manager;
- Then I want to emulate hardware insert action and do IoInvalidateDeviceRelations[BusRelations] and to response on IRP_MN_QUERY_DEVICE_RELATIONS from PnP-manager add deleted PDO;
- But PnP manager doesn’t construct device tree and driver stack for this PDO =(((( Device don’t arrive in the system and Device manager …
Where am I’m wrong ? Please, explain to me =)
When you say “add deleted PDO”, do you literally mean you passed the same object address that you previously removed? In response to your bus relations trickery, PnP is going to shut down and delete that device stack. The PDO won’t exist any more. You need to trigger the creation of a new one.
Well, first I do not understand why the utilities, like PnPDTest, don’t do what you need. I really don’t understand it.
If you want to “perfectly” emulate this, then do as Mr. Roddy suggested.
The approach implied in your list of issues does “perfectly” emulate this any more than PnPDTest does.
Peter
@Tim_Roberts said:
When you say “add deleted PDO”, do you literally mean you passed the same object address that you previously removed? In response to your bus relations trickery, PnP is going to shut down and delete that device stack. The PDO won’t exist any more. You need to trigger the creation of a new one.
Thank you for your reply! But device PDO created by usb-hub, and it continues existing after deleting from childs list on IRP_MN_QUERY_DEVICE_RELATIONS , and PnP manager destroy stack **above ** this PDO, and why I must create new PDO instead using existing PDO on usb-hub, why PnP manager carry about new or no it’s PDO?
Please correct me and explain about link PnP and PDO
The PnP contract is that the PDO is deleted after it is reported missing from QDR/BusRelations and it receives the IRP_MN_REMOVE_DEVICE. I bet if you turned on driver verifier for usbhub and your driver it would report the incorrect behavior. Having the PDO show up again is the hard part about being a bus filter since you want USBHUB to be the one to create the PDO and reuse all of its existing logic, but USBHUB doesn’t know that the PDO was even reported as missing by your driver, so still thinks the PDO is still a PDO and reported as present to PNP
1 Like
Ok, but usbhub responsible for creating and managing device PDO or not? And what principle problem to hide PDO from components above PDO stack and then show it again, if real hardware removing from PC doesn’t arise?
Oh, my God, save my mind…
It comes down to a very simple concept: the pnp manager has a state machine and set of rules the bus driver must follow. Usbhub is following the rules and has its own state machine for the PDO. When your filter removes the PDO, you creating a state change and hiding it from usbhub. Now usbhub’s state machine is out of sync with pnp manager’s state machine. UsbHub has no idea it should delete the PDO (according to its state machine, the PDO is still valid). There is no way for you to get them back in sync.
1 Like
Doron, thanx for much! And finally question : how I can triggering creation new PDO for existing hardware? Its possible or no way for me?
I don’t think you read Doron’s concluding statement:
There is no way for you to get them back in sync.
You do have the ability to create a new PDO, of course, but the UsbHub driver won’t know anything about it. It doesn’t know how to service devices it didn’t create. The result will be a BSOD.
The well-defined and well-supported way to do this is to disable and enable the device the way Device Manager and “devcon” do it. You have the source code for devcon that will show you how to use the SetupDi APIs to do this properly.
1 Like
Tim, thanx for clarification! But I won’t to disable/enable device by SetupDi functions, I trying FULL emulating physical remove/insert device from system on kernel level… Oh, I am saddened that this impossible on Windows pnp artichecture =(((( No way remove device pdo and again say to controller that device arrival… Pain and sorrow…
I think you need to read this thread again before saying that you are sad
But I won’t to disable/enable device by SetupDi functions, I trying FULL emulating physical remove/insert device from system on kernel level…
Why? If you’re trying to test your remove/insert handling, then you need to physically remove and insert the device. Nothing else will do. Simulations aren’t the same. There are USB hubs that have “disconnect” buttons for each port that let you do this without wearing out USB connectors, and believe me, they DO wear out.
Having said that, it is possible to communicate directly with the USB hub and instruct it to cycle power on one of its ports. The “usbview” sample in the WDK is an excellent example of the USB hub ioctl set.
1 Like
Pretty sure that IOCTL support for control of individual port power state was removed long ago.
IOCTL_INTERNAL_USB_CYCLE_PORT asks the hub to simulate a remove/reinsert. Not the same as actually cycling the power on the port, but has been stable for us from at least XP SP3.
1 Like
@MBond2 said:
I think you need to read this thread again before saying that you are sad
Why do you think so? I realized and realized my mistake about how pnp-arch works…