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/


Extra PDO

Tim_RobertsTim_Roberts Member - All Emails Posts: 13,490
I should know this.  Shame on me that I don't.

I'm doing a virtual audio driver, based on SYSVAD or MSVAD -- I have
prototypes with both.  I've tweaked the media-class INF files to
advertise my own hardware ID, let's call it ROOT\MyHardware.

When I install this using "devcon install", I get a PDO for
ROOT\MyHardware.  I also get a PDO for ROOT\MEDIA\0000.  Both of them
appear in Device Manager, and both of them get device instances.  The
sample happens to reject duplicate creates, so one of the two ends up
with a yellow bang.

I don't want two.  I only want one.  I don't care which one.  How do I
fix this?

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

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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    ROOT\MEDIA\0000 is an instance path, not a hardware ID. ROOT\MEDIA\0000 is actually the instance path for the first PDO enumerated by the ROOT enumerator in the MEDIA class.

    >I don't want two.?I only want one.?I don't care which one. How do I fix this?

    Let the second one go (do not fail the AddDevice and attach your FDO to the PDO's stack) but tell the PNP Manager that the hardware is gone with IoInvalidateDeviceState. You can try to set a flag in the device context, filter the IRP_MN_QUERY_PNP_DEVICE_STATE IRP sent by the PNP Manager after IoInvalidateDeviceState is called to indicate that the device has been removed (set the IRP's PNP_DEVICE_STATE to PNP_DEVICE_REMOVED).

    I had nether tried this, this is a suggestion. Good luck Mr Roberts.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,893
    Sorry... you're in the Audio stack Mr. Roberts. That means you're beyond me.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Sorry about the silly proposal I made Mr Roberts.

    PNP drivers must service ALL the devices that advertise a matching hardware ID. No segregation is allowed.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,490
    [email protected] wrote:
    > When I install this using "devcon install", I get a PDO for
    > ROOT\MyHardware.  I also get a PDO for ROOT\MEDIA\0000.  Both of them
    > appear in Device Manager, and both of them get device instances.  The
    > sample happens to reject duplicate creates, so one of the two ends up
    > with a yellow bang.

    I have the answer, thanks to Matthew on the Microsoft audio team, who,
    by the way, is a gem of a resource.

    The INF for the SYSVAD sample includes a [DeviceInstall32] section,
    which is not documented.  It turns out this section is designed for
    virtual drivers that do not have hardware.  It creates a new PDO for
    you.  It does basically what the "devcon install" function does.

    So, the fact that I used "devcon install" meant that I got TWO PDOs. 
    When your INF includes [DeviceInstall32], you need to use "pnputil -a".

    And now you know the rest of the story.

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

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

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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA