[wdmaudiodev] Re: Overriding IRP_MJ_DEVICE_CONTROL handling is possible?
- From: "Paul Gryting" <paul.gryting@xxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 9 Apr 2007 12:18:36 -0500
There is a non-standard way to put private interface into WDM audio driver.
(Its more of a hook)
In your DriverEntry, save the original IRP_MJ_DEVICE_IO_CONTROL function
pointer (or all of them), and replace with your own function(s).
Then in your dispatch handler(s) you can either process the IRP yourself and
complete it or call the original function, depending on whether the from
your private interface or not.
If you use IoRegisterDeviceInterface() you can check the
irpStack->FileObject.FileName parameter against the reference string passed
into IoRegisterDeviceInterface to see if IRP is from your private interface.
Pjg
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Don Bell
Sent: Monday, April 09, 2007 11:45 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Overriding IRP_MJ_DEVICE_CONTROL handling is
possible?
Tom, thank you so much for your reply - you have no idea how the "little"
tips that you provided here are helping me understand some fundamental
issues. I will use the context of your reply to explain how or why:
On 4/9/07, Tom Eckert <teckert@xxxxxxxxxxxxxxxx> wrote:
> I don't think you should be calling IoSkipCurrentIrpStackLocation()
> and
> IoCallDriver() to pass the call to portcls. The miniport is not an
> upper driver for portcls, actually portcls takes over your stack
> location so once you've hooked it back (by overwriting the portcls
> call in the MajorFunction
> table) this will actually re-enter your driver instead of calling
> portcls (and overrun the stack).
That is exactly what I was confused about. On one hand, the book that I have
("Writing Windows WDM Device Drivers" by Chris Cant) does an excellent job
in explaining the "assembly language" of WDM programming. On the other hand,
this could be very misleading when writing a miniport driver... as I will
soon explain in a very fundamental question that I will present further
down:
> Save the address of the IRP_MJ_DEVICE_CONTROL handler that portcls
> installs and call it directly when you've determined that the IRP is
> not from your app.
>
> PDRIVER_DISPATCH pPortClsDeviceControl;
>
> extern "C" NTSTATUS DriverEntry(
> IN PDRIVER_OBJECT DriverObject,
> IN PUNICODE_STRING RegistryPathName)
> {
> NTSTATUS ntStatus = PcInitializeAdapterDriver(
> DriverObject,
> RegistryPathName,
>
> (PDRIVER_ADD_DEVICE)AddDevice);
>
> if(NT_SUCCESS(ntStatus))
> {
> pPortClsDeviceControl =
> DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL];
> DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
> DeviceControlHandler; } return ntStatus; }
>
> and somewhere in DeviceControlHandler
> if(it's my IOCTL)
> status = HandleIt();
> else
> status= pPortClsDeviceControl(fdo,Irp);
That is very intuitive and makes a lot of sense. I should only ask myself
now: "Duh! How come I didn't see this before posting my question?"
> This approach works for us but it looks like PcDispatchIrp saves you
> the trouble of keeping a copy of the portcls handler so to use that
> just eliminate the pPortClsDeviceControl variable and call PcDispatchIrp
instead.
> Maybe someone from ms will want to chime in here if there's a reason
> why the PcDispatchIrp approach is better than simply calling the portcls
entry?
Indeed, this is an excellent question - which adds to my fundamental
question: How am I supposed to know that I should use PcDispatchIrp()
instead of the "manual approach"? Now that I know about it, I can find it in
WDK's reference section but... Isn't there a tutorial that provides a recipe
for such scenario (which I am sure is not rare)?
> You'll also need to create symbolic link to use in your user mode
> CreateFile call.
Thanks for this tip, too. I understand that this symbolic link should be
different than the one created by PortCls? Am I correct?
Lastly, do you know of any book that specializes in Audio device drivers?
Chris Cant's book is good but its main focus is on HID and USB device
drivers. I wish I had book that could "lead me by the hand"
as I am learning this exciting new field.
> Hope this helps,
> Tom
It really helps - thank you again!
Don
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
