W2K DDK contradicts itself -- can anyone explain?

NTDEV
1

The documentation for IoInitializeDpcRequest() in the Windows 2000 DDK
mentions, “It is possible to call KeInitializeDpc to initialize another DPC
at IRQL <= DISPATCH_LEVEL”.

However, the documentation for KeInitializeDpc() says, “Callers of this
routine must be running at IRQL PASSIVE_LEVEL”.

Which one is accurate?

  • Matt
2

I think call to the KeInitializeDpc can be done at any IRQL.
All important kernel routines live in .text section and thus
are resident. In all of the KeInitializeXxxx is written the IRQL
must be PASSIVE_LEVEL. Why this is if the routine and all
data which maintains are resident? The only exception is
KeInitializeTimer(Ex) (IRQL <= DISPATCH_LEVEL) and
KeInitializeSpinLock (any IRQL).

I think all the Kernel initialization routines can safely be called
at IRQL <= DISPATCH_LEVEL (or truly at any IRQL).

Paul

-----P?vodn? zpr?va-----
Od: Matt Arnold [SMTP:xxxxx@motu.com]
Odesl?no: 18. kv?tna 2000 5:21
Komu: NT Developers Interest List
P?edm?t: [ntdev] W2K DDK contradicts itself – can anyone explain?

The documentation for IoInitializeDpcRequest() in the Windows 2000 DDK
mentions, “It is possible to call KeInitializeDpc to initialize another
DPC
at IRQL <= DISPATCH_LEVEL”.

However, the documentation for KeInitializeDpc() says, “Callers of this
routine must be running at IRQL PASSIVE_LEVEL”.

Which one is accurate?

  • Matt

You are currently subscribed to ntdev as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

From the NT4 DDK:

“The caller can queue an initialized DPC with KeInsertQueueDpc. The caller
also can set up a timer object associated with the initialized DPC object
and queue the DPC with KeSetTimer.
Storage for the DPC object must be resident: in the device extension of a
driver-created device object, in the controller extension of a
driver-created controller object, or in nonpaged pool allocated by the
caller.
Callers of this routine must be running at IRQL PASSIVE_LEVEL.”

I would be surprised that this kind of kernel routine would have changed
between NT4 and NT5, oups! W2K. :wink:

It is not the first time I’ve seen an equal sign being unappropriately
inserted or removed in the DDK doc.

Alain Clermont
ArtQuest International
www.artquest.net
xxxxx@artquest.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Matt Arnold
Sent: Wednesday, May 17, 2000 11:21 PM
To: NT Developers Interest List
Subject: [ntdev] W2K DDK contradicts itself – can anyone explain?

The documentation for IoInitializeDpcRequest() in the Windows 2000 DDK
mentions, “It is possible to call KeInitializeDpc to initialize another DPC
at IRQL <= DISPATCH_LEVEL”.

However, the documentation for KeInitializeDpc() says, “Callers of this
routine must be running at IRQL PASSIVE_LEVEL”.

Which one is accurate?

  • Matt

You are currently subscribed to ntdev as: xxxxx@videotron.ca
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

4

> I think call to the KeInitializeDpc can be done at any IRQL.

I can tell you for a fact that you’ll get into trouble calling
KeInitializeDpc from within a DPC, at least under NT 4.0 SP 6.

We had some code that did this, and it was a VERY hard bug to track down.
Under VERY heavy load, the machine would hang (not even SoftICE would work)
every few days. We eventually tracked it down to calling KeInitializeDpc
from within one of our DPCs. This would very rarely cause the forward and
backwards links in the DPC doubly-linked list to get set to the same value,
and then when the DPC was called (or maybe when a timer went off), it would
just sit and spin inside the kernel (at IRQL 0x1C, I seem to recall)
traversing the infinite list.

We eventually tracked it down by using a forced NMI into SoftICE during the
time it was hung.

Simply moving the KeInitializeDpc to DriverEntry fixed the problem.