STATUS_WORKING_SET_QUOTA Problem

NTFSD
1

Hi,

in my minifilter I’ve to link the dircontrol’s output for a Dir1 to the
dircontrol’s output for a Dir2 (IE the result of this is the sum of two
directory list).

To do so, I’ve used this code :

VOID SendDirectoryControl(

IN OUT PFLT_CALLBACK_DATA Data,

IN PDIR_CNTRL_CNTX DirCntrlCtx

)

{

PFLT_CALLBACK_DATA NewData = NULL;

if(NT_SUCCESS(FltAllocateCallbackData(

DirCntrlCtx->PrefixStruct->DestInstance,

DirCntrlCtx->RedirFileObject,

&NewData)))

{

NewData->Iopb->MajorFunction = Data->Iopb->MajorFunction;

NewData->Iopb->MinorFunction = Data->Iopb->MinorFunction;

NewData->Iopb->OperationFlags = DirCntrlCtx->OperationFlags;

NewData->Iopb->IrpFlags = DirCntrlCtx->IrpFlags;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.Length =
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.Length;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileName =
&DirCntrlCtx->Mask;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileInformatio
nClass =
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.FileInformationCl
ass;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileIndex =
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.FileIndex;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffe
r =
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress =
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress;

FltPerformSynchronousIo(NewData);

if(NT_SUCCESS(NewData->IoStatus.Status))

{

RtlCopyMemory(&Data->IoStatus,&NewData->IoStatus,sizeof(IO_STATUS_BLOCK)
);

FltSetCallbackDataDirty( Data );

}else

{

ObDereferenceObject(DirCntrlCtx->RedirFileObject);

FltClose(DirCntrlCtx->hRedirFile);

}

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress =
NULL;

FltFreeCallbackData(NewData);

}

}

But after about 2000 iteration, the FltPerformSynchronousIo give a
STATUS_WORKING_SET_QUOTA on the NewData->IoStatus.Status.

I’ve do something bad?

There’re no mem leak and I’ve run the driver with the verifier
activated.

The target machine is a XP SP2.

N.B:: I’ve seen that if I don’t put to NULL the
NewData->…QueryDirectory.MdlAddress when I call FltFreeCallbackData
the FltMgr try to free this field even if it was not populated by
FltAllocateCallbackData. It’s normal?

Thank’s

2

Working with windbg and perfmon, I saw that if FltPerformSynchronousIo(NewData) is commented, the pooled memory don’t grow and at the end of the process I don’t get an error from ntfs.sys about pages that aren’t DeLocked befor process’s exit.

I’t seems that I use FltPerformSynchronousIo in a wrong way.

But where I’m wrong?

Thank’s

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gian-luca Tenti
Sent: marted? 7 febbraio 2006 16.45
To: Windows File Systems Devs Interest List
Subject: [ntfsd] STATUS_WORKING_SET_QUOTA Problem

Hi,

in my minifilter I’ve to link the dircontrol’s output for a Dir1 to the dircontrol’s output for a Dir2 (IE the result of this is the sum of two directory list).

To do so, I’ve used this code :

VOID SendDirectoryControl(

IN OUT PFLT_CALLBACK_DATA Data,

IN PDIR_CNTRL_CNTX DirCntrlCtx

)

{

PFLT_CALLBACK_DATA NewData = NULL;

if(NT_SUCCESS(FltAllocateCallbackData(

DirCntrlCtx->PrefixStruct->DestInstance,

DirCntrlCtx->RedirFileObject,

&NewData)))

{

NewData->Iopb->MajorFunction = Data->Iopb->MajorFunction;

NewData->Iopb->MinorFunction = Data->Iopb->MinorFunction;

NewData->Iopb->OperationFlags = DirCntrlCtx->OperationFlags;

NewData->Iopb->IrpFlags = DirCntrlCtx->IrpFlags;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.Length = Data->Iopb->Parameters.DirectoryControl.QueryDirectory.Length;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileName = &DirCntrlCtx->Mask;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileInformationClass = Data->Iopb->Parameters.DirectoryControl.QueryDirectory.FileInformationClass;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.FileIndex = Data->Iopb->Parameters.DirectoryControl.QueryDirectory.FileIndex;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer = Data->Iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer;

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress = Data->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress;

FltPerformSynchronousIo(NewData);

if(NT_SUCCESS(NewData->IoStatus.Status))

{

RtlCopyMemory(&Data->IoStatus,&NewData->IoStatus,sizeof(IO_STATUS_BLOCK));

FltSetCallbackDataDirty( Data );

}else

{

ObDereferenceObject(DirCntrlCtx->RedirFileObject);

FltClose(DirCntrlCtx->hRedirFile);

}

NewData->Iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress = NULL;

FltFreeCallbackData(NewData);

}

}

But after about 2000 iteration, the FltPerformSynchronousIo give a STATUS_WORKING_SET_QUOTA on the NewData->IoStatus.Status.

I’ve do something bad?

There’re no mem leak and I’ve run the driver with the verifier activated.

The target machine is a XP SP2.

N.B:: I’ve seen that if I don’t put to NULL the NewData->…QueryDirectory.MdlAddress when I call FltFreeCallbackData the FltMgr try to free this field even if it was not populated by FltAllocateCallbackData. It’s normal?

Thank’s

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Gian-luca,
This may not be the answer , but if I understand your need you should only
be looking at IRP_MN_QUERY_DIRECTORY.

IRP_MN_NOTIFY_CHANGE_DIRECTORY operations (which I don’t think you care
about) are long lived by their nature and so not (I would say) suitable for
calling via FltPerformSynchronousIo

/rod

4

Hi Rod,

I hook only the IRP_MN_QUERY_DIRECTORY.
Now I’m going to do some search about the FltAllocateCallbackData and FltPerformSynchronousIo in the net, the problem is in these function.
I use the Data structure that come from the user’s request to the filter’s post-operation callback and if the query_directory_info result, for a specific directory (IE Dir1), is an error then I create a new Data (NewData), I copy the QueryDirectory structure from the original Data to the NewData, and then I send the request for the redirected directory (Dir2).
If from Dos you launch a dir of Dir1, you get the sum of Dir1 and Dir2. This work.
But when I sen the request with FltPerformSynchronousIo the pool mem grow, after about 1000 iteration I receive STATUS_WORKING_SET_QUOTA as error and when the process that do the dir requests close, the ntfs.sys generate a BSOD with a message like this: a driver don’t unlock it’s mem page before exit.
If I comment the FltPerformSynchronousIo there is no mem increment and no BSOD (but clearly the two dir aren’t linked).

Gian-Luca

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: marted? 7 febbraio 2006 19.50
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] STATUS_WORKING_SET_QUOTA Problem

Gian-luca,
This may not be the answer , but if I understand your need you should only
be looking at IRP_MN_QUERY_DIRECTORY.

IRP_MN_NOTIFY_CHANGE_DIRECTORY operations (which I don’t think you care
about) are long lived by their nature and so not (I would say) suitable for
calling via FltPerformSynchronousIo

/rod

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

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

5

Gian-luca,

I’m not sure I can help you further: I’ve not used these interfaces heavily,
but if it were me, I would start to strip out the caller’s parameter from
your new data request and see what happens. I’d start with DirectoryBuffer
& MdlAddress (this last would certainly be indicate if ntfs is complaining
about buffers not unlocking pages…) and replace them with a poineter to
some space (of size length) of your own…

As as side issue I’m not convinced that the tactic of blindly reposting on
an error is correct, nor yet that this will work when you get
STATUS_NO_MORE_FILES back from your syncrhonous IO. Also I’m unconvinced
that you can just copy FileIndex like that… Does this technique work
(prior to the loss of quota) for huge directories?

/rod

6

Hi Rod,

now is ok with this:

NewData->Iopb->IrpFlags |= IRP_SYNCHRONOUS_API;

I’ve no problem now.

Thank’s

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: mercoled? 8 febbraio 2006 12.27
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] STATUS_WORKING_SET_QUOTA Problem

Gian-luca,

I’m not sure I can help you further: I’ve not used these interfaces heavily,
but if it were me, I would start to strip out the caller’s parameter from
your new data request and see what happens. I’d start with DirectoryBuffer
& MdlAddress (this last would certainly be indicate if ntfs is complaining
about buffers not unlocking pages…) and replace them with a poineter to
some space (of size length) of your own…

As as side issue I’m not convinced that the tactic of blindly reposting on
an error is correct, nor yet that this will work when you get
STATUS_NO_MORE_FILES back from your syncrhonous IO. Also I’m unconvinced
that you can just copy FileIndex like that… Does this technique work
(prior to the loss of quota) for huge directories?

/rod

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

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