How Access SRB buffer data in filter driver?

How Access SRB buffer data in filter driver?

I'm writing a upper filter driver to a stream minidriver (DDK sample -
testcap.sys in my project) and try to
modify the stream data in the filter.
I write my filter based on the document :
http://www.cswl.com/whiteppr/tech/wdm.html
But how can I access the buffer data in the filter driver?

Any suggestion would be apprieciated, and thank you in advance.

Here's something about my idea.

in minidriver, I find the srb has the irp point:
0: kd> ??*pSrb (0x81921c78 struct _HW_STREAM_REQUEST_BLOCK *)
struct _HW_STREAM_REQUEST_BLOCK
+0x000 SizeOfThisPacket : 0x4c
+0x004 Command : 0 ( SRB_READ_DATA )
....
+0x018 CommandData : _CommandData
union _CommandData
+0x000 DataBufferArray : 0x81c038f8 (KSSTREAM_HEADER)
+0x000 StreamBuffer : 0x81c038f8
+0x000 .......
+0x01c NumberOfBuffers : 1
+0x020 TimeoutCounter : 0xf
+0x024 TimeoutOriginal : 0xf
+0x028 NextSRB : (null)
+0x02c Irp : 0x81f2a008
+0x030 Flags : 3
.....

and in the irp, I found the Irp->AssociatedIrp->SystemBuffer has the same
value with the pSrb->CommandData
(KSSTREAM_HEADER):
0: kd> ??*pSrb->Irp
struct _IRP
+0x000 Type : 6
+0x002 Size : 0x190
........
+0x00c AssociatedIrp : __unnamed
0: kd> ??pSrb->Irp->AssociatedIrp
union __unnamed
+0x000 MasterIrp : 0x81c038f8
+0x000 IrpCount : -2118108936
+0x000 SystemBuffer : 0x81c038f8
+0x010 ThreadListEntry : _LIST_ENTRY [ 0x81c275c8 - 0x821da018 ]
+0x018 IoStatus : _IO_STATUS_BLOCK
+0x020 RequestorMode : 1 ''

so I ajudge that Irp->AssociatedIrp->SystemBuffer is the stream data buffer,
but I found that when minidriver
complete the SRB (calling
StreamClassStreamNotification(StreamRequestComplete, ...)), the stream class
driver
(I took it for granted as I used "ba" command in Windbg)change the value of
pSrb->CommandData.Data. so in the
complete routine in filter driver, the stream data buffer can't access.

AndyCao
Thu Aug 11 04:08:46 CDT 2005

I have tried an alterative method:
I save the data buffer in the stream extension before the testcap call
StreamClassStreamNotification to
complete current SRB:
typedef struct _STREAMEX {
...
PULONG pImageBuf;
}
PKSSTREAM_HEADER pDataPacket = pSrb->CommandData.DataBufferArray;
...
pStreamEx->pImagebuf = pDataPacket->Data;
CompleteStreamSRB(pSrb);

but I found out the data buffer is refused to access in my filter driver's
complete routine:
FilterIoCtrlCompleteRoutine(...)
{
PHW_STREAM_REQUEST_BLOCK pSrb;
PSTREAMEX pStrmEx;
...
ControlCode = IrpStack->Parameters.DeviceIoControl.IoControlCode;
switch(ControlCode)
{
case IOCTL_KS_READ_STREAM:
pSrb = (PHW_STREAM_REQUEST_BLOCK)Irp->Tail.CompletionKey;
pStrmEx= (PSTREAMEX)pSrb->StreamObject->HwStreamExtension;
pSysBuffer = pStrmEx->pImageBuf;
ModifyDataBuffer(pSysBuffer);
break;
}
...
}
ModifyDataBuffer(pSysBuffer)
{
__try
{
ProbeForWrite(pBuf, (yBottom - yTop) * biWidthBytes, 1);

//modify buffer here
...

}
__except(EXCEPTION_EXECUTE_HANDLER)
{
status = GetExceptionCode();
PrintError(status);
}

}

in ModifyDataBuffer(), exception=STATUS_ACCESS_VIOLATION is received
if I didn't call ProbeForWrite() to checked the exception, the data will be
successfully modified but it
may result in blue screen when close the Amcap.exe.

Max
Mon Aug 15 13:13:29 CDT 2005

Why in the world would you do something like this?
What exactly are you trying to achieve?

You do understand that this "technique" of accessing device extension can
only "work" for your own driver, i.e. the driver for which you know the
layout of the device extension. Right?
If you own the driver that you want to filter there might be a much easier
way to modify the bits that the device sends out.

In KS world the easiest way would be to write a DShow filter to sits
downstream from your driver to do this.
Alternatively you could have registered a companion driver that would do
data modifications without resorting to these ugly hacks.

-- Max.



"Andy Cao" <AndyCao@discussions.microsoft.com> wrote in message
news:90B6B6EE-40A6-4BC9-9037-75F6F0D06807@microsoft.com...
>I have tried an alterative method:
> I save the data buffer in the stream extension before the testcap call
> StreamClassStreamNotification to
> complete current SRB:
> typedef struct _STREAMEX {
> ...
> PULONG pImageBuf;
> }
> PKSSTREAM_HEADER pDataPacket = pSrb->CommandData.DataBufferArray;
> ...
> pStreamEx->pImagebuf = pDataPacket->Data;
> CompleteStreamSRB(pSrb);
>
> but I found out the data buffer is refused to access in my filter driver's
> complete routine:
> FilterIoCtrlCompleteRoutine(...)
> {
> PHW_STREAM_REQUEST_BLOCK pSrb;
> PSTREAMEX pStrmEx;
> ...
> ControlCode = IrpStack->Parameters.DeviceIoControl.IoControlCode;
> switch(ControlCode)
> {
> case IOCTL_KS_READ_STREAM:
> pSrb = (PHW_STREAM_REQUEST_BLOCK)Irp->Tail.CompletionKey;
> pStrmEx= (PSTREAMEX)pSrb->StreamObject->HwStreamExtension;
> pSysBuffer = pStrmEx->pImageBuf;
> ModifyDataBuffer(pSysBuffer);
> break;
> }
> ...
> }
> ModifyDataBuffer(pSysBuffer)
> {
> __try
> {
> ProbeForWrite(pBuf, (yBottom - yTop) * biWidthBytes, 1);
>
> //modify buffer here
> ...
>
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> status = GetExceptionCode();
> PrintError(status);
> }
>
> }
>
> in ModifyDataBuffer(), exception=STATUS_ACCESS_VIOLATION is received
> if I didn't call ProbeForWrite() to checked the exception, the data will
> be
> successfully modified but it
> may result in blue screen when close the Amcap.exe.
>

AndyCao
Wed Aug 17 00:54:01 CDT 2005

Thank you, Max

"Max Paklin" wrote:

> Why in the world would you do something like this?
> What exactly are you trying to achieve?

We want to add some special effect (decrease noisy, for example) on data
eceived from our minidriver.

>
> You do understand that this "technique" of accessing device extension can
> only "work" for your own driver, i.e. the driver for which you know the
> layout of the device extension. Right?
> If you own the driver that you want to filter there might be a much easier
> way to modify the bits that the device sends out.

We have several different minidrivers and we'll develop more relative driver
in the future. We thought filter driver is more independance solution.

>
> In KS world the easiest way would be to write a DShow filter to sits
> downstream from your driver to do this.

We wouldn't choose a DShow filter solution because DShow filter is used in
User Mode, but we hope our special effect would work in the third-party
application.

> Alternatively you could have registered a companion driver that would do
> data modifications without resorting to these ugly hacks.



>
> -- Max.

Max
Wed Aug 17 14:45:38 CDT 2005

Filter drivers for KS are not supported.
Still you can make one work (and we did and it worked), but it is subject to
breaking with any OS spin. As usual. So don't go down that road unless there
is no other way.

I'd suggest you implement a kernel mode DLL with an entry point for your
data post processing stuff. Then call that routine from all of your drivers.
You can even add some parameters to it on what algorithm to invoke and have
those parameters stored in registry on per device basis.

-- Max.



"Andy Cao" <AndyCao@discussions.microsoft.com> wrote in message
news:C3145E70-D4FF-4210-A839-D0FD1E457FB4@microsoft.com...
> Thank you, Max
>
> "Max Paklin" wrote:
>
>> Why in the world would you do something like this?
>> What exactly are you trying to achieve?
>
> We want to add some special effect (decrease noisy, for example) on data
> eceived from our minidriver.
>
>>
>> You do understand that this "technique" of accessing device extension can
>> only "work" for your own driver, i.e. the driver for which you know the
>> layout of the device extension. Right?
>> If you own the driver that you want to filter there might be a much
>> easier
>> way to modify the bits that the device sends out.
>
> We have several different minidrivers and we'll develop more relative
> driver
> in the future. We thought filter driver is more independance solution.
>
>>
>> In KS world the easiest way would be to write a DShow filter to sits
>> downstream from your driver to do this.
>
> We wouldn't choose a DShow filter solution because DShow filter is used in
> User Mode, but we hope our special effect would work in the third-party
> application.
>
>> Alternatively you could have registered a companion driver that would do
>> data modifications without resorting to these ugly hacks.
>
>
>
>>
>> -- Max.
>

AndyCao
Mon Aug 22 04:34:18 CDT 2005

Thank you, Max.
I'll adopt your suggest of "Kernel DLL" later. And I'll try to do it in
filter since it can work, as you said in your response. But I do not
understand "OS Spin", if "Os spin" break the filter, will it comes up system
crash? I'm new in driver develop, thanks for your patience.

"Max Paklin" wrote:

> Filter drivers for KS are not supported.
> Still you can make one work (and we did and it worked), but it is subject to
> breaking with any OS spin. As usual. So don't go down that road unless there
> is no other way.
>
> I'd suggest you implement a kernel mode DLL with an entry point for your
> data post processing stuff. Then call that routine from all of your drivers.
> You can even add some parameters to it on what algorithm to invoke and have
> those parameters stored in registry on per device basis.
>
> -- Max.

Max
Mon Aug 22 12:13:00 CDT 2005

Yes, it could.
Basically what you have to do is to reverse engineering internal OS
structures and the protocol of communication between ksproxy.ax and ks.sys.
This is undocumented and subject to change. When it changes your driver can
fail to perform its task or can crash the system because something that it
counts on is not there.

You are a newbie and this is not the task that you would want to undertake.
Believe me, I've seen my fellow coworked (who is an excellent engineer and
an experience KS developer) struggle for months to get this thing work
reliably. Eventually he got to the point of being able to demo his audio
filter driver (the one that filter KS audio miniports) working well on an
existing OS version. At the same time he said that he would never put that
thing in a commercial product.

-- Max.



"Andy Cao" <AndyCao@discussions.microsoft.com> wrote in message
news:E3B7CCC1-FA6F-4CC0-AC1A-428C7FB04ECE@microsoft.com...
> Thank you, Max.
> I'll adopt your suggest of "Kernel DLL" later. And I'll try to do it in
> filter since it can work, as you said in your response. But I do not
> understand "OS Spin", if "Os spin" break the filter, will it comes up
> system
> crash? I'm new in driver develop, thanks for your patience.
>
> "Max Paklin" wrote:
>
>> Filter drivers for KS are not supported.
>> Still you can make one work (and we did and it worked), but it is subject
>> to
>> breaking with any OS spin. As usual. So don't go down that road unless
>> there
>> is no other way.
>>
>> I'd suggest you implement a kernel mode DLL with an entry point for your
>> data post processing stuff. Then call that routine from all of your
>> drivers.
>> You can even add some parameters to it on what algorithm to invoke and
>> have
>> those parameters stored in registry on per device basis.
>>
>> -- Max.
>