Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Attaching to devices in IRP_MN_QUERY_DEVICE_RELATIONS

Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 284

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 !

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,704

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,111

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 284

    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.

  • craig_howardcraig_howard Member Posts: 196

    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?

  • Martin_DrábMartin_Dráb Member - All Emails Posts: 86

    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.

    Martin Dráb

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 284

    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.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers 24 January 2022 Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online