Attaching to devices in IRP_MN_QUERY_DEVICE_RELATIONS

Hello !

I have driver that registered as upper filter for USB bus (36fc9e60-c465-11cf-8056-444553540000).
In IRP_MN_QUERY_DEVICE_RELATIONS/BusRelations dispatch I attach to devices reported by bus with IoAttachDeviceToDeviceStack.
This works in practice.

My question is: is that approach theoretically valid considering Windows PnP architecture ?

Thank you !

So, you want to create a filter device that’s above the PDOs that are enumerated, irrespective of the device type? Is that what you’re doing?

I don’t see any problem with this, architecturally. Though there has been considerable discussion about this here over the years, and IIRC there were some caveats/issues. Maybe there’s somebody who remembers those discussions better than I do…

Peter

The issue is, what are you going to DO in this filter? Unless you understand the protocol for every possible device class, there’s almost nothing you can do generically when you’re in that position.

Thank you guys !

Point is to potentially “block” device by failing mn_start_device, nothing else.
This filter doesn’t do anything device-type specific.

Hmmm … attempting to rephrase from “how to keep the wings on the pig from falling off” to “I have a need for a flying pig for my company/ graduate thesis/ because I’m bored, what are some good ideas for doing that?” would a fair refactoring of your question be …

I would like to stop an arbitrary driver from starting, how would I accomplish that?

Intercepting messages to a driver and attempting to “block” them can be tricky, because the driver is (correctly) expecting messages to arrive and (correctly) expecting the OS to act on the return.

Take mn_start_device … if you intercept it before the driver ever gets it what will you return to the OS? If you return a failure code then the user sees a yellow bang and hilarity ensues. If you return a success code then the OS will send other stuff to the driver, same issue … same result if you let the driver complete the call and replace the success with a failure code …

Other drivers are part of a device stack, and it’s not going to end well if you start changing those load orders and codes … for instance, suppose that you intercept an mn_start for a usb hub device; you’ve now killed everything downstream of that hub …

Paraphrasing, a) what problem exactly are you trying to solve and b) is this for a commercially targeted product, or as a graduate/ boredom research project?

My question is: is that approach theoretically valid considering Windows PnP architecture ?

I do not think it is illegal, e.g. because ACPI.sys follows the same path AFAIK but you need to be careful when communicating with PDOs the filter is attached to. In the moment you receive completion of the IRP_MN_QUERY_DEVICE_RELATIONS request, the PnP manager still knows nothing about the reported PDOs, thus, an attempt to call a PnP function on such PDO easily leads to a bug check. For example, if you attempt to retrieve hardware/compatible ID for such PDO, the system may crash.

From my experience, especially display drivers are problematic in this regard. Generic USB drivers seem to be OK.

Thank you Martin !

I only do attach at QUERY_DEVICE_RELATIONS time and make actual decision about “blocking” at start_device, so I think i’m relatively safe.