Validating RelatedFileObject of irpstack->FileObject

Hi

I am working on a file system filter driver. I want to get the full path
name in both the cases(absolute as well as relative)

  1. when irpStack->FileObject->RelatedFileObject is NULL(absolute)

In this case irpStack->FileObject->FileName.Buffer is used for generating
the filename

  1. when RelatedFileObject is not NULL(relative)

In this case both related fileobject and fileobject are used for generating
the filename.

Am i using the right approach. Please clarify

following is the code for generating filename from related file object and
fileobject.I am using filespy as base code and making modification above
that code.This code is placed inside spypassthrough function of filespy
code. The system crashes around ten minutes after system is rebooted. We
have make the filter driver as boot time driver.

if((pIrpStack != NULL) && (pIrpStack->FileObject != NULL)
&&(pIrpStack->FileObject->FileName.Length != 0))
if((pDevExt!= NULL) && pDevExt->UserNames.Length != 0)
{
ULONG ulLen,ulLenRelatedFileObject=0;
if(pIrpStack->FileObject->RelatedFileObject)
{
ulLenRelatedFileObject =
pIrpStack->FileObject->RelatedFileObject->FileName.Length ;
ulLen= ulLenRelatedFileObject + pIrpStack->FileObject->
FileName.Length+pDevExt->UserNames.Length+2;

}
else
ulLen=pIrpStack->FileObject->FileName.Length+pDevExt->
UserNames.Length+2;
pFileName = ExAllocatePool(NonPagedPool,ulLen); //added 2
for UNICODE_NULL
if(pFileName){

wcsncpy(pFileName , pDevExt->UserNames.Buffer ,pDevExt->
UserNames.Length/sizeof(WCHAR) );
if(pIrpStack->FileObject->RelatedFileObject &&
ulLenRelatedFileObject)
wcsncpy(pFileName
+pDevExt->UserNames.Length/sizeof(WCHAR),
pIrpStack->FileObject->RelatedFileObject->FileName.Buffer,ulLenRelatedFileObject/sizeof(WCHAR)
); //Line
containg the error
wcsncpy(pFileName + (pDevExt->UserNames.Length +
ulLenRelatedFileObject)/sizeof(WCHAR) , pIrpStack->FileObject->
FileName.Buffer ,(pIrpStack->FileObject->FileName.Length)/sizeof(WCHAR));
pFileName[(ulLen - 2)/sizeof(WCHAR)] = UNICODE_NULL;

}

}

I will be very thankful if anyone can tell me why this is happening

Refer to filespy source for method to construct name and also note that you
can never use FileObject->RelatedFileObject->FileName.Buffer

“Rohit” wrote in message news:xxxxx@ntfsd…
Hi

I am working on a file system filter driver. I want to get the full path
name in both the cases(absolute as well as relative)

1) when irpStack->FileObject->RelatedFileObject is NULL(absolute)

In this case irpStack->FileObject->FileName.Buffer is used for generating
the filename

2) when RelatedFileObject is not NULL(relative)

In this case both related fileobject and fileobject are used for generating
the filename.

Am i using the right approach. Please clarify

Hi

I am making filters based upon filename including full path.
Query for the filename to the filesystem everytime RelatedFileObject Not
NULL is very expensive since we are doing this for every IRP.

It would be very helpful if you tell me the bug in this code. Ok is it
possible that if the current irp is other than or may be CREATE,
ReletiveFileObject is referencing to the memory which is already freed.

Regards
Rohit Gauba

Everything you are doing is wrong, and is explained about 10,000 times in the archives of this list.

You cannot access FileObject->FileName or FileObject->RelatedFileObject except in create dispatch. You’ll crash.

You cannot query the file name willy nilly (that’s a technical term) for every IRP. You’ll deadlock.

You need to (correctly) get the name in create and save it in your per-fcb context.

  • Dan.

----- Original Message -----
From: Rohit
To: Windows File Systems Devs Interest List
Sent: Friday, June 30, 2006 7:40 AM
Subject: Re:[ntfsd] Validating RelatedFileObject of irpstack->FileObject

Hi

I am making filters based upon filename including full path.
Query for the filename to the filesystem everytime RelatedFileObject Not NULL is very expensive since we are doing this for every IRP.

It would be very helpful if you tell me the bug in this code. Ok is it possible that if the current irp is other than or may be CREATE, ReletiveFileObject is referencing to the memory which is already freed.

Regards
Rohit Gauba
— Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: xxxxx@privtek.com To unsubscribe send a blank email to xxxxx@lists.osr.com

>>>Refer to filespy source for method to construct name and also note that
you

>>can never use FileObject->RelatedFileObject->FileName.Buffer

Lyndon

Cann’t we use FileObject->RelatedFileObject->FileName.Buffer(RelatedFileObject
!= NULL && RelatedFileObject->
FileName.Length > 0 ) in pre create

Regards
Rohit

Absolutely not.

You must query the file system for the name of the related file object.

FileObject->FileName is valid only in create dispatch. This is not the
create for FileObject->RelatedFileObject. It is already open, and the file
name field may not be accessed.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rohit
Sent: Monday, July 03, 2006 7:32 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Validating RelatedFileObject of irpstack->FileObject

>>Refer to filespy source for method to construct name and also note that
you
>>can never use FileObject->RelatedFileObject->FileName.Buffer

Lyndon

Cann’t we use FileObject->RelatedFileObject->FileName.Buffer
(RelatedFileObject != NULL && RelatedFileObject->FileName.Length > 0 ) in
pre create

Regards
Rohit
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: xxxxx@privtek.com To unsubscribe send a blank email to
xxxxx@lists.osr.com