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

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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/


Is there a way to call a WDM root-enumerated driver from another WDM PnP driver?

Timothy_JohnsonTimothy_Johnson Member Posts: 9

The WDM PnP driver was originally designed to be a bus enumerator for the serial ports of a USB to serial converter. Thus the serial ports are child devices of a USB device. The problem is that when the USB device is disconnected, the Device Manager removes the child devices (serial ports) and the application handle for an open serial port becomes invalid. I'd like to have a separate root-enumerated bus enumerator enumerate the serial ports so that if they (the serial ports) don't get removed when the USB to serial converter gets disconnected. Is there a way to call into the root-enumerated driver from the WDM PnP driver if the root-enumerated driver exports an interface?

Comments

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

    Sure. Why not have the enumerator register a device interface (IoRegisterDeviceInterface)? If you’re sure that the way you want to go.

    I just recently spent time considering this problem, so I’ll pass along a bit of a warning: Consider the fact that an app using the serial port can set/change various setting, and that these will be reset to their defaults when a device goes away and later returns. Seems to me you need some way to track these and re-establish them, no?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Timothy_JohnsonTimothy_Johnson Member Posts: 9

    Thanks, Peter. I was aware of the problem of having to save the serial port's state and restore it when it returns. So once the enumerator registers a device interface, how would I call it. I'm assuming there's some way of getting its device object and calling it with IoCallDriver?

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

    In the OTHER driver (the one that does NOT register the device interface), use IoRegisterPlugPlayNotification. That'll give you the PDEVICE_OBJECT that you can use to send IRPs.

    If you're going to write this second driver, I'd really recommend you use WDF... and you can STILL call IoRegisterPlugPlayNotification. Just create a Remote I/O Target using the returned DEVICE_OBJECT pointer.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Timothy_JohnsonTimothy_Johnson Member Posts: 9

    When the other driver calls IoRegisterPlugPlayNotification, will the callback be dispatched if the interface is already enabled? Or does it only callback when it changes? The reason I ask is that I'm planning to have the root-enumerated driver register an interface as soon as it starts. which could before the other driver calls IoRegisterPlugPlayNotification.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,551

    The doc page for IoRegisterPlugPlayNotification answers your question. Did you read it?

    d
  • Timothy_JohnsonTimothy_Johnson Member Posts: 9

    Thanks Doron. I read it over quite well (I thought) but missed it :(
    "Only valid with an EventCategory of EventCategoryDeviceInterfaceChange. If set, the PnP manager calls the driver callback routine for each device interface instance that is currently registered and active and registers the callback routine for future arrivals or removals of device interface instances."

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE