Can someone tell me the difference or relation between/about IRP_MJ_DEVICE_CONTROL and IOCTL_KS_PROPERTY? Can I use IRP_MJ_DEVICE_CONTROL to overwrite an device io control then pass it down to IOCTL_KS_PROPERTY? Thanks for your advice.
Yong
xxxxx@gmail.com wrote:
Can someone tell me the difference or relation between/about IRP_MJ_DEVICE_CONTROL and IOCTL_KS_PROPERTY? Can I use IRP_MJ_DEVICE_CONTROL to overwrite an device io control then pass it down to IOCTL_KS_PROPERTY? Thanks for your advice.
I don’t quite understand your question. IOCTL_KS_PROPERTY is an ioctl,
and all ioctls are sent to drivers using the IRP_MJ_DEVICE_CONTROL IRP code.
So, when your application uses IKsProperty to send a property request,
the IKsProperty handler eventually calls DeviceIoControl with control
code set to IOCTL_KS_PROPERTY. The I/O manager creates an IRP from
that, since that it the only way to communicate with drivers. The IRP
has major code IRP_MJ_DEVICE_CONTROL (as do all calls through
DeviceIoControl).
The kernel streaming driver (ks.sys) gets that IRP in its DeviceControl
handler. It looks at the control code in the IRP, and sees it is
IOCTL_KS_PROPERTY. Because it has access to the KS filter and pin
structures, it pulls the fields out of the IRP structure and passes them
to the property handler for the AVStream miniport.
So, every IOCTL_KS_PROPERTY is transmitted via an IRP_MJ_DEVICE_CONTROL
IRP. Now, can you ask your question again?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, thank you very much for your reply. Waht you said confirm what I thought that IOCTL_KS_PROPERTY is a kind of IRP_MJ_DEVICE_CONTROL. Right now I am developing an virtual audio driver which comminicates with two user mode applications through KS property declared in filter descriptor. Since there are two applications, two filters are created. One application calls deviceiocontrol to send some data to driver, but those data attached with the filter created in this application. I want to pass those data to the other filter created in second application, but I could not get the handle the second filter. Since I used IOCTL_KS_PROPERTY, I got pointer to PCPROPERTY_REQUEST, which contained IRP, calling IoGetCurrentIrpStackLocation, I can get IO_STACK_LOCATION, then get device_object which contains nextdevice. Through those steps, I can get the device_object created in the second application, but I do not know how to convert the device_object to the filter(MajorTarget in PCPROPERTY_REQUEST structure), so that I can pass the data to the filter. Do you have any ideas or other ways to do that? Thanks in advance.
Yong
xxxxx@gmail.com wrote:
Tim, thank you very much for your reply. Waht you said confirm what I thought that IOCTL_KS_PROPERTY is a kind of IRP_MJ_DEVICE_CONTROL. Right now I am developing an virtual audio driver which comminicates with two user mode applications through KS property declared in filter descriptor. Since there are two applications, two filters are created. One application calls deviceiocontrol to send some data to driver, but those data attached with the filter created in this application. I want to pass those data to the other filter created in second application, but I could not get the handle the second filter. Since I used IOCTL_KS_PROPERTY, I got pointer to PCPROPERTY_REQUEST, which contained IRP, calling IoGetCurrentIrpStackLocation, I can get IO_STACK_LOCATION, then get device_object which contains nextdevice. Through those steps, I can get the device_object created in the second application, but I do not know how to convert the device_object to the filter(MajorTarget in PCPROPERTY_REQUEST structure), so that I can pass the data to the filter. Do you have any ideas or other ways to do that?
This is absolutely the wrong way to go about this. Remember, this is
all YOUR code. You don’t have to go to these kinds of tricks. If you
need to remember something to pass from one instance to another, just
store it in some driver-global flag or structure or list, and have the
second instance check for it when it gets a chance. If you absolutely
need to talk to a pin on another instance right now, and you know
there’s only going to be one such pin, just have the pin store a pointer
to itself in a global, and let the second instance refer to it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.