Article 14244 of comp.os.ms-windows.programmer.nt.kernel-mode:
I'll even offer a place that you might want to go look.

In the real driver pay VERY close attention to where you might be
initializing the DPC object.  If you have an INIT in more than one
place in the driver you should make REAL sure that the INIT can never
occur when the DPC is in the queue.

In the past when I've heard about these sorts of DPC problems, it
could be traced down to an inadvertant init.


"Jim McCollum" <jimmc@ultranet.com> wrote:

>>Anthony V. Ercolano <tony@ercolano.com> wrote in message
>><34c187ba.96744578@news.alt.net>...
>> The code sample is broken.
>>
>> To quote the DDK documentation:
>>
>> "Callers of KeInsertQueueDpc must be running at IRQL >=
>> DISPATCH_LEVEL."
>
>Yeah, I know it says that, but since KeInsertQueueDpc raises IRQL
>immediately to HIGH_LEVEL, it doesn't matter. My actual driver doesn't do
>the call to KeInsertQueueDpc from PASSIVE_LEVEL, I just used that in the
>sample driver for convenience. I could easily add a call to KeRaiseIrql (to
>go to DISPATCH_LEVEL) just before the call to KeInsertQueueDpc and a call to
>KeLowerIrql upon return, and it will still crash.
>
>Jim
>
>
>