Dpcs and Synchronisation

I have never figured this out properly and it’s getting me into
trouble…

My driver maintains a list of events that are triggered by Xen, via my
Isr. My child drivers ask to bind to these events which could be either
as a Dpc, or at DIRQL (where they probably create their own Dpcs
anyway). The bus driver Isr checks to see what type of event is wanted
and either just calls the service routine directly or schedules a Dpc
that calls the service routine.

The problem comes at teardown (eg driver unload or hibernation).
KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
can I be sure that the Dpc is not currently being executed?
KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
overkill, and isn’t available under Windows 2000 either. The latter
objection is not really a concern for me as my driver doesn’t work under
2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
really completely finished and I can destroy the KDPC structure…

Thanks

James

Well, this is a tough one. You could increment a count (protected by a lock) when you get into your DPC routine and your cleanup code could check the count, the problem is that there could be a situation where your DPC has just been removed from the queue but before it has incremented the count, it gets interrupted. So I suppose you could delay a little while and recheck the count, with the hope that the DPC has resumed execution and incremented the count. Off the top of my head I can’t think of a way to close that execution window…

–Mark Cariddi
OSR, Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Wednesday, February 17, 2010 4:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Dpcs and Synchronisation

I have never figured this out properly and it’s getting me into
trouble…

My driver maintains a list of events that are triggered by Xen, via my
Isr. My child drivers ask to bind to these events which could be either
as a Dpc, or at DIRQL (where they probably create their own Dpcs
anyway). The bus driver Isr checks to see what type of event is wanted
and either just calls the service routine directly or schedules a Dpc
that calls the service routine.

The problem comes at teardown (eg driver unload or hibernation).
KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
can I be sure that the Dpc is not currently being executed?
KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
overkill, and isn’t available under Windows 2000 either. The latter
objection is not really a concern for me as my driver doesn’t work under
2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
really completely finished and I can destroy the KDPC structure…

Thanks

James


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

The only way to do it is either with Mark’s suggestion – which would work fine – or just use KeFlushQueuedDpcs. I’m not sure what your objection to the latter is… you’re driver’s exiting, so if you wait even for a few milliseconds (and THAT would be a LOT of DPCs) that shouldn’t cause a problem.

Peter
OSR

I’m always curious if objections like “KeFlushQeuedDpcs is overkill”
are based on actual data, or just philosophical disagreement.

The homegrown mecahanisms are frought with race conditions and
heuristics due to lack of access to the synchronization primitives
required to do this correctly.

Mark Roddy

On Wed, Feb 17, 2010 at 1:05 AM, James Harper
wrote:
> I have never figured this out properly and it’s getting me into
> trouble…
>
> My driver maintains a list of events that are triggered by Xen, via my
> Isr. My child drivers ask to bind to these events which could be either
> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> anyway). The bus driver Isr checks to see what type of event is wanted
> and either just calls the service routine directly or schedules a Dpc
> that calls the service routine.
>
> The problem comes at teardown (eg driver unload or hibernation).
> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> can I be sure that the Dpc is not currently being executed?
> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> overkill, and isn’t available under Windows 2000 either. The latter
> objection is not really a concern for me as my driver doesn’t work under
> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> really completely finished and I can destroy the KDPC structure…
>
> Thanks
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:

I have never figured this out properly and it’s getting me into
trouble…

My driver maintains a list of events that are triggered by Xen, via my
Isr. My child drivers ask to bind to these events which could be either
as a Dpc, or at DIRQL (where they probably create their own Dpcs
anyway). The bus driver Isr checks to see what type of event is wanted
and either just calls the service routine directly or schedules a Dpc
that calls the service routine.

The problem comes at teardown (eg driver unload or hibernation).
KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
can I be sure that the Dpc is not currently being executed?
KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
overkill, and isn’t available under Windows 2000 either. The latter
objection is not really a concern for me as my driver doesn’t work under
2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
really completely finished and I can destroy the KDPC structure…

I solved this by using a reference counter and an event. Increment the
reference counter prior to queueing the DPC, then decrement in the DPC.
When the counter goes to zero, set the event.

Interested parties wait on the event.

Ping me if you want to see the code.

Best,
-PWM

Thanks

James


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Um, aren’t you still in the dpc when the count goes to zero?

On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> I have never figured this out properly and it’s getting me into
>> trouble…
>>
>> My driver maintains a list of events that are triggered by Xen, via my
>> Isr. My child drivers ask to bind to these events which could be either
>> as a Dpc, or at DIRQL (where they probably create their own Dpcs
>> anyway). The bus driver Isr checks to see what type of event is wanted
>> and either just calls the service routine directly or schedules a Dpc
>> that calls the service routine.
>>
>> The problem comes at teardown (eg driver unload or hibernation).
>> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
>> can I be sure that the Dpc is not currently being executed?
>> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
>> overkill, and isn’t available under Windows 2000 either. The latter
>> objection is not really a concern for me as my driver doesn’t work under
>> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
>> really completely finished and I can destroy the KDPC structure…
>>
>
> I solved this by using a reference counter and an event. ?Increment the
> reference counter prior to queueing the DPC, then decrement in the DPC.
> When the counter goes to zero, set the event.
>
> Interested parties wait on the event.
>
> Ping me if you want to see the code.
>
> Best,
> -PWM
>
>
>> Thanks
>>
>> James
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>


Mark Roddy

If you are using KMDF, we do manage the rundown of WDFDPCs for you on device removal. James, why do you need to rundown the DPCs on hibernate?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, February 17, 2010 7:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dpcs and Synchronisation

Um, aren’t you still in the dpc when the count goes to zero?

On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> I have never figured this out properly and it’s getting me into
>> trouble…
>>
>> My driver maintains a list of events that are triggered by Xen, via my
>> Isr. My child drivers ask to bind to these events which could be either
>> as a Dpc, or at DIRQL (where they probably create their own Dpcs
>> anyway). The bus driver Isr checks to see what type of event is wanted
>> and either just calls the service routine directly or schedules a Dpc
>> that calls the service routine.
>>
>> The problem comes at teardown (eg driver unload or hibernation).
>> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
>> can I be sure that the Dpc is not currently being executed?
>> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
>> overkill, and isn’t available under Windows 2000 either. The latter
>> objection is not really a concern for me as my driver doesn’t work under
>> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
>> really completely finished and I can destroy the KDPC structure…
>>
>
> I solved this by using a reference counter and an event. ?Increment the
> reference counter prior to queueing the DPC, then decrement in the DPC.
> When the counter goes to zero, set the event.
>
> Interested parties wait on the event.
>
> Ping me if you want to see the code.
>
> Best,
> -PWM
>
>
>> Thanks
>>
>> James
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>


Mark Roddy


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:

Um, aren’t you still in the dpc when the count goes to zero?

Yes. The last executable code in the DPC would be to set the event.

-PWM

On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> >> I have never figured this out properly and it’s getting me into
> >> trouble…
> >>
> >> My driver maintains a list of events that are triggered by Xen, via my
> >> Isr. My child drivers ask to bind to these events which could be either
> >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> >> anyway). The bus driver Isr checks to see what type of event is wanted
> >> and either just calls the service routine directly or schedules a Dpc
> >> that calls the service routine.
> >>
> >> The problem comes at teardown (eg driver unload or hibernation).
> >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> >> can I be sure that the Dpc is not currently being executed?
> >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> >> overkill, and isn’t available under Windows 2000 either. The latter
> >> objection is not really a concern for me as my driver doesn’t work under
> >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> >> really completely finished and I can destroy the KDPC structure…
> >>
> >
> > I solved this by using a reference counter and an event. Increment the
> > reference counter prior to queueing the DPC, then decrement in the DPC.
> > When the counter goes to zero, set the event.
> >
> > Interested parties wait on the event.
> >
> > Ping me if you want to see the code.
> >
> > Best,
> > -PWM
> >
> >
> >> Thanks
> >>
> >> James
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>

Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Peter W. Morreale
Sent: Wednesday, February 17, 2010 9:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> Um, aren’t you still in the dpc when the count goes to zero?

Yes. The last executable code in the DPC would be to set the event.

-PWM

>
>
> On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> >> I have never figured this out properly and it’s getting me into
> >> trouble…
> >>
> >> My driver maintains a list of events that are triggered by Xen, via my
> >> Isr. My child drivers ask to bind to these events which could be either
> >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> >> anyway). The bus driver Isr checks to see what type of event is wanted
> >> and either just calls the service routine directly or schedules a Dpc
> >> that calls the service routine.
> >>
> >> The problem comes at teardown (eg driver unload or hibernation).
> >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> >> can I be sure that the Dpc is not currently being executed?
> >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> >> overkill, and isn’t available under Windows 2000 either. The latter
> >> objection is not really a concern for me as my driver doesn’t work under
> >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> >> really completely finished and I can destroy the KDPC structure…
> >>
> >
> > I solved this by using a reference counter and an event. Increment the
> > reference counter prior to queueing the DPC, then decrement in the DPC.
> > When the counter goes to zero, set the event.
> >
> > Interested parties wait on the event.
> >
> > Ping me if you want to see the code.
> >
> > Best,
> > -PWM
> >
> >
> >> Thanks
> >>
> >> James
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:

Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.

d

I’m waiting in pause/halt/unload. You best not remove my text while I’m
still alive.

Thx
-PWM

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Peter W. Morreale
> Sent: Wednesday, February 17, 2010 9:02 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Dpcs and Synchronisation
>
>
> On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > Um, aren’t you still in the dpc when the count goes to zero?
>
> Yes. The last executable code in the DPC would be to set the event.
>
> -PWM
>
> >
> >
> > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > >> I have never figured this out properly and it’s getting me into
> > >> trouble…
> > >>
> > >> My driver maintains a list of events that are triggered by Xen, via my
> > >> Isr. My child drivers ask to bind to these events which could be either
> > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > >> and either just calls the service routine directly or schedules a Dpc
> > >> that calls the service routine.
> > >>
> > >> The problem comes at teardown (eg driver unload or hibernation).
> > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > >> can I be sure that the Dpc is not currently being executed?
> > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > >> overkill, and isn’t available under Windows 2000 either. The latter
> > >> objection is not really a concern for me as my driver doesn’t work under
> > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > >> really completely finished and I can destroy the KDPC structure…
> > >>
> > >
> > > I solved this by using a reference counter and an event. Increment the
> > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > When the counter goes to zero, set the event.
> > >
> > > Interested parties wait on the event.
> > >
> > > Ping me if you want to see the code.
> > >
> > > Best,
> > > -PWM
> > >
> > >
> > >> Thanks
> > >>
> > >> James
> > >>
> > >> —
> > >> NTDEV is sponsored by OSR
> > >>
> > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > >> http://www.osr.com/seminars
> > >>
> > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

You set the event, your wait is now satisfied and the stack unwinds. The DPC which has set the event has not yet returned from KeSetEvent or has not yet unwound back to the kernel. Since your wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound. When the DPC stack unwinds, it now executes unmapped code. Boom. Flushing DPCs solves this problem by making sure the DPC stack unwinds.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 9:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:

Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.

d

I’m waiting in pause/halt/unload. You best not remove my text while I’m
still alive.

Thx
-PWM

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Peter W. Morreale
> Sent: Wednesday, February 17, 2010 9:02 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Dpcs and Synchronisation
>
>
> On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > Um, aren’t you still in the dpc when the count goes to zero?
>
> Yes. The last executable code in the DPC would be to set the event.
>
> -PWM
>
> >
> >
> > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > >> I have never figured this out properly and it’s getting me into
> > >> trouble…
> > >>
> > >> My driver maintains a list of events that are triggered by Xen, via my
> > >> Isr. My child drivers ask to bind to these events which could be either
> > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > >> and either just calls the service routine directly or schedules a Dpc
> > >> that calls the service routine.
> > >>
> > >> The problem comes at teardown (eg driver unload or hibernation).
> > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > >> can I be sure that the Dpc is not currently being executed?
> > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > >> overkill, and isn’t available under Windows 2000 either. The latter
> > >> objection is not really a concern for me as my driver doesn’t work under
> > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > >> really completely finished and I can destroy the KDPC structure…
> > >>
> > >
> > > I solved this by using a reference counter and an event. Increment the
> > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > When the counter goes to zero, set the event.
> > >
> > > Interested parties wait on the event.
> > >
> > > Ping me if you want to see the code.
> > >
> > > Best,
> > > -PWM
> > >
> > >
> > >> Thanks
> > >>
> > >> James
> > >>
> > >> —
> > >> NTDEV is sponsored by OSR
> > >>
> > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > >> http://www.osr.com/seminars
> > >>
> > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:

You set the event, your wait is now satisfied and the stack unwinds. The DPC which has set the event has not yet returned from KeSetEvent or has not yet unwound back to the kernel. Since your wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound. When the DPC stack unwinds, it now executes unmapped code. Boom. Flushing DPCs solves this problem by making sure the DPC stack unwinds.

d

I completely understand (and did prior) what you are saying wrt routine
termination.

What I don’t understand, is whether you are telling me that there are
cases where, after driver entry, I will get a Restart/Unload without an
intervening Pause and/or Halt.

Thanks,
-PWM

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 9:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
> Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.
>
> d

I’m waiting in pause/halt/unload. You best not remove my text while I’m
still alive.

Thx
-PWM

>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Peter W. Morreale
> > Sent: Wednesday, February 17, 2010 9:02 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Dpcs and Synchronisation
> >
> >
> > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > > Um, aren’t you still in the dpc when the count goes to zero?
> >
> > Yes. The last executable code in the DPC would be to set the event.
> >
> > -PWM
> >
> > >
> > >
> > > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > > >> I have never figured this out properly and it’s getting me into
> > > >> trouble…
> > > >>
> > > >> My driver maintains a list of events that are triggered by Xen, via my
> > > >> Isr. My child drivers ask to bind to these events which could be either
> > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > > >> and either just calls the service routine directly or schedules a Dpc
> > > >> that calls the service routine.
> > > >>
> > > >> The problem comes at teardown (eg driver unload or hibernation).
> > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > > >> can I be sure that the Dpc is not currently being executed?
> > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > > >> overkill, and isn’t available under Windows 2000 either. The latter
> > > >> objection is not really a concern for me as my driver doesn’t work under
> > > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > > >> really completely finished and I can destroy the KDPC structure…
> > > >>
> > > >
> > > > I solved this by using a reference counter and an event. Increment the
> > > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > > When the counter goes to zero, set the event.
> > > >
> > > > Interested parties wait on the event.
> > > >
> > > > Ping me if you want to see the code.
> > > >
> > > > Best,
> > > > -PWM
> > > >
> > > >
> > > >> Thanks
> > > >>
> > > >> James
> > > >>
> > > >> —
> > > >> NTDEV is sponsored by OSR
> > > >>
> > > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > > >> http://www.osr.com/seminars
> > > >>
> > > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > > > —
> > > > NTDEV is sponsored by OSR
> > > >
> > > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > http://www.osr.com/seminars
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > >
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

You will get an pause/halt (these are NDIS specific concepts, but they map to the more generic lifetime model) before unload, but that doesn’t really matter. The window exists if you wait for dpc rundown in your current schecme in unload or in halt/pause

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 11:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:

You set the event, your wait is now satisfied and the stack unwinds. The DPC which has set the event has not yet returned from KeSetEvent or has not yet unwound back to the kernel. Since your wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound. When the DPC stack unwinds, it now executes unmapped code. Boom. Flushing DPCs solves this problem by making sure the DPC stack unwinds.

d

I completely understand (and did prior) what you are saying wrt routine
termination.

What I don’t understand, is whether you are telling me that there are
cases where, after driver entry, I will get a Restart/Unload without an
intervening Pause and/or Halt.

Thanks,
-PWM

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 9:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
> Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.
>
> d

I’m waiting in pause/halt/unload. You best not remove my text while I’m
still alive.

Thx
-PWM

>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Peter W. Morreale
> > Sent: Wednesday, February 17, 2010 9:02 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Dpcs and Synchronisation
> >
> >
> > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > > Um, aren’t you still in the dpc when the count goes to zero?
> >
> > Yes. The last executable code in the DPC would be to set the event.
> >
> > -PWM
> >
> > >
> > >
> > > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > > >> I have never figured this out properly and it’s getting me into
> > > >> trouble…
> > > >>
> > > >> My driver maintains a list of events that are triggered by Xen, via my
> > > >> Isr. My child drivers ask to bind to these events which could be either
> > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > > >> and either just calls the service routine directly or schedules a Dpc
> > > >> that calls the service routine.
> > > >>
> > > >> The problem comes at teardown (eg driver unload or hibernation).
> > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > > >> can I be sure that the Dpc is not currently being executed?
> > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > > >> overkill, and isn’t available under Windows 2000 either. The latter
> > > >> objection is not really a concern for me as my driver doesn’t work under
> > > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > > >> really completely finished and I can destroy the KDPC structure…
> > > >>
> > > >
> > > > I solved this by using a reference counter and an event. Increment the
> > > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > > When the counter goes to zero, set the event.
> > > >
> > > > Interested parties wait on the event.
> > > >
> > > > Ping me if you want to see the code.
> > > >
> > > > Best,
> > > > -PWM
> > > >
> > > >
> > > >> Thanks
> > > >>
> > > >> James
> > > >>
> > > >> —
> > > >> NTDEV is sponsored by OSR
> > > >>
> > > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > > >> http://www.osr.com/seminars
> > > >>
> > > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > > > —
> > > > NTDEV is sponsored by OSR
> > > >
> > > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > http://www.osr.com/seminars
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > >
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Isn’t the fact that queue:run isn’t 1:1 a bigger problem? a second
call to queue will inc the counter but not queue the dpc if it’s
already queued, resulting in only one decrement

That objection assumes you do literally inc the counter then queue

Sent from my iPhone

On 18/02/2010, at 2:57, “Mark Roddy” wrote:

> Um, aren’t you still in the dpc when the count goes to zero?
>
>
>
> On Wednesday, February 17, 2010, Peter W. Morreale > > wrote:
>> On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>>> I have never figured this out properly and it’s getting me into
>>> trouble…
>>>
>>> My driver maintains a list of events that are triggered by Xen,
>>> via my
>>> Isr. My child drivers ask to bind to these events which could be
>>> either
>>> as a Dpc, or at DIRQL (where they probably create their own Dpcs
>>> anyway). The bus driver Isr checks to see what type of event is
>>> wanted
>>> and either just calls the service routine directly or schedules a
>>> Dpc
>>> that calls the service routine.
>>>
>>> The problem comes at teardown (eg driver unload or hibernation).
>>> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but
>>> how
>>> can I be sure that the Dpc is not currently being executed?
>>> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
>>> overkill, and isn’t available under Windows 2000 either. The latter
>>> objection is not really a concern for me as my driver doesn’t work
>>> under
>>> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
>>> really completely finished and I can destroy the KDPC structure…
>>>
>>
>> I solved this by using a reference counter and an event. Increment
>> the
>> reference counter prior to queueing the DPC, then decrement in the
>> DPC.
>> When the counter goes to zero, set the event.
>>
>> Interested parties wait on the event.
>>
>> Ping me if you want to see the code.
>>
>> Best,
>> -PWM
>>
>>
>>> Thanks
>>>
>>> James
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> Mark Roddy
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Thu, 2010-02-18 at 08:06 +1100, James Harper wrote:

Isn’t the fact that queue:run isn’t 1:1 a bigger problem? a second
call to queue will inc the counter but not queue the dpc if it’s
already queued, resulting in only one decrement

That objection assumes you do literally inc the counter then queue

You have to inc, then queue.

You would need to check the return code from KeInsertQueueDpc, if it
fails to queue, dec.

Best,
-PWM

Sent from my iPhone

On 18/02/2010, at 2:57, “Mark Roddy” wrote:
>
> > Um, aren’t you still in the dpc when the count goes to zero?
> >
> >
> >
> > On Wednesday, February 17, 2010, Peter W. Morreale > > > wrote:
> >> On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> >>> I have never figured this out properly and it’s getting me into
> >>> trouble…
> >>>
> >>> My driver maintains a list of events that are triggered by Xen,
> >>> via my
> >>> Isr. My child drivers ask to bind to these events which could be
> >>> either
> >>> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> >>> anyway). The bus driver Isr checks to see what type of event is
> >>> wanted
> >>> and either just calls the service routine directly or schedules a
> >>> Dpc
> >>> that calls the service routine.
> >>>
> >>> The problem comes at teardown (eg driver unload or hibernation).
> >>> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but
> >>> how
> >>> can I be sure that the Dpc is not currently being executed?
> >>> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> >>> overkill, and isn’t available under Windows 2000 either. The latter
> >>> objection is not really a concern for me as my driver doesn’t work
> >>> under
> >>> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> >>> really completely finished and I can destroy the KDPC structure…
> >>>
> >>
> >> I solved this by using a reference counter and an event. Increment
> >> the
> >> reference counter prior to queueing the DPC, then decrement in the
> >> DPC.
> >> When the counter goes to zero, set the event.
> >>
> >> Interested parties wait on the event.
> >>
> >> Ping me if you want to see the code.
> >>
> >> Best,
> >> -PWM
> >>
> >>
> >>> Thanks
> >>>
> >>> James
> >>>
> >>> —
> >>> NTDEV is sponsored by OSR
> >>>
> >>> For our schedule of WDF, WDM, debugging and other seminars visit:
> >>> http://www.osr.com/seminars
> >>>
> >>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
> > –
> > Mark Roddy
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:

You will get an pause/halt (these are NDIS specific concepts, but they map to the more generic lifetime model) before unload, but that doesn’t really matter. The window exists if you wait for dpc rundown in your current schecme in unload or in halt/pause

MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
never be hit upon.

The idea to flush all outstanding queued DPCs, by each driver (using
such) during a shutdown, is an interesting architectural decision.

Thx,
-PWM

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 11:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
> You set the event, your wait is now satisfied and the stack unwinds. The DPC which has set the event has not yet returned from KeSetEvent or has not yet unwound back to the kernel. Since your wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound. When the DPC stack unwinds, it now executes unmapped code. Boom. Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>
> d

I completely understand (and did prior) what you are saying wrt routine
termination.

What I don’t understand, is whether you are telling me that there are
cases where, after driver entry, I will get a Restart/Unload without an
intervening Pause and/or Halt.

Thanks,
-PWM

>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
> Sent: Wednesday, February 17, 2010 9:33 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
> > Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.
> >
> > d
>
>
> I’m waiting in pause/halt/unload. You best not remove my text while I’m
> still alive.
>
> Thx
> -PWM
>
>
> >
> > tiny phone keyboard + fat thumbs = you do the muth
> >
> >
> >
> > -----Original Message-----
> > From: Peter W. Morreale
> > > Sent: Wednesday, February 17, 2010 9:02 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Dpcs and Synchronisation
> > >
> > >
> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > > > Um, aren’t you still in the dpc when the count goes to zero?
> > >
> > > Yes. The last executable code in the DPC would be to set the event.
> > >
> > > -PWM
> > >
> > > >
> > > >
> > > > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > > > >> I have never figured this out properly and it’s getting me into
> > > > >> trouble…
> > > > >>
> > > > >> My driver maintains a list of events that are triggered by Xen, via my
> > > > >> Isr. My child drivers ask to bind to these events which could be either
> > > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > > > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > > > >> and either just calls the service routine directly or schedules a Dpc
> > > > >> that calls the service routine.
> > > > >>
> > > > >> The problem comes at teardown (eg driver unload or hibernation).
> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > > > >> can I be sure that the Dpc is not currently being executed?
> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > > > >> overkill, and isn’t available under Windows 2000 either. The latter
> > > > >> objection is not really a concern for me as my driver doesn’t work under
> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > > > >> really completely finished and I can destroy the KDPC structure…
> > > > >>
> > > > >
> > > > > I solved this by using a reference counter and an event. Increment the
> > > > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > > > When the counter goes to zero, set the event.
> > > > >
> > > > > Interested parties wait on the event.
> > > > >
> > > > > Ping me if you want to see the code.
> > > > >
> > > > > Best,
> > > > > -PWM
> > > > >
> > > > >
> > > > >> Thanks
> > > > >>
> > > > >> James
> > > > >>
> > > > >> —
> > > > >> NTDEV is sponsored by OSR
> > > > >>
> > > > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > >> http://www.osr.com/seminars
> > > > >>
> > > > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > > >
> > > > >
> > > > > —
> > > > > NTDEV is sponsored by OSR
> > > > >
> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > > http://www.osr.com/seminars
> > > > >
> > > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > > >
> > > >
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

How do you know that it can never be hit upon? That is na?ve to think that just b/c something is running at passive on one processor and dispatch on another proc that a timing window is eliminated. I have certainly debugged many a crash dump where exactly this scenario has happened.

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 3:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:

You will get an pause/halt (these are NDIS specific concepts, but they map to the more generic lifetime model) before unload, but that doesn’t really matter. The window exists if you wait for dpc rundown in your current schecme in unload or in halt/pause

MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
never be hit upon.

The idea to flush all outstanding queued DPCs, by each driver (using
such) during a shutdown, is an interesting architectural decision.

Thx,
-PWM

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Wednesday, February 17, 2010 11:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Dpcs and Synchronisation

On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
> You set the event, your wait is now satisfied and the stack unwinds. The DPC which has set the event has not yet returned from KeSetEvent or has not yet unwound back to the kernel. Since your wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound. When the DPC stack unwinds, it now executes unmapped code. Boom. Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>
> d

I completely understand (and did prior) what you are saying wrt routine
termination.

What I don’t understand, is whether you are telling me that there are
cases where, after driver entry, I will get a Restart/Unload without an
intervening Pause and/or Halt.

Thanks,
-PWM

>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
> Sent: Wednesday, February 17, 2010 9:33 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
> > Which means unload can proceed, unmap the image and the ret instruction from your dpc has yet to execute and then you bugcheck. Flush your dpcs and this goes away.
> >
> > d
>
>
> I’m waiting in pause/halt/unload. You best not remove my text while I’m
> still alive.
>
> Thx
> -PWM
>
>
> >
> > tiny phone keyboard + fat thumbs = you do the muth
> >
> >
> >
> > -----Original Message-----
> > From: Peter W. Morreale
> > > Sent: Wednesday, February 17, 2010 9:02 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Dpcs and Synchronisation
> > >
> > >
> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
> > > > Um, aren’t you still in the dpc when the count goes to zero?
> > >
> > > Yes. The last executable code in the DPC would be to set the event.
> > >
> > > -PWM
> > >
> > > >
> > > >
> > > > On Wednesday, February 17, 2010, Peter W. Morreale wrote:
> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
> > > > >> I have never figured this out properly and it’s getting me into
> > > > >> trouble…
> > > > >>
> > > > >> My driver maintains a list of events that are triggered by Xen, via my
> > > > >> Isr. My child drivers ask to bind to these events which could be either
> > > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
> > > > >> anyway). The bus driver Isr checks to see what type of event is wanted
> > > > >> and either just calls the service routine directly or schedules a Dpc
> > > > >> that calls the service routine.
> > > > >>
> > > > >> The problem comes at teardown (eg driver unload or hibernation).
> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued, but how
> > > > >> can I be sure that the Dpc is not currently being executed?
> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system which is
> > > > >> overkill, and isn’t available under Windows 2000 either. The latter
> > > > >> objection is not really a concern for me as my driver doesn’t work under
> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if the Dpc is
> > > > >> really completely finished and I can destroy the KDPC structure…
> > > > >>
> > > > >
> > > > > I solved this by using a reference counter and an event. Increment the
> > > > > reference counter prior to queueing the DPC, then decrement in the DPC.
> > > > > When the counter goes to zero, set the event.
> > > > >
> > > > > Interested parties wait on the event.
> > > > >
> > > > > Ping me if you want to see the code.
> > > > >
> > > > > Best,
> > > > > -PWM
> > > > >
> > > > >
> > > > >> Thanks
> > > > >>
> > > > >> James
> > > > >>
> > > > >> —
> > > > >> NTDEV is sponsored by OSR
> > > > >>
> > > > >> For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > >> http://www.osr.com/seminars
> > > > >>
> > > > >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > > >
> > > > >
> > > > > —
> > > > > NTDEV is sponsored by OSR
> > > > >
> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > > > http://www.osr.com/seminars
> > > > >
> > > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > > >
> > > >
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

This scenario is even more likely when using NDIS Work Item support.
Since the work item is also PASSIVE, even more of a chance exists for the
driver to complete the unload and unmap before the worker thread exits the
driver code scope.

Cheers,
Dave Cattley


From: “Doron Holan”
Sent: Wednesday, February 17, 2010 6:11 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Dpcs and Synchronisation

> How do you know that it can never be hit upon? That is naïve to think that
> just b/c something is running at passive on one processor and dispatch on
> another proc that a timing window is eliminated. I have certainly debugged
> many a crash dump where exactly this scenario has happened.
>
> d
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
> Sent: Wednesday, February 17, 2010 3:06 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:
>> You will get an pause/halt (these are NDIS specific concepts, but they
>> map to the more generic lifetime model) before unload, but that doesn’t
>> really matter. The window exists if you wait for dpc rundown in your
>> current schecme in unload or in halt/pause
>>
>
> MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
> never be hit upon.
>
> The idea to flush all outstanding queued DPCs, by each driver (using
> such) during a shutdown, is an interesting architectural decision.
>
> Thx,
> -PWM
>
>> d
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
>> Sent: Wednesday, February 17, 2010 11:26 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] Dpcs and Synchronisation
>>
>> On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
>> > You set the event, your wait is now satisfied and the stack unwinds.
>> > The DPC which has set the event has not yet returned from KeSetEvent or
>> > has not yet unwound back to the kernel. Since your wait is satisfied,
>> > your driver now unloads but the DPC stack still has not yet unwound.
>> > When the DPC stack unwinds, it now executes unmapped code. Boom.
>> > Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>> >
>> > d
>>
>>
>> I completely understand (and did prior) what you are saying wrt routine
>> termination.
>>
>> What I don’t understand, is whether you are telling me that there are
>> cases where, after driver entry, I will get a Restart/Unload without an
>> intervening Pause and/or Halt.
>>
>> Thanks,
>> -PWM
>>
>>
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> > Morreale
>> > Sent: Wednesday, February 17, 2010 9:33 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] Dpcs and Synchronisation
>> >
>> > On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
>> > > Which means unload can proceed, unmap the image and the ret
>> > > instruction from your dpc has yet to execute and then you bugcheck.
>> > > Flush your dpcs and this goes away.
>> > >
>> > > d
>> >
>> >
>> > I’m waiting in pause/halt/unload. You best not remove my text while
>> > I’m
>> > still alive.
>> >
>> > Thx
>> > -PWM
>> >
>> >
>> > >
>> > > tiny phone keyboard + fat thumbs = you do the muth
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Peter W. Morreale
>> > > Sent: Wednesday, February 17, 2010 9:02 AM
>> > > To: Windows System Software Devs Interest List
>> > > Subject: Re: [ntdev] Dpcs and Synchronisation
>> > >
>> > >
>> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
>> > > > Um, aren’t you still in the dpc when the count goes to zero?
>> > >
>> > > Yes. The last executable code in the DPC would be to set the event.
>> > >
>> > > -PWM
>> > >
>> > > >
>> > > >
>> > > > On Wednesday, February 17, 2010, Peter W. Morreale
>> > > > wrote:
>> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> > > > >> I have never figured this out properly and it’s getting me into
>> > > > >> trouble…
>> > > > >>
>> > > > >> My driver maintains a list of events that are triggered by Xen,
>> > > > >> via my
>> > > > >> Isr. My child drivers ask to bind to these events which could be
>> > > > >> either
>> > > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
>> > > > >> anyway). The bus driver Isr checks to see what type of event is
>> > > > >> wanted
>> > > > >> and either just calls the service routine directly or schedules
>> > > > >> a Dpc
>> > > > >> that calls the service routine.
>> > > > >>
>> > > > >> The problem comes at teardown (eg driver unload or hibernation).
>> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued,
>> > > > >> but how
>> > > > >> can I be sure that the Dpc is not currently being executed?
>> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system
>> > > > >> which is
>> > > > >> overkill, and isn’t available under Windows 2000 either. The
>> > > > >> latter
>> > > > >> objection is not really a concern for me as my driver doesn’t
>> > > > >> work under
>> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if the
>> > > > >> Dpc is
>> > > > >> really completely finished and I can destroy the KDPC
>> > > > >> structure…
>> > > > >>
>> > > > >
>> > > > > I solved this by using a reference counter and an event.
>> > > > > Increment the
>> > > > > reference counter prior to queueing the DPC, then decrement in
>> > > > > the DPC.
>> > > > > When the counter goes to zero, set the event.
>> > > > >
>> > > > > Interested parties wait on the event.
>> > > > >
>> > > > > Ping me if you want to see the code.
>> > > > >
>> > > > > Best,
>> > > > > -PWM
>> > > > >
>> > > > >
>> > > > >> Thanks
>> > > > >>
>> > > > >> James
>> > > > >>
>> > > > >> —
>> > > > >> NTDEV is sponsored by OSR
>> > > > >>
>> > > > >> For our schedule of WDF, WDM, debugging and other seminars
>> > > > >> visit:
>> > > > >> http://www.osr.com/seminars
>> > > > >>
>> > > > >> To unsubscribe, visit the List Server section of OSR Online at
>> > > > >> http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > > >
>> > > > > —
>> > > > > NTDEV is sponsored by OSR
>> > > > >
>> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > > > http://www.osr.com/seminars
>> > > > >
>> > > > > To unsubscribe, visit the List Server section of OSR Online at
>> > > > > http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > >
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

If NDIS uses IoWorkItems underneath the covers (vs Ex work items), this is taken care of for you by the io manager since it takes an ObRef that is not released until the work item proc returns, thus preventing unload until the ref is released

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, February 17, 2010 3:22 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dpcs and Synchronisation

This scenario is even more likely when using NDIS Work Item support.
Since the work item is also PASSIVE, even more of a chance exists for the
driver to complete the unload and unmap before the worker thread exits the
driver code scope.

Cheers,
Dave Cattley


From: “Doron Holan”
Sent: Wednesday, February 17, 2010 6:11 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Dpcs and Synchronisation

> How do you know that it can never be hit upon? That is na?ve to think that
> just b/c something is running at passive on one processor and dispatch on
> another proc that a timing window is eliminated. I have certainly debugged
> many a crash dump where exactly this scenario has happened.
>
> d
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
> Sent: Wednesday, February 17, 2010 3:06 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:
>> You will get an pause/halt (these are NDIS specific concepts, but they
>> map to the more generic lifetime model) before unload, but that doesn’t
>> really matter. The window exists if you wait for dpc rundown in your
>> current schecme in unload or in halt/pause
>>
>
> MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
> never be hit upon.
>
> The idea to flush all outstanding queued DPCs, by each driver (using
> such) during a shutdown, is an interesting architectural decision.
>
> Thx,
> -PWM
>
>> d
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
>> Sent: Wednesday, February 17, 2010 11:26 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] Dpcs and Synchronisation
>>
>> On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
>> > You set the event, your wait is now satisfied and the stack unwinds.
>> > The DPC which has set the event has not yet returned from KeSetEvent or
>> > has not yet unwound back to the kernel. Since your wait is satisfied,
>> > your driver now unloads but the DPC stack still has not yet unwound.
>> > When the DPC stack unwinds, it now executes unmapped code. Boom.
>> > Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>> >
>> > d
>>
>>
>> I completely understand (and did prior) what you are saying wrt routine
>> termination.
>>
>> What I don’t understand, is whether you are telling me that there are
>> cases where, after driver entry, I will get a Restart/Unload without an
>> intervening Pause and/or Halt.
>>
>> Thanks,
>> -PWM
>>
>>
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> > Morreale
>> > Sent: Wednesday, February 17, 2010 9:33 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] Dpcs and Synchronisation
>> >
>> > On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
>> > > Which means unload can proceed, unmap the image and the ret
>> > > instruction from your dpc has yet to execute and then you bugcheck.
>> > > Flush your dpcs and this goes away.
>> > >
>> > > d
>> >
>> >
>> > I’m waiting in pause/halt/unload. You best not remove my text while
>> > I’m
>> > still alive.
>> >
>> > Thx
>> > -PWM
>> >
>> >
>> > >
>> > > tiny phone keyboard + fat thumbs = you do the muth
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Peter W. Morreale
>> > > Sent: Wednesday, February 17, 2010 9:02 AM
>> > > To: Windows System Software Devs Interest List
>> > > Subject: Re: [ntdev] Dpcs and Synchronisation
>> > >
>> > >
>> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
>> > > > Um, aren’t you still in the dpc when the count goes to zero?
>> > >
>> > > Yes. The last executable code in the DPC would be to set the event.
>> > >
>> > > -PWM
>> > >
>> > > >
>> > > >
>> > > > On Wednesday, February 17, 2010, Peter W. Morreale
>> > > > wrote:
>> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> > > > >> I have never figured this out properly and it’s getting me into
>> > > > >> trouble…
>> > > > >>
>> > > > >> My driver maintains a list of events that are triggered by Xen,
>> > > > >> via my
>> > > > >> Isr. My child drivers ask to bind to these events which could be
>> > > > >> either
>> > > > >> as a Dpc, or at DIRQL (where they probably create their own Dpcs
>> > > > >> anyway). The bus driver Isr checks to see what type of event is
>> > > > >> wanted
>> > > > >> and either just calls the service routine directly or schedules
>> > > > >> a Dpc
>> > > > >> that calls the service routine.
>> > > > >>
>> > > > >> The problem comes at teardown (eg driver unload or hibernation).
>> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer queued,
>> > > > >> but how
>> > > > >> can I be sure that the Dpc is not currently being executed?
>> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system
>> > > > >> which is
>> > > > >> overkill, and isn’t available under Windows 2000 either. The
>> > > > >> latter
>> > > > >> objection is not really a concern for me as my driver doesn’t
>> > > > >> work under
>> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if the
>> > > > >> Dpc is
>> > > > >> really completely finished and I can destroy the KDPC
>> > > > >> structure…
>> > > > >>
>> > > > >
>> > > > > I solved this by using a reference counter and an event.
>> > > > > Increment the
>> > > > > reference counter prior to queueing the DPC, then decrement in
>> > > > > the DPC.
>> > > > > When the counter goes to zero, set the event.
>> > > > >
>> > > > > Interested parties wait on the event.
>> > > > >
>> > > > > Ping me if you want to see the code.
>> > > > >
>> > > > > Best,
>> > > > > -PWM
>> > > > >
>> > > > >
>> > > > >> Thanks
>> > > > >>
>> > > > >> James
>> > > > >>
>> > > > >> —
>> > > > >> NTDEV is sponsored by OSR
>> > > > >>
>> > > > >> For our schedule of WDF, WDM, debugging and other seminars
>> > > > >> visit:
>> > > > >> http://www.osr.com/seminars
>> > > > >>
>> > > > >> To unsubscribe, visit the List Server section of OSR Online at
>> > > > >> http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > > >
>> > > > > —
>> > > > > NTDEV is sponsored by OSR
>> > > > >
>> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > > > http://www.osr.com/seminars
>> > > > >
>> > > > > To unsubscribe, visit the List Server section of OSR Online at
>> > > > > http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > >
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Well wait now. NDIS protects against your code segment getting yanked out from under you, as long as you use NDIS’s work item, timer, and DPC support. That’s not the real issue. The real issue is that your callback tries to use some pool memory (or other allocated resource) that your cleanup routine has already free’d. NDIS can’t protect against that.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, February 17, 2010 3:22 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dpcs and Synchronisation

This scenario is even more likely when using NDIS Work Item support.
Since the work item is also PASSIVE, even more of a chance exists for the driver to complete the unload and unmap before the worker thread exits the driver code scope.

Cheers,
Dave Cattley


From: “Doron Holan”
Sent: Wednesday, February 17, 2010 6:11 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Dpcs and Synchronisation

> How do you know that it can never be hit upon? That is na?ve to think
> that just b/c something is running at passive on one processor and
> dispatch on another proc that a timing window is eliminated. I have
> certainly debugged many a crash dump where exactly this scenario has happened.
>
> d
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
> Morreale
> Sent: Wednesday, February 17, 2010 3:06 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:
>> You will get an pause/halt (these are NDIS specific concepts, but
>> they map to the more generic lifetime model) before unload, but that
>> doesn’t really matter. The window exists if you wait for dpc rundown
>> in your current schecme in unload or in halt/pause
>>
>
> MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
> never be hit upon.
>
> The idea to flush all outstanding queued DPCs, by each driver (using
> such) during a shutdown, is an interesting architectural decision.
>
> Thx,
> -PWM
>
>> d
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> Morreale
>> Sent: Wednesday, February 17, 2010 11:26 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] Dpcs and Synchronisation
>>
>> On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
>> > You set the event, your wait is now satisfied and the stack unwinds.
>> > The DPC which has set the event has not yet returned from
>> > KeSetEvent or has not yet unwound back to the kernel. Since your
>> > wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound.
>> > When the DPC stack unwinds, it now executes unmapped code. Boom.
>> > Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>> >
>> > d
>>
>>
>> I completely understand (and did prior) what you are saying wrt
>> routine termination.
>>
>> What I don’t understand, is whether you are telling me that there are
>> cases where, after driver entry, I will get a Restart/Unload without
>> an intervening Pause and/or Halt.
>>
>> Thanks,
>> -PWM
>>
>>
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> > Morreale
>> > Sent: Wednesday, February 17, 2010 9:33 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] Dpcs and Synchronisation
>> >
>> > On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
>> > > Which means unload can proceed, unmap the image and the ret
>> > > instruction from your dpc has yet to execute and then you bugcheck.
>> > > Flush your dpcs and this goes away.
>> > >
>> > > d
>> >
>> >
>> > I’m waiting in pause/halt/unload. You best not remove my text
>> > while I’m still alive.
>> >
>> > Thx
>> > -PWM
>> >
>> >
>> > >
>> > > tiny phone keyboard + fat thumbs = you do the muth
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Peter W. Morreale
>> > > Sent: Wednesday, February 17, 2010 9:02 AM
>> > > To: Windows System Software Devs Interest List
>> > >
>> > > Subject: Re: [ntdev] Dpcs and Synchronisation
>> > >
>> > >
>> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
>> > > > Um, aren’t you still in the dpc when the count goes to zero?
>> > >
>> > > Yes. The last executable code in the DPC would be to set the event.
>> > >
>> > > -PWM
>> > >
>> > > >
>> > > >
>> > > > On Wednesday, February 17, 2010, Peter W. Morreale
>> > > > wrote:
>> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> > > > >> I have never figured this out properly and it’s getting me
>> > > > >> into trouble…
>> > > > >>
>> > > > >> My driver maintains a list of events that are triggered by
>> > > > >> Xen, via my Isr. My child drivers ask to bind to these
>> > > > >> events which could be either as a Dpc, or at DIRQL (where
>> > > > >> they probably create their own Dpcs anyway). The bus driver
>> > > > >> Isr checks to see what type of event is wanted and either
>> > > > >> just calls the service routine directly or schedules a Dpc
>> > > > >> that calls the service routine.
>> > > > >>
>> > > > >> The problem comes at teardown (eg driver unload or hibernation).
>> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer
>> > > > >> queued, but how can I be sure that the Dpc is not currently
>> > > > >> being executed?
>> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system
>> > > > >> which is overkill, and isn’t available under Windows 2000
>> > > > >> either. The latter objection is not really a concern for me
>> > > > >> as my driver doesn’t work under
>> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if
>> > > > >> the Dpc is really completely finished and I can destroy the
>> > > > >> KDPC structure…
>> > > > >>
>> > > > >
>> > > > > I solved this by using a reference counter and an event.
>> > > > > Increment the
>> > > > > reference counter prior to queueing the DPC, then decrement
>> > > > > in the DPC.
>> > > > > When the counter goes to zero, set the event.
>> > > > >
>> > > > > Interested parties wait on the event.
>> > > > >
>> > > > > Ping me if you want to see the code.
>> > > > >
>> > > > > Best,
>> > > > > -PWM
>> > > > >
>> > > > >
>> > > > >> Thanks
>> > > > >>
>> > > > >> James
>> > > > >>
>> > > > >> —
>> > > > >> NTDEV is sponsored by OSR
>> > > > >>
>> > > > >> For our schedule of WDF, WDM, debugging and other seminars
>> > > > >> visit:
>> > > > >> http://www.osr.com/seminars
>> > > > >>
>> > > > >> To unsubscribe, visit the List Server section of OSR Online
>> > > > >> at http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > > >
>> > > > > —
>> > > > > NTDEV is sponsored by OSR
>> > > > >
>> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > > > http://www.osr.com/seminars
>> > > > >
>> > > > > To unsubscribe, visit the List Server section of OSR Online
>> > > > > at http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > >
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer