Change Irp->IoStatus.Status in completion routine

NTFSD
1

Hi all,

Is it possible to change Irp->IoStatus.Status in completion routine for
filter driver? There is a problem with return value from IoCallDriver in
synchronous case, because it is coming from lower driver, that is original
status code, not changed status code.

How can I solve this situation? I must even solve it?

I have two ideas:

  1. Always return STATUS_PENDING from my dispatch. There is a little overhead
    (I/O manager cannot use optimization for synchronous completion, see
    IRP_DEFER_IO_COMPLETION)

  2. Pass correct status from completion routine to dispatch routine via Irp
    context (a structure allocated before dispatching and released after
    completion).

Second approach has IMHO two advantages:
a) Synchronous completion is not affected

b) Moreover, I can use this mechanism in situation, when I must perform
post-processing of request at PASSIVE_LEVEL and current IRQL is below. Then
the completion routine posts request to the working thread, pass to dispatch
STATUS_PENDING code and returns STATUS_MORE_PROCESSING_REQUIRED. (PS: This
approach must be used in situation, when a driver cannot block thread in
dispatch routine, as in file systems, and usual method using a event &
STATUS_MORE_PROCESSING_REQUIRED cannot be used.).

Any suggestions?

Thanks

Petr Borsodi

2

The problem with this approach is work done by the FSD - suppose you want to
return the status via completion for a Create, Rename or Delete? You return a
different status, while the FSD has already performed the operation… Not a
good situation.

Petr Borsodi wrote:

Hi all,

Is it possible to change Irp->IoStatus.Status in completion routine for
filter driver? There is a problem with return value from IoCallDriver in
synchronous case, because it is coming from lower driver, that is original
status code, not changed status code.

How can I solve this situation? I must even solve it?

I have two ideas:

  1. Always return STATUS_PENDING from my dispatch. There is a little overhead
    (I/O manager cannot use optimization for synchronous completion, see
    IRP_DEFER_IO_COMPLETION)

  2. Pass correct status from completion routine to dispatch routine via Irp
    context (a structure allocated before dispatching and released after
    completion).

Second approach has IMHO two advantages:
a) Synchronous completion is not affected

b) Moreover, I can use this mechanism in situation, when I must perform
post-processing of request at PASSIVE_LEVEL and current IRQL is below. Then
the completion routine posts request to the working thread, pass to dispatch
STATUS_PENDING code and returns STATUS_MORE_PROCESSING_REQUIRED. (PS: This
approach must be used in situation, when a driver cannot block thread in
dispatch routine, as in file systems, and usual method using a event &
STATUS_MORE_PROCESSING_REQUIRED cannot be used.).

Any suggestions?

Thanks

Petr Borsodi

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

3

You are right. But I not discuss these aspects now, I suppose that these
consequences must be resolved anyway.
BTW Create dispatch don’t make problems because of inherently synchronous
behaviour. I have in mind e.g Query Info, Read, etc. dispatch.

“Dejan Maksimovic” wrote:

>
> The problem with this approach is work done by the FSD - suppose you
want to
> return the status via completion for a Create, Rename or Delete? You
return a
> different status, while the FSD has already performed the operation… Not
a
> good situation.
>
> Petr Borsodi wrote:
>
> > Hi all,
> >
> > Is it possible to change Irp->IoStatus.Status in completion routine for
> > filter driver? There is a problem with return value from IoCallDriver in
> > synchronous case, because it is coming from lower driver, that is
original
> > status code, not changed status code.
> >
> > How can I solve this situation? I must even solve it?
> >
> > I have two ideas:
> >
> > 1) Always return STATUS_PENDING from my dispatch. There is a little
overhead
> > (I/O manager cannot use optimization for synchronous completion, see
> > IRP_DEFER_IO_COMPLETION)
> >
> > 2) Pass correct status from completion routine to dispatch routine via
Irp
> > context (a structure allocated before dispatching and released after
> > completion).
> >
> > Second approach has IMHO two advantages:
> > a) Synchronous completion is not affected
> >
> > b) Moreover, I can use this mechanism in situation, when I must perform
> > post-processing of request at PASSIVE_LEVEL and current IRQL is below.
Then
> > the completion routine posts request to the working thread, pass to
dispatch
> > STATUS_PENDING code and returns STATUS_MORE_PROCESSING_REQUIRED. (PS:
This
> > approach must be used in situation, when a driver cannot block thread in
> > dispatch routine, as in file systems, and usual method using a event &
> > STATUS_MORE_PROCESSING_REQUIRED cannot be used.).
> >
> > Any suggestions?
> >
> > Thanks
> >
> > Petr Borsodi
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> Kind regards, Dejan M. www.alfasp.com
> E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>