Don
Tue Oct 16 09:32:20 PDT 2007
No, you don't store it on the stack. You take a bunch of IRP's and queue
them with a cancel safe queue, then when there is something to report you
complete the IRP with the data to report in the buffer associated with the
IRP. This is a very standard model for Windows drivers.
If you need to not loose an event, you may need to have a secondary queue
that can store event data if there is no IRP to satisfy the event when it
happens. But start with the above, an article on this model is at
http://www.osronline.com/article.cfm?id=94
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website:
http://www.windrvr.com
Blog:
http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Michael Harvey" <MichaelHarvey@discussions.microsoft.com> wrote in message
news:0EA25500-C4C6-45E1-9D88-D86330D08771@microsoft.com...
> That could work if I filter the notifications at the driver so only the
> important ones get sent, there won't be too many of them. Just have to
> figure
> out how to do it. I think it requires storing the notification on the
> stack
> and not in the driver extension, and figure out how to make the dispatch
> routine get it from the right place on the stack.
>
> "Doron Holan [MSFT]" wrote:
>
>> instead of a shared event, have the application pend mulitple requests at
>> the same time. this way you have a one to one relationship between an
>> "event" occurring in the driver and notifying the application.
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Michael Harvey" <MichaelHarvey@discussions.microsoft.com> wrote in
>> message
>> news:A87673E6-C799-4C90-8905-2EE2A04615F5@microsoft.com...
>> > Thanks, What I am really trying to do is slow down my driver enough so
>> > my
>> > user mode process can get all the notifications from KeSetEvent. Maybe
>> > a
>> > reasonable timer value will do most of the time, but I would prefer a
>> > guaranteed method.
>> >
>> > "Don Burn" wrote:
>> >
>> >> Because you specified 10 seconds after midnite in 1601 or any time
>> >> there
>> >> after for the thread to run again. The value has to be negative for a
>> >> 10
>> >> second relative delay. A lot of people use macros to simplify this,
>> >> see
>> >>
http://www.osronline.com/article.cfm?article=261
>> >>
>> >>
>> >> --
>> >> Don Burn (MVP, Windows DDK)
>> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> >> Website:
http://www.windrvr.com
>> >> Blog:
http://msmvps.com/blogs/WinDrvr
>> >> Remove StopSpam to reply
>> >>
>> >>
>> >> "Michael Harvey" <MichaelHarvey@discussions.microsoft.com> wrote in
>> >> message
>> >> news:489979A2-D937-4E3F-936A-91192BB85403@microsoft.com...
>> >> > Hi, why is this not waiting at all, there is no delay:
>> >> >
>> >> > LARGE_INTEGER x;
>> >> > NTSTATUS y;
>> >> > x.QuadPart = 100000000I64; // wait 10 seconds
>> >> > y = KeDelayExecutionThread( KernelMode, FALSE, &x);
>> >> >
>> >> > Here, y == STATUS_SUCCESS meaning the wait was completed, but it was
>> >> > not,
>> >> > and IRQL == PASSIVE_LEVEL.
>> >>
>> >>
>> >>
>>
>>