Re: MiniportHandleInterrupt not queued when MiniportHalt is running in

From: Stephan Wolf [MVP] (stewo68_at_hotmail.com)
Date: 02/25/05 

Date: Fri, 25 Feb 2005 10:27:29 +0100

Sure you are right but the OP talks about the *CE* docs, which
actually say:

http://msdn.microsoft.com/library/en-us/wcesdkr/html/_wcesdk_MiniportISR.asp

 "The MiniportHandleInterrupt function is not queued if the driver's
 MiniportHalt or MiniportInitialize function is currently executing."

So this is contradictory.

Note that MiniportHandleInterrupt() can also get called *without* any
MiniportISR() during or shortly after MiniportInitialize(), as
reported by MS (kyleb) in 1997, see

http://groups-beta.google.com/group/comp.os.ms-windows.programmer.nt.kernel-mode/msg/d2e765be5123feab

I consider this bad behaviour (NDIS workaround for badly written
miniports) but I am currently not aware if NDIS still does so today
(to cope with this, all my miniports simply ignore DPCs w/o a
preceding ISR).

Stephan
---
On Thu, 24 Feb 2005 19:27:15 -0800, "Alireza Dabagh [MS]"
<alid@online.microsoft.com> wrote:

>Replying to Pavel's question:
>
>>Is this a problem? do you really need DPC queued while you're in Halt() ?
>In general, "absoloutely!" How do we know if in order to clean up and set
>the state of the hardware properly (so it can be re-enabled or the system
>can be restarted without any hang) the driver does not need to write a
>command to a hardware register that will signal its completion through
>generating an interrupt?
>
>In any case, the rule is that as long as the call to
>NdisMDeregisterInterrupt has not returned, you can get caleld at your ISR
>and DPC handler. NDIS will not call your ISR or DPC handler afterward.
>
>-ali