Regarding - Error code 0x24(NTFS_FILE_SYSTEM)

Hi developers !

We’re developing Virtual File & Directory filter driver. (it’s ASP client
engine)

It’s works well under FAT.

but, it rarely cause BSOD:0x24(NTFS_FILE_SYSTEM) under NTFS (Windows 2000
Pro).

and softice shows following infomation.


call IoGetTopLevelIrp
push dword ptr [eax+0x14] <----- eax == 0, so die


I think my filter driver is an indirect cause of BSOD.

how can I fix this bugs?

I’m miserable…

any help will greatly appreciated.

Terra.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Well, it is certainly possible to cause problems along these lines. It
sounds to me like you are calling NTFS in some fashion that it expects to
find something stored in the top level IRP field (which is the whole point
of IoGetTopLevelIrp.) Offset 0x14 would correspond to the “Blink” pointer
in the IRP, and somehow I suspect that’s not what’s really there, so this is
probably some sort of data structure instead.

Are you calling NTFS with IRPs that you are constructing on your own? Are
you calling from completion routines? SOMETHING is causing NTFS to make
assumptions that must not be true when your filter is involved.

Of course, more information might trigger other ideas - like a stack
backtrace, for instance, or other information (like the bug check analysis
from WinDBG.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@softonnet.com [mailto:xxxxx@softonnet.com]
Sent: Saturday, September 15, 2001 12:47 AM
To: File Systems Developers
Subject: [ntfsd] Regarding - Error code 0x24(NTFS_FILE_SYSTEM)

Hi developers !

We’re developing Virtual File & Directory filter driver. (it’s ASP client
engine)

It’s works well under FAT.

but, it rarely cause BSOD:0x24(NTFS_FILE_SYSTEM) under NTFS (Windows 2000
Pro).

and softice shows following infomation.


call IoGetTopLevelIrp
push dword ptr [eax+0x14] <----- eax == 0, so die


I think my filter driver is an indirect cause of BSOD.

how can I fix this bugs?

I’m miserable…

any help will greatly appreciated.

Terra.


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thanks, Tony.

I am very grateful for your concern.


> Are you calling NTFS with IRPs that you are constructing on your own?
No, I’m not using my own IRPs. but I call ZwXXX functions in dispatch
routine.

> Are you calling from completion routines?
No. I’m not using any completiong routine.

I found out TopLevelIRP value causes BSOD.
when TopLevelIRP value is greater than 0x04
(i.e. TopLevelIRP value is IRP pointer), BSOD occurs.
in particular, whenever I do file copy operation, always BSOD occurs.
in my guess, paged or cached opration may causes BSOD.

my algorithm is following…

NTSTATUS ReadDispatch (IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{

if (FileObject’s path is in my target directory)
{
// Read Some other directory’s file and fill read buffer.
// it’s different directory. so there is no reenterance problem.
// I don’t care about cached read or memory mapped read.

pTop = IoGetTopLevelIrp();

> if(pTop>(PIRP)0x4) // when I add this line, BSOD not occur,
> { // but original file’s data fills read buffer.
> goto No_Hook; //
> }

IoCompleteRequest( Irp, IO_NO_INCREMENT );
return status;
}

No_Hook:
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver( hookExt->FileSystem, Irp );
}


If there’s anyone who knows the situation like above, please let me know.

any help will greatly appreciated.

Best Regard,
Terra.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Terra,

One of your statements is, unfortunately, false and it probably leads to the
issues that you are observing. You stated “it’s different directory. so
there is no reenterance problem” in a comment within the code.

Unfortunately, the fact that it is a different directory would indicate that
you DO have a reentrancy problem. That is because you are calling into the
file system after the file system has already been invoked.

Since there’s still not enough information here for me to pinpoint your
problem, I can at least suggest a mechanism for breaking the reentrancy (and
hence the file system’s use of the top level IRP.) Instead of “skipping”
the stack location in your code, post the request to a worker thread (yours
or an OS-provided worker thread.) Since this is dispatch entry code, you
will be called at APC_LEVEL or below, so it is safe to block (in this
thread) for the other thread to complete the I/O operation.

While I can’t guarantee that this will fix your problem, it will eliminate
the thread-level reentrancy you have and that will probably change the
behavior substantially.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@softonnet.com [mailto:xxxxx@softonnet.com]
Sent: Monday, September 17, 2001 6:14 PM
To: File Systems Developers
Subject: [ntfsd] RE: Regarding - Error code 0x24(NTFS_FILE_SYSTEM)

Thanks, Tony.

I am very grateful for your concern.


> Are you calling NTFS with IRPs that you are constructing on your own?
No, I’m not using my own IRPs. but I call ZwXXX functions in dispatch
routine.

> Are you calling from completion routines?
No. I’m not using any completiong routine.

I found out TopLevelIRP value causes BSOD.
when TopLevelIRP value is greater than 0x04
(i.e. TopLevelIRP value is IRP pointer), BSOD occurs.
in particular, whenever I do file copy operation, always BSOD occurs.
in my guess, paged or cached opration may causes BSOD.

my algorithm is following…

NTSTATUS ReadDispatch (IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{

if (FileObject’s path is in my target directory)
{
// Read Some other directory’s file and fill read buffer.
// it’s different directory. so there is no reenterance problem.
// I don’t care about cached read or memory mapped read.

pTop = IoGetTopLevelIrp();

> if(pTop>(PIRP)0x4) // when I add this line, BSOD not occur,
> { // but original file’s data fills read buffer.
> goto No_Hook; //
> }

IoCompleteRequest( Irp, IO_NO_INCREMENT );
return status;
}

No_Hook:
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver( hookExt->FileSystem, Irp );
}


If there’s anyone who knows the situation like above, please let me know.

any help will greatly appreciated.

Best Regard,
Terra.


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com