AntonBassov
Fri Mar 09 20:23:13 CST 2007
> LOL...You are taking the doc too too literately....
> See Eliyas's excellent explanations and demo code.
Unfortunately, his explanation is just "insider info", rather than
documented behaviour of IoCompleteRequest(). Indeed, as it turns out,
IoMarkIrpPending()
call by the driver is unnecessary, simply because, unless the completion
routine returns STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest() calls
IoMarkIrpPending() anyway if Irp->PendingReturned is set. In other words,
IoCompleteRequest() does something that, according to the doc I quoted,
should be done by the completion routine, so that doing the same thing in the
completion routine is simply unnecessary.
However, officially all the above is undocumented behaviour, so that MSFT
can change it at whenever it wants - after all, if some problem arises, they
can always say that you just haven't followed their guidelines.....
> Maybe I should have shown you the list
> of DDK doc bugs I've submitted over the years.
This is not really a bug - if you do it the way this doc says, you are not
going to get into any trouble. Therefore, this is just a "harmless"
discrepancy between DDK documentation and *CURRENTLY EXISTING* implementation
of IoCompleteRequest() that can be changed without breaking drivers that do
things the way the doc says.
Unfortunately, from time to time you can come across much more serious
"omissions" in the official documentation ( for example, WFP documentation
that came with RTM WDK is virtually unusable)....
Anton Bassov
"Calvin Guan" wrote:
> "Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in message
> news:C7D1E53D-8C62-4F4F-BE43-BC9BD8056BE2@microsoft.com...
> > Calvin,
> >
> >> It's ok not to mark pending while
> >> returning !STATUS_MORE_PROCESSING_REQUIRED.
> >
> > Here is the quotation from IoMarkIrpPending documentation in WDK
> >
> > [begin quote]
> >
> > If a driver sets an IoCompletion routine for an IRP and then passes the
> > IRP
> > down to a lower driver, the IoCompletion routine should check the
> > IRP->PendingReturned flag. If the flag is set, the IoCompletion routine
> > must
> > call IoMarkIrpPending with the IRP.
> >
> > [end quote]
> >
> > As you can see, according to MSDN, unless you abort the call chain of
> > completion routines by returning STATUS_MORE_PROCESSING_REQUIRED,
> > IoMarkIrpPending() is an absolute must here. It seems to be a pointless
> > call,
> > but it is not - you will see it shortly
> >
> >> NTSTATUS CompRoutine(irp)
> >> {
> >> //do whatever with the IRP
> >> return STATUS_CONTINUE_COMPLETION;
> >> }
> >
> > As you will see below, the above code has quite insidious bug in it....
> >
>
> LOL...You are taking the doc too too literately.... See Eliyas's excellent
> explanations and demo code.
>
> >
> >> it doesn't make sense while setting a bit that nobody cares.
> >
> > Well, this is quite bold statement. The problem is that, although the OS,
> > apparently, does not really care about it, some third-party drivers may
> > do.
> > Consider the following scenario:
> >
>
> I obviously didn't make it clear for some people to understand what I was
> trying to say. Let me expand a bit.
>
> VOID func_a()
> {
> IoGetDeviceObjectPointer(...,&pDevObject);
> irp = IoAllocateIrp(); // with no extra stack;
> /// setup IRP stack.
> IoSetCompetionRoutine(irp,CompRoutine,...);
> IoCallDriver();
> return;
> }
>
> NTSTATUS
> CompRoutine(irp)
> {
> if (Irp->PendingReturned)
> {
> /// do NOT mark pending regardless what code you return,
> /// it's fatal error - a logical one.
> }
> ObDereferenceObject(devobj);
> IoFreeIrp(Irp);
> return SMPR;
> }
>
> > What happens if you write your completion routine the way you have
> > described,
> > and this "optimized" driver happens to be above you on the stack? The
> > answer
> > is obvious - if you don't propagate PendingReturned flag, this driver
> > will
> > always believe that IRP has been completed synchronously, and, hence, will
> > never call
> > KeSetEvent(). Therefore, if IoCallDriver() call that he makes from his
> > Dispatch routine returns STATUS_PENDING, his Dispatch routine is going
> > to
> > deadlock......
> >
> > This is just a classical example of how one may get into a conflict with
> > the
> > third-party software because of avoiding some seemingly pointless call
> > that,
> > according to MSDN, he should make....
> >
>
> I've been writing almost all kind of IRP completion combinations. My drivers
> are running on millions of NT systems for years. They are not in the habit
> of croaking.
>
> > according to MSDN
>
> If someone can not understand what the document really wants to say, he just
> can't write a solid driver, period. Maybe I should have shown you the list
> of DDK doc bugs I've submitted over the years.
>
> --
> Calvin Guan (expiring DDK MVP)
> Sr. Staff Engineer
> NetXtreme NTX Miniport
> Broadcom Corporation
> Connecting Everything(r)
>
>
>