This is usually done when an audio device (typically in card form, not something on the motherboard) also has a non-audio feature (a game controller port is a common case, or it used to be). The driver creates a device object of its own to support this device, steals the IRP handlers back from the class driver, and then tries to support both drivers. Sometimes (even worse) I’m not sure they even create a separate device object, but are simply trying to roll their own upper filter device model. I’m not certain I’ve seen the latter, but once the technique is promoted in sample form, it’s difficult to stop creative extensions to it- that may be my own bit of hackery coming into play.
IMO, it was a poor choice to have ever done it this way, and the problem is exacerbated by illustrating it in a sample, but that choice goes back to the beginning of WDM at least, and (again IMO) we still had a bit to learn ourselves. I supported Portcls for a while, so I can tell you one price we pay is in crashes where the vendor’s driver gives us an IRP that we should never have seen because it isn’t ours. I remember creating a defense in depth mechanism for this [and worse than this, of course], but PortCls and KS are old stable code, and there just wasn’t a strong enough case to get it approved even by the owning Dev (I was a contractor at that time). I’d diagnosed and reported the problem from some crash somewhere, and was later assigned to fix it, so it seemed odd to then have it rejected, but hey- the pay’s the same whether I let it bother me or not, and I wasn’t being paid to make that decision. Just as a caution, though- that doesn’t mean this hasn’t been addressed since then. I’ve thought of better ways it could have been done since then, myself (some glaringly obvious in hindsight).
A better solution (as I’m sure any number of my colleagues would attest) would be for their card’s function driver to report a new PDO for their audio function, give it a HW ID, and provide a separate PortCls miniport driver for that. Both sides would be much happier over the long run, and could divert their attention to other pursuits.
Drivers that are doing this at DriverEntry have probably always done so, and have a fixed and known set of functions they support in that driver. Those that do it later have probably evolved their approaches to the point where they only hijack the dispatch entries if they know the card they are driving actually has devices where they have to do this (so they would be doing it at Start time). Some may do it at AddDevice time, perhaps- I can think of reasons someone might want to [not particularly good ones, just reasons]. It isn’t like the dispatch table can disappear or that it is write protected [maybe it should be after DriverEntry, but I bet something would break if that were tried].
If you do this, you should first of all note what dispatch entries PortCls is using, and you must replace ALL of them- otherwise you have left a hole where someone can dispatch traffic for your device straight to PortCls [which is where my previous ramble comes in]. Then when a request comes in, you should look at the device object, handle your own, and pass the rest off to Portcls through the original dispatch entries. If it’s for your device and you don’t want to handle that kind of IRP, then just complete it STATUS_INVALID_DEVICE_REQUEST (IIRC- hopefully someone will correct me if I got that or any of the rest of this wrong).
IIRC, this is what the sample shows- not sure it shows the first part [catching them all] or last part [what to return], though- been too long, and I haven’t the time to look it up for you.
One additional suggestion -if you search this list for “wdmaudiodev” you should turn up a URL for a mailing list where you stand a decent chance of getting a more direct (and probably more accurate) answer from the team that includes the current owners of PortCls.