The DDK is wishy-washy about valid IRQLs for dispatch routines, but not completion routines. If you believe this,
then you could never send an IRP out of a completion routine [except conditionally if the IRQL was low]. I think
such an interpretation would mean that almost all of the disk drivers are illegal. I would be nice if MS pinned this
down better.
-DH
Section 13.1
“The Dispatch routine that called IoSetCompletionRoutine can pass a Context pointer to whatever driver-determined context it set
up for the IoCompletion routine to use in processing the given IRP. Note that the context area cannot be pageable because the
IoCompletion routine can be called at IRQL DISPATCH_LEVEL.
From Section 6.1 “Kernel Mode Drivers”.”
Section 6.1
"Most drivers’ Dispatch routines are called in an arbitrary thread context at IRQL PASSIVE_LEVEL, with the following exceptions:
a… Any highest-level driver’s Dispatch routines are called in the context of the thread that originated the I/O request,
which is commonly a user-mode application thread.
In other words, the Dispatch routines of file system drivers and other highest-level drivers are called in a nonarbitrary
thread context at IRQL PASSIVE_LEVEL.
b… The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of lowest-level device drivers and of intermediate
drivers layered above them in the system paging path, can be called at IRQL APC_LEVEL and in an arbitrary thread context.
The DispatchRead and/or DispatchWrite and any other routine that also processes read and/or write requests in such a
lowest-level device or intermediate driver must be resident at all times. These driver routines can neither be pageable nor be
part of a driver’s pageable-image section; they must not access any pageable memory. Furthermore, they should not be dependent
on any blocking calls (such as KeWaitForSingleObject with a nonzero time-out). See Part 3 for more information.
c… The DispatchPower routine of drivers in the hibernation and/or paging paths can be called at IRQL DISPATCH_LEVEL. The
DispatchPnP routines of such drivers must be prepared to handle PnP IRP_MN_DEVICE_USAGE_NOTIFICATION requests.
d… The DispatchPower routine of drivers that require inrush power at start-up can be called at IRQL DISPATCH_LEVEL.
e… "
13.2 IoCompletion Routine Required Functionality
On entry, an IoCompletion routine is called with DeviceObject, Irp, and Context pointers. The Dispatch routine that called
IoSetCompletionRoutine can pass a Context pointer to whatever driver-determined context it set up for the IoCompletion routine
to use in processing the given IRP. Note that the context area cannot be pageable because the IoCompletion routine can be called
at IRQL DISPATCH_LEVEL.
An IoCompletion routine is responsible for doing whatever additional IRP processing the driver requires and any necessary
cleanup operations for the request, depending on how the Dispatch routine set up the request.
Built on Wednesday, June 28, 2000
----- Original Message -----
From: “Timothy A. Johns”
To: “NT Developers Interest List”
Sent: Thursday, August 16, 2001 7:05 PM
Subject: [ntdev] Re: Question on IoCallDriver
> Whoa, be careful - remember that hardware vendors, rather than Microsoft,
> supply many (if not most) of the drivers that ship in the box. Certainly we
> can’t expect Microsoft to document whether those drivers’ dispatch routines
> can be called at DISPATCH_LEVEL.
>
> I agree Microsoft should document which of the system-supplied bus drivers’
> (such as USB) dispatch routines can be called at DISPATCH_LEVEL, and for the
> most part, they do. For example, the docs clearly state that
> IOCTL_INTERNAL_USB_RESET_PORT must be submitted at PASSIVE_LEVEL. The docs
> for IOCTL_INTERNAL_USB_SUBMIT_URB doesn’t indicate at which IRQLs it can be
> submitted, and I’d perhaps log that as a bug in the bugbash (although I
> haven’t…). (aside - in this specific case only, by ommission and
> experience I’d assume SUBMIT_URB is safe at DISPATCH_LEVEL, but it would
> indeed be nice if the docs stated that as a fact).
>
> -Tim
>
> Timothy A. Johns — xxxxx@driverdev.com
> Driver Development Corporation — 800.841.0092
> Bring Up Your Hardware — Fast. www.driverdev.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Jos Scherders
> > Sent: Thursday, August 16, 2001 10:57 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Question on IoCallDriver
> >
> >
> > Maxim S. Shatskih wrote:
> >
> > >Surely not all drivers support this. For instance, filesystems do not.
> > >Unfortunately, I don’t think MS have documented this thing - what drivers
> > >and stacks can be called at DISPATCH_LEVEL.
> > >
> > It is unfortunate we have to life with this yes, e.g. badly documented
> > API’s, code etc. When do people start figuring out bad documentation is
> > a BIG problem in the software business. My guess it costs us all 10
> > times more then all the BLUE screens combined.
> >
> > You should file these bugs at www.osr.com because it should be treated
> > as one for sure.
> >
> > Jos.
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com