IO_STATUS_BLOCK vs. IoCallDriver

NTFSD
1

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?
I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!
Am I missing something here?

TIA,

Vladimir

2

You’re not missing anything. There’s a bug in FASTFAT where it returns an
uninitialized status variable from its IRP_MJ_CLOSE dispatch routine. Since
the IO Manager doesn’t check the return code, everything seems to work until
you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir

3

By the way, this appears to be fixed in W2K. You are seeing the problem
under NT 4.0?

-----Original Message-----
From: Rob Fuller [mailto:xxxxx@NSISW.COM]
Sent: Tuesday, August 08, 2000 1:50 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

You’re not missing anything. There’s a bug in FASTFAT where it returns an
uninitialized status variable from its IRP_MJ_CLOSE dispatch routine. Since
the IO Manager doesn’t check the return code, everything seems to work until
you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir

4

Thanks, Rob

Talking the generic way, can I say: “Newer relay on status returned from
IoCallDriver (except for STATUS_PENDING) use IO_STATUS_BLOCK.Status instead
(if it’s available)”?

Regards,

Vladimir

-----Original Message-----
From: Rob Fuller [mailto:xxxxx@NSISW.COM]
Sent: Tuesday, August 08, 2000 1:50 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

You’re not missing anything. There’s a bug in FASTFAT where it returns an
uninitialized status variable from its IRP_MJ_CLOSE dispatch routine. Since
the IO Manager doesn’t check the return code, everything seems to work until
you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir

5

This was fixed in Windows 2000.

-----Original Message-----
From: Rob Fuller [mailto:xxxxx@NSISW.COM]
Sent: Tuesday, August 08, 2000 11:50 AM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

You’re not missing anything. There’s a bug in FASTFAT where it returns
an uninitialized status variable from its IRP_MJ_CLOSE dispatch routine.
Since the IO Manager doesn’t check the return code, everything seems to
work until you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status
that I get from IoCallDriver (assuming it is not STATUS_PENDING) or I
should use Status field from IO_STATUS_BLOCK (for example, making a copy
of it in the completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while
IO_STATUS_BLOCK has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir

6

While I prefer general solutions, I don’t think the one you suggested will
solve your problems. I’ve seen FSD’s return an error code from dispatch and
forget to set Irp->IoStatus.Status. Consequently, I’ve had good luck with
code that looks like this:

if (NT_SUCCESS(Status))
Status = IoStatusBlock.Status;

…except of course in the case of IRP_MJ_CLOSE sent to FASTFAT.
Therefore, I suggest you handle IRP_MJ_CLOSE as an exception.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 1:57 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

Thanks, Rob

Talking the generic way, can I say: “Newer relay on status returned from
IoCallDriver (except for STATUS_PENDING) use IO_STATUS_BLOCK.Status instead
(if it’s available)”?

Regards,

Vladimir

-----Original Message-----
From: Rob Fuller [mailto:xxxxx@NSISW.COM]
Sent: Tuesday, August 08, 2000 1:50 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

You’re not missing anything. There’s a bug in FASTFAT where it returns an
uninitialized status variable from its IRP_MJ_CLOSE dispatch routine. Since
the IO Manager doesn’t check the return code, everything seems to work until
you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir

7

This brings up another issue, NT_SUCCESS(STATUS_PENDING) evaluates to TRUE.
Therefore, you should check for STATUS_PENDING before throwing away the
return value from IoCallDriver. So filling in more details, you generally
need something like this:

Status = IoCallDriver(…);

if (STATUS_PENDING == Status)
KeWaitForSingleObject(…);

if (NT_SUCCESS(Status))
Status = IoStatusBlock.Status;

Of course in the case of IRP_MJ_CLOSE you should always wait for completion,
unless it happens to properly return STATUS_PENDING, which I’ve never
evaluated. Also, as you mentioned, you should ignore the return code from
IoCallDriver for IRP_MJ_CLOSE.

-----Original Message-----
From: Rob Fuller
Sent: Tuesday, August 08, 2000 2:08 PM
To: ‘File Systems Developers’
Subject: RE: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

While I prefer general solutions, I don’t think the one you suggested will
solve your problems. I’ve seen FSD’s return an error code from dispatch and
forget to set Irp->IoStatus.Status. Consequently, I’ve had good luck with
code that looks like this:

if (NT_SUCCESS(Status))
Status = IoStatusBlock.Status;

…except of course in the case of IRP_MJ_CLOSE sent to FASTFAT.
Therefore, I suggest you handle IRP_MJ_CLOSE as an exception.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 1:57 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

Thanks, Rob

Talking the generic way, can I say: “Newer relay on status returned from
IoCallDriver (except for STATUS_PENDING) use IO_STATUS_BLOCK.Status instead
(if it’s available)”?

Regards,

Vladimir

-----Original Message-----
From: Rob Fuller [mailto:xxxxx@NSISW.COM]
Sent: Tuesday, August 08, 2000 1:50 PM
To: File Systems Developers
Subject: [ntfsd] RE: IO_STATUS_BLOCK vs. IoCallDriver

You’re not missing anything. There’s a bug in FASTFAT where it returns an
uninitialized status variable from its IRP_MJ_CLOSE dispatch routine. Since
the IO Manager doesn’t check the return code, everything seems to work until
you add a filter that checks the return code.

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, August 08, 2000 12:51 PM
To: File Systems Developers
Subject: [ntfsd] IO_STATUS_BLOCK vs. IoCallDriver

Hi everyone

When I call a driver using IoCallDriver, should I rely on the status that I
get from IoCallDriver (assuming it is not STATUS_PENDING) or I should use
Status field from IO_STATUS_BLOCK (for example, making a copy of it in the
completion routine)?

I’ve noticed, that when I call FastFat with a CLOSE IRP, IoCallDriver
returns some strange number (out of any known range) while IO_STATUS_BLOCK
has Status=STATUS_SUCCES!

Am I missing something here?

TIA,

Vladimir