Maxim
Fri Jan 09 12:30:17 CST 2004
There was also a native Microsoft article on the web in their KB.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"Bill McKenzie" <bill.mckenzie@compuware.com> wrote in message
news:OHy7Bls1DHA.4064@tk2msftngp13.phx.gbl...
> Now might be a good time to pick up a copy of Walter Oney's "Programming the
> Microsoft Windows Driver Model, Second Edition". In it are excellent
> descriptions of most common driver issues, including IRP handling.
>
> --
> Bill McKenzie
> Compuware Corporation
> Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
>
http://frontline.compuware.com/nashua/patches/utility.htm
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:u7HcBhq1DHA.1684@TK2MSFTNGP12.phx.gbl...
> > > If I call IoCompleteRequest in IoComplete routine, does it mean that
> > > the upper driver's IoComplete routine will be called before return
> > > control to dispatch routine?
> >
> > Surely. The first thing which IoCompleteRequest does - is calling the
> > completion routines registered in stack locations. This loop - shift the
> stack
> > up/call the completion, shift the stack up/call the completion etc.
> >
> > It is terminated and IoCompleteRequest does nothing more and quits if one
> of
> > the completions (possibly the first one) returns
> > STATUS_MORE_PROCESSING_REQUIRED. In this case, IoCompleteRequest is just
> to
> > "return the IRP back" to the upper layer, after it was received via the
> > dispatch routine.
> >
> > Another condition is when all stack locations are processed. In this case,
> > IoCompleteRequest queues the IopCompleteRequest APC to the IRP's thread.
> So,
> > such a condition must never occur for IRPs created by IoAllocateIrp and
> > IoBuildAsynchronousFsdRequest.
> >
> > Such a condition only occurs for IRPs created by IO manager as a result of
> > NtRead/Write/DeviceIoControlFile syscalls and for the IRPs allocated by
> > IoBuildSynchronousFsdRequest and IoBuildDeviceIoControlRequest.
> >
> > > HandleDeviceSetPower do nothing after call PoCallDriver.
> >
> > After Po/IoCallDriver, you must not touch the IRP till it will be
> delivered to
> > your completion routine.
> >
> > Power IRPs have only the following special to them:
> > - you must not wait in DispatchPower (yes, you can in DispatchPnP, but not
> in
> > DispatchPower). This can cause a deadlock, since the number of threads the
> OS
> > uses to deliver power IRPs can be limited. So, be as async as possible in
> > DispatchPower.
> > - you must use PoCallDriver and not IoCallDriver for some power IRPs
> (nearly
> > for all, look at the documentation for details).
> > - you must also use PoStartNextPowerIrp, which is a pairing function to
> > PoCallDriver. PoCallDriver blocks some internal queue, while
> > PoStartNextPowerIrp releases it.
> > - PoStartNextPowerIrp must be called on a power IRP before stack location
> > manipulation - i.e. before IoCopyCurrentIrpStackLocationToNext or
> > IoSkipCurrentIrpStackLocation.
> > - so, the code must be like:
> >
> > PoStartNextPowerIrp(Irp);
> > IoCopyCurrentIrpStackLocationToNext(Irp);
> > IoSetCompletionRoutine(...);
> > return PoCallDriver(...);
> >
> > - you must silently pass down all power IRPs unknown to you as:
> >
> > PoStartNextPowerIrp(Irp);
> > IoSkipCurrentIrpStackLocation(Irp);
> > return PoCallDriver(...);
> >
> > The Verifier checks this.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> >
http://www.storagecraft.com
> >
> >
>
>