PROBLEM:
Retried I/Os from the disk driver on W2K3 (disk.sys,
classpnp.sys) seem to be performed at the DISPATCH_LEVEL
IRQL.
These appear to be performed from a DPC triggered from a
kernel timer (initialized by KeSetTimerEx, if I can
believe the example from the DDK, but that's consistent
with the stack traces I got).

Now, this causes the MajorFunction[IRP_MJ_SCSI] entry
point on my lower filter driver to be executed with that
DISPATCH_LEVEL IRQL, which causes some crashes as I have
some waits on asynchronous I/Os in there.

QUESTION:
But, is that legitimate for this entry point to be called
with such an IRQL ? From the stacks I have, it seems that
the driver triggered DPC itself is executed with that IRQL
(unless the I/O manager is raising the IRQL in the
IoCallDriver call !).


ADDITIONAL INFORMATION:

That problem was not present on W2K, since (to the best of
my knowledge) retries were processed in the same thread
than the original request, and did not use a timer
triggered DPC call.


The stack I have is as such:
myLowerFilter!myInternalControlEntryPoint+0x317
nt!IovCallDriver+0x110
nt!IofCallDriver+0xe
CLASSPNP!ClasspRetryRequestDpc+0x88
nt!KiTimerExpiration+0x371
nt!KiRetireDpcList+0x63

On Tue, 28 Oct 2003 01:53:35 -0800, "Marc LAUTIER"
<lautim@europe.stortek.nospam> wrote:

Despite the DDK documentation that sort of indicates the contrary, it
is legitimate for drivers to do as disk.sys does. The target driver
had better understand what is going on, as you discovered.

Just out of curiosity, exactly what sort of IRP was this?

Oh, and this is new behavior in XP and later.




=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

Thanks for your answer.

I got confused by the bit of DDK documentation that stated
that a queued DPC would be run as soon as the processor
IRQL went down below DISPATCH_LEVEL, assumed it meant that
DPC were run below DISPATCH_LEVEL.

I see now how DPC are meant to run at DISPATCH_LEVEL, and
how what disk.sys is doing is valid.


So now (in W2K3), some dispatch routine on my driver are
run at DISPATCH_LEVEL whereas in previous versions (W2K,
I'm really only targetting server platforms here, which is
why I'm discounting WXP) the same dispatch routines were
only accessed at PASSIVE_LEVEL.

The catch is that I'm doing some jobs in those dispatch
routines that include running multiple synchronous I/Os
(that is, I've got infinite wait on event objects for
those I/Os completion), along with some synchronization
(mutexes) that are incompatible with DISPATCH_LEVEL.

How should I go and get to do such processing while being
accessed at DISPATCH_LEVEL ? Deport those processing in
another thread ?
Would there be an example somewhere of a driver that
performs similar processing ?


Thanks,
Marc.

(for the record, the retried I/O here was a SCSI Reserve)

On Wed, 29 Oct 2003 00:52:59 -0800, "Marc LAUTIER"
<lautim@europe.stortek.nospam> wrote:

This is a standard driver design problem and the standard solution is
to queue your IRPs to a worker thread running at passive level that
performs your 'infinite delay' tasks (and I sure hope that they aren't
really infinite :-) You can create your own driver private threads or
you can use the system's Worker threads (see IoQueueWorkItem.) Be very
careful here when you are in the storage stack as some IO requests
cannot time out or you risk data corruption or a bugcheck crash. Also
your use of system work items can deadlock with other storage stack
drivers use of work items, although this is mitigated in w2k and
later.



=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

For storage stacks - yes. Dispatch entry points can be called on
DISPATCH_LEVEL. Period.

Same for USB and serial stacks.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com