Hi,
I wrote a filter driver that is used to display info abt URBs passed from a function driver to lower drivers, more specifically for USB devices. This is working fine but I wanted to display this info in a user mode application. Here i am facing some hurdles.
- How to make the application wait until a request(URB) is received by the filter?
For this, I use an IOCTL and in the filter, I was completing the IOCTL request only after a request was received. I set a flag in the default request event of the filter whenever it received a request and in the IOCTL routine, I was checking this flag in a loop.
I did requestComplete after this loop.
The problem now is that as I was sending the IOCTL using a seperate thread in the application, it somehow does not die after I close the application (I can see the exe in task manager). And when another request is sent to the filter, the thread dies.
I know this method is not gr8 but I also tried quite a few other methods but met with no success. Atleast the requests are printed when I use this method.
Plz suggest some other mechanism which I can use…Thanx in advance.
> I set a flag in the default request event of the filter whenever it received a request and
in the IOCTL routine, I was checking this flag in a loop. I did requestComplete after this loop.
Do you mean that your Dispatch() routine receives IOCTL, spins in a loop until the flag gets set, and
returns only after flag has been set??? If this is the case, you should not be surprized that your app cannot terminate. Unless a thread is in the user mode or in the waiting state with ‘UserMode’ specified as a WaitMode parameter, it just cannot get terminated - it can happen only when it returns to the user mode…
What you have to do here is to return STATUS_PENDING straight away, and call IOCompleteRequest() when the flag gets set. In any case, you don’t need a loop here…
Anton Bassov
Hi Anton,
Hmmm… But the thread is in the user mode.
It is created in the application and sends down IOCTLs repeatedly. As I was running a loop till the request flag was set and only then completing the IOCTL request, The thread in the user mode is essentially put on hold till the IOCTL has been completed.
Just to be clear here, a UserMode wait has other side affects that you
must account for. A driver should really never be using a UserMode wait
when waiting on a dispatcher object.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, May 16, 2007 4:08 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Sniffing filter driverand application issue
I set a flag in the default request event of the filter whenever it
received a request and
in the IOCTL routine, I was checking this flag in a loop. I did
requestComplete after this loop.
Do you mean that your Dispatch() routine receives IOCTL, spins in a loop
until the flag gets set, and
returns only after flag has been set??? If this is the case, you should
not be surprized that your app cannot terminate. Unless a thread is in
the user mode or in the waiting state with ‘UserMode’ specified as a
WaitMode parameter, it just cannot get terminated - it can happen only
when it returns to the user mode…
What you have to do here is to return STATUS_PENDING straight away, and
call IOCompleteRequest() when the flag gets set. In any case, you don’t
need a loop here…
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
karthik wrote:
For this, I use an IOCTL and in the filter, I was completing the
IOCTL request only after a request was received. I set a flag
in the default request event of the filter whenever it received
a request and in the IOCTL routine, I was checking this flag
in a loop.
You are making this way more complicated than it is.
-
IOCTLs from userspace to read out the contents of filtered URBs are immediately dispatched to a queue.
-
When an URB comes, see if there is an IOCTL waiting in the queue. If there is, pull it out, copy in the URB contents (or whatever), and then complete it.
> Hmmm… But the thread is in the user mode.
It is created in the application and sends down IOCTLs repeatedly. As I was
running a loop till the request flag was set and only then completing the IOCTL
request, The thread in the user mode is essentially put on hold till the IOCTL
has been completed.
Do you understand the difference between the kernel and the user modes??? Taking into account the above excerpt, I seriously doubt it…
Anton Bassov
Hi,
It somehow started working now… I guess I was making things too complex for my own good.
And Anton, Sorry man guess my knowledge is just too basic. Why I mentioned the thread as user mode is because it was created and running in the user mode…guess its not as simple as that. Plz excuse my ignorance.
Is there any place on the net where I can find some more info on tracking URBs???.. I wud really appreciate it.
Hi
Try Device Monitoring Studio… its a bit clunky but works ok, I think some
source is availble in… sniffusb… contains a filter driver and source.
This might help you
Steve
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, May 18, 2007 7:33 AM
Subject: RE:[ntdev] Sniffing filter driverand application issue
> Hi,
>
> It somehow started working now… I guess I was making things too complex
> for my own good.
>
> And Anton, Sorry man guess my knowledge is just too basic. Why I mentioned
> the thread as user mode is because it was created and running in the user
> mode…guess its not as simple as that. Plz excuse my ignorance.
>
> Is there any place on the net where I can find some more info on tracking
> URBs???.. I wud really appreciate it.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>