Safe to block DeviceAdd from class upper filter? RRS feed

  • Question

  • Hi,

    I have a WPD upper class filter that conditionally filters devices and supports no access, read-only access etc.  I currently use a custom device interface (WdfDeviceCreateDeviceInterface) which a user-mode app uses to set the desired action for each device.

    However at the moment this is reactive as the user mode app waits for appropriate "new device" messages and then prompts the user (the first time the device is seen) and then enforces their choice.  Whilst this is occuring we don't block access to the device.

    So my question is would it be safe to block (e.g. wait on an event) the KMDF DeviceAdd callback until an action has been set?  If not, what other choices do I have? 

    Another issue we have is how can the driver know whether the user mode app is running (so it knows to wait)?  I thought of adding a sideband control device object but I not really sure how this can work because the driver is only loaded by the pnp manager on the first device attachment, so deviceadd may be called before the app has had a chance to connect.  I could see this might work if we could change the starttype to system but I'm not sure if this is safe with the pnp manager, e.g. would it still attempt to unload the driver when the last device is removed.

    Any help appreciated.

    • Edited by SpecWin Monday, March 10, 2014 4:11 PM
    Monday, March 10, 2014 4:06 PM


  • you can't block AddDevice. The interface you create won't be visible until AddDevice and a pnp start for the entire stack has been successfully completed. A sideband control device object works around the issue of being able to communicate with the driver before AddDevice has finished. There is no way to know that the user app is running, I would suggest a wait with a timeout.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, March 10, 2014 4:44 PM