And why, @sunnywilson09, did you feel it necessary to copy Doron’s answer?
Mr. Sonnywilson09 was a spam bot… now banned, thanks to Mr. Vodika.
Peter
No way remove device pdo and again say to controller that device arrival… Pain and sorrow…
No way to use an address of some function’s local variable after the said functions returns… Pain and sorrow…
No way to use a pointer after having had passed it to a function that deallocates it… Pain and sorrow…
Anton Bassov
Just to get back to the original question, which seems to have
transmogrified from “How to emulate physical device removal/insertion” to
“How to force usbhub to remove a device that isn’t removed”, of course you
can emulate physical device removal insertion, you do it with a bus driver.
You could even sort of do it on top of usbhub by filtering all the bus
operations on the hub fdo, shadowing those pdos with your own in your own
bus driver, hiding the lower pdos from the rest of the world, and doing
your own thing. Of course you would also have to emulate a lot of what
usbhub is doing with those pdos.
Mark Roddy
1 Like
@anton_bassov said:
No way remove device pdo and again say to controller that device arrival… Pain and sorrow…
No way to use an address of some function’s local variable after the said functions returns… Pain and sorrow…
No way to use a pointer after having had passed it to a function that deallocates it… Pain and sorrow…
Anton Bassov
No, this is clearly from another Opera and not so trivial, because, in fact, no one deletes the PDO either physically or programmatically, and the USB hub thinks it exists, but as far as I understand syncing with the internal implementation of PNP-manager will break because it will think that the device is deleted…Technically, I still do not understand why it is impossible to return the same PDO in principle, because it is managed by the USB-hub, it did not delete it, did not clean it. Here the problem is only in the “dark matter” implementation of the internal PNP device in Windows…
@Mark_Roddy said:
Just to get back to the original question, which seems to have
transmogrified from “How to emulate physical device removal/insertion” to
“How to force usbhub to remove a device that isn’t removed”, of course you
can emulate physical device removal insertion, you do it with a bus driver.
You could even sort of do it on top of usbhub by filtering all the bus
operations on the hub fdo, shadowing those pdos with your own in your own
bus driver, hiding the lower pdos from the rest of the world, and doing
your own thing. Of course you would also have to emulate a lot of what
usbhub is doing with those pdos.Mark Roddy
Mark, but how can I emulate connecting a device? With deleting everything is clear, but the problem is in the reverse connection and here I have a dead end and a misunderstanding…In addition, in the most general case, we are talking not only about USB hardware but also about all peripheral interfaces
Well, you know the device is already there, right? So issue the IOCTL that @“Scott_Noone_(OSR)” mentioned above.
Peter
@“Peter_Viscarola_(OSR)” said:
Well, you know the device is already there, right? So issue the IOCTL that @“Scott_Noone_(OSR)” mentioned above.Peter
It’s not only usb devices, but firewire and other, what kind of IOCTL… are they exist? Not sure =(
It’s going to be specific to each bus.
Peter
It’s not only usb devices, but firewire and other, what kind of IOCTL… are they exist? Not sure =(
You have already been told that what you’re doing violates the Windows “contract”. You’re not going to find a general solution. USB happens to have a back door hack.
No, this is clearly from another Opera and not so trivial,
Not really, as we will see shortly…
because, in fact, no one deletes the PDO either physically or programmatically, and the USB hub thinks it exists,
…but PnP Manager does not know it, right. From PnP Manager’s perspective, the target device has been gone already, and, hence, has to be treated as such.
Technically, I still do not understand why it is impossible to return the same PDO in principle, because it is managed by the USB-hub,
it did not delete it, did not clean it.
Consider what happens if someone has a reference to the device on top of the stack, and PDO gets removed ( and, hence, the entire stack on top of it gets torn down). As long as its refcount is non-zero, this topmost device has to be present, although all the request to it have to
fail. of course. Now imagine the target PDO gets back to life, and the new stack gets setup on top of it.
Let’s look at the whole thing from the topmost driver’s perspective.At this point, it has two device objects related to exactly the same PDO. One of them is fully functional and is attached to the stack, and another one is permanently crippled and has to be gone when its refcount goes down to zero. If PDOs were “reused” all PnP drivers in existence would have to deal with the possibility of this scenario.
Taking into consideration that PnP is a fairly complex in itself, there is simply no need to add yet another complication…
Anton Bassov
@Alex_Funky said:
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!
I underwent a similar situation, where I wanted to test an ACPI PNP device, by auto insert/eject/surprise_remove etc from in a VM, to easily test functionality, as constantly removing it from the system board is cumbersome during dev. I got it all working using a bus driver.
From the Windows 7 7600 DDK, build the MsToaster project, install this root bus driver via devcon in your VM. Then that root bus driver can create fake ACPI devices of your choice (i.e. ACPI\PNP1234) and they’ll appear in the ACPI devtree (so you can see it in devmgr, in the VM) and the MsToaster can simulate insert/remove/surpriceremoval/etc on your device. And if you have your driver/INF installed registered on that devid ACPI\PNP1234, your device driver will get the simulated PNP events.
Of course from time to time check (without a vm) with real hardware to make sure things are still going smoothly and replicating correctly.
1 Like
It’s a great strategy for virtual devices and simple to execute with the toaster sample, but doesn’t enable surprise removal testing of devices actively using hardware resources or a bus protocol (like usb) unless your bus driver starts to emulate these buses (gets complicated fast)
1 Like
If your system under test is a VM, you should certainly be able to connect/disconnect USB devices to the VM. I’ve never tried to pass through firewire devices to a VM so not sure which if any VM software supports that or the other device types you want to control.