Usb Filter Driver

OSR_Community_User · October 24, 2006, 1:52pm

Hi!

I’m developing an application based on a driver supplied by Microchip
(mchpusb.sys) that’s developed by Walter Oney.

My applicaton now kinda works, but the problem is that the User mode
application can’t pool the Usb device in Real-time (for every frame on
1ms) so my buffer on the PIC18F4550 device gets overflowed all the time.
I just need to read from a Usb device more often.

I think that I must develop a filter driver that’s on top of this
function driver from Microchip and that I must reorganize the
IRP_MJ_READ packets so I created a timer that will send an IRP_MJ_READ
down every one msec and store the data in the buffer. And for every
IRP_MJ_READ that I handle from the user mode app I will send the data
from this buffer.

The problem is that the function driver from Microchip crashes when I
send an IRP_MJ_READ in the timer routine :::

LARGE_INTEGER Offset;
Offset.HighPart = Offset.LowPart = 0;
KEVENT Event;
KeInitializeEvent(&Event,NotificationEvent,FALSE);
IO_STATUS_BLOCK ioStatus;
PIRP Irp = IoBuildSynchronousFsdRequest(IRP_MJ_READ,
pdx->LowerDeviceObject, pdx->ReadBuff, 64, &Offset, &Event, &ioStatus);
if (Irp==NULL) {
return;
}

NTSTATUS ntStatus = IoCallDriver(pdx->LowerDeviceObject, Irp);

if(ntStatus == STATUS_PENDING) {
ntStatus = KeWaitForSingleObject(&Event, Executive, KernelMode,
FALSE, NULL);
}

The user mode handles are created with
\?\usb#vid_1111&pid_1111#000#{5354fa28-6d14-4e35-a1f5-75bb54e6030f}/MCH
P_EP1
Where the MCHP_EP1 stands for end point 1 of the Usb device.

Do I need to remember something in the handle from IRP_MJ_CREATE and use
that in creation on the new IRP_MJ_READ?

What am I doing wrong?
Will this function driver even work?

Martin

Tim_Roberts · October 24, 2006, 3:06pm

Martin Bergant wrote:

I’m developing an application based on a driver supplied by Microchip
(mchpusb.sys) that’s developed by Walter Oney.

My applicaton now kinda works, but the problem is that the User mode
application can’t pool the Usb device in Real-time (for every frame on
1ms) so my buffer on the PIC18F4550 device gets overflowed all the time.
I just need to read from a Usb device more often.

Then use overlapped I/O and submit multiple read requests from your
application. That’s a lot simpler and a hell of a lot easier to debug
than writing a filter driver.

I think that I must develop a filter driver that’s on top of this
function driver from Microchip and that I must reorganize the
IRP_MJ_READ packets so I created a timer that will send an IRP_MJ_READ
down every one msec and store the data in the buffer. And for every
IRP_MJ_READ that I handle from the user mode app I will send the data
from this buffer.

If you do end up going down this path, you do NOT need a timer. Just
submit a bunch of IRPs at once. The host controller will complete them
when data is available.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

David_J_Craig · October 24, 2006, 3:19pm

You can’t do that. Timer DPCs are DPCs and do not run at PASSIVE_LEVEL.

“Martin Bergant” wrote in message
news:xxxxx@ntdev…
> Hi!
>
> I’m developing an application based on a driver supplied by Microchip
> (mchpusb.sys) that’s developed by Walter Oney.
>
> My applicaton now kinda works, but the problem is that the User mode
> application can’t pool the Usb device in Real-time (for every frame on
> 1ms) so my buffer on the PIC18F4550 device gets overflowed all the time.
> I just need to read from a Usb device more often.
>
>
> I think that I must develop a filter driver that’s on top of this
> function driver from Microchip and that I must reorganize the
> IRP_MJ_READ packets so I created a timer that will send an IRP_MJ_READ
> down every one msec and store the data in the buffer. And for every
> IRP_MJ_READ that I handle from the user mode app I will send the data
> from this buffer.
>
> The problem is that the function driver from Microchip crashes when I
> send an IRP_MJ_READ in the timer routine :::
>
> LARGE_INTEGER Offset;
> Offset.HighPart = Offset.LowPart = 0;
> KEVENT Event;
> KeInitializeEvent(&Event,NotificationEvent,FALSE);
> IO_STATUS_BLOCK ioStatus;
> PIRP Irp = IoBuildSynchronousFsdRequest(IRP_MJ_READ,
> pdx->LowerDeviceObject, pdx->ReadBuff, 64, &Offset, &Event, &ioStatus);
> if (Irp==NULL) {
> return;
> }
>
> NTSTATUS ntStatus = IoCallDriver(pdx->LowerDeviceObject, Irp);
>
> if(ntStatus == STATUS_PENDING) {
> ntStatus = KeWaitForSingleObject(&Event, Executive, KernelMode,
> FALSE, NULL);
> }
>
> The user mode handles are created with
> \?\usb#vid_1111&pid_1111#000#{5354fa28-6d14-4e35-a1f5-75bb54e6030f}/MCH
> P_EP1
> Where the MCHP_EP1 stands for end point 1 of the Usb device.
>
> Do I need to remember something in the handle from IRP_MJ_CREATE and use
> that in creation on the new IRP_MJ_READ?
>
> What am I doing wrong?
> Will this function driver even work?
>
> Martin
>
>

OSR_Community_User · October 24, 2006, 5:01pm

“The problem is that the function driver from Microchip crashes when I
send an IRP_MJ_READ in the timer routine”

Let me guess: you are executing at DISPATCH_LEVEL at this point in time.
First you need to be running at PASSIVE_LEVEL to call
IoBuildSynchronousFsdRequest, then you need to be running at <
DISPATCH_LEVEL to wait for a pending io request to complete, and having
fixed those problems, you are probably violating assumptions on the part
of the read dispatch routine below you about what IRQL it is called at
as well.

As to your other question, Oney’s driver may or may not care about the
FileObject passed in the IRP, probably not, but it may very well care
about the IRQL it gets called at.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Bergant
Sent: Tuesday, October 24, 2006 3:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Usb Filter Driver