On 10/5/2011 11:28 PM, Jose M Robles wrote:

Hi again,
>I've had similar problems when using the filter driver over a mouse; but
>it wasn't always reproducible and not as noticeable because moving the
>mouse would unlock it.  Try shutting your PC completely down and
>disconnecting all of your hubs from power.
>
In this case, maybe it's necessary do a PoCallDriver before? Another power-state related function?

Only one driver in the stack can be the power policy owner.  If more than one driver tries to manage power then a BSOD occurs.
Because of the way the filter driver is injected into the driver stack amongst other foreign USB drivers, it cannot attempt to manage power.

This might be worth a try, and it does not always blue screen;  Whether is causes problems or not depends on lower drivers. (mainly a function driver sitting directly underneath)
At any-rate, this it is not something we could add to the release binaries without a high potential for causing BSODs.  ;)

Although, now I tend to think that this is not the problem, in my experience the request immediately fails in this situation.

   
>The problem here is most likely caused by another driver in the stack
>blocking all requests until "something" that it is waiting for happens.
>Remember that the filter driver must try and work alongside the original
>driver(s) simultaneously.  It could also be that the device is in a
>suspended (power managed) state.
>

But I don't understand why IoCallDriver no return, is an async func no?

Usually, but that would greatly depend on the drivers underneath.  What actually happens is it passes the IRP to the next lower driver.  It is up to the drivers underneath if the request is handled asynchronously or synchronously and the drivers above must be ready for both.

>The filter driver is not 100% reliable which is why we do not recommend
>it for anything beyond experimenting and proof of concepts.
>
So that, what could I do to make the application aware of the snapshot button event? Is it possible install a hook via SetWindowsHookEx?

I don't know.  Maybe claim the interface from a different thread so it doesn't deadlock your application.  When the thread exits, then you know the button has been pressed and your ready to go.

I don't see what SetWindowsHookEx could do for you.  That is a user level function.  Maybe the original driver does something that is detectable from user mode via a windows hook?

Don't use the filter driver. ;)  Use the inf-wizard to install libusb-win32 as the one-and-only function driver and this problem will go away.

>Have you tried installing the filter driver on the individual interfaces
>instead of the composite parent?
>What is hhdusbh32?

It's a commercial usb sniffer. I removed it now, but the problem is the same.
They are two possible hooks for the filter:

       vid:eb1a pid:2571 rev:0624                           Composite device    (Usbccgp lower driver)
       vid:eb1a pid:2571 rev:0624 mii:00                 Video device           (usbvideo lower driver)

 Same results with both options, so I think that the problem is with usbvideo.sys no?
 Do you know how to view the driver stack?

libusb-win32 debug builds will report the drivers underneath when the device is connected. (AttachedDevice)
The device manager will show all the drivers of a device.

Regards,
Travis