Timeout on network IRP_MJ_QUERY_INFORMATION

Hi,

Sometimes applications open a file without using the FILE_DIRECTORY_FILE or
the FILE_NON_DIRECTORY_FILE flag (Windows Explorer to name one).

In the Create completion routine, I want to know whether the open file
object is of a file or a directory so I issue an IRP_MJ_QUERY_INFORMATION
request.
However, if the file object is of a directory on the network, I get
STATUS_PENDING from the IoCallDriver call but the waiting event is never
signalled so unless I specify a timeout for the KeWaitForSingleObject the
thread is permenantly stuck.

Any suggestions ?
Rami


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

Rami,

At what IRQL are you calling KeWaitForSingleObject? I’m guessing that you
are at APC_LEVEL, which could explain why your event is never signaled (the
I/O Manager uses an APC to perform this task, but at APC_LEVEL, the delivery
of APCs is blocked). If this is the case, you will need to perform the
signaling manually by setting your own event in your completion routine.

I hope this helps.

Regards,

Tony

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

See the new NTFSD FAQ on the OSR Web Site!
-----Original Message-----
From: xxxxx@aliroo.com [mailto:xxxxx@aliroo.com]
Sent: Sunday, December 02, 2001 4:52 AM
To: File Systems Developers
Subject: [ntfsd] Timeout on network IRP_MJ_QUERY_INFORMATION

Hi,

Sometimes applications open a file without using the FILE_DIRECTORY_FILE or
the FILE_NON_DIRECTORY_FILE flag (Windows Explorer to name one).

In the Create completion routine, I want to know whether the open file
object is of a file or a directory so I issue an IRP_MJ_QUERY_INFORMATION
request.
However, if the file object is of a directory on the network, I get
STATUS_PENDING from the IoCallDriver call but the waiting event is never
signalled so unless I specify a timeout for the KeWaitForSingleObject the
thread is permenantly stuck.

Any suggestions ?
Rami


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

If you can do it in another routine - i.e. after IRP_MJ_CREATE processing,
do it.
If not, split the IRP into one that has FILE_NON_DIRECTORY_FILE flag, and
if it fails issue it with the original “no flag” (or with FILE_DIRECTORY_FILE).
This works.

Regards, Dejan.

xxxxx@aliroo.com wrote:

Hi,

Sometimes applications open a file without using the FILE_DIRECTORY_FILE or
the FILE_NON_DIRECTORY_FILE flag (Windows Explorer to name one).

In the Create completion routine, I want to know whether the open file
object is of a file or a directory so I issue an IRP_MJ_QUERY_INFORMATION
request.
However, if the file object is of a directory on the network, I get
STATUS_PENDING from the IoCallDriver call but the waiting event is never
signalled so unless I specify a timeout for the KeWaitForSingleObject the
thread is permenantly stuck.

Any suggestions ?
Rami


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


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32 developers.


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

> At what IRQL are you calling KeWaitForSingleObject? I’m guessing that you are

at APC_LEVEL, which could explain why your event is never signaled (the I/O
Manager uses an APC to perform this task, but at APC_LEVEL, the delivery of
APCs is blocked).

Since it’s in the completion routine, it’s very possible that it’s
DISPATCH_LEVEL rather.

If this is the case, you will need to perform the signaling manually by
setting your own event in your completion routine.

Where else would he do it? (I’m assuming in the completion for the query
call itself?)


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32 developers.


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

On 12/02/01, “Dejan Maksimovic ” wrote:
> > At what IRQL are you calling KeWaitForSingleObject? I’m guessing that you are
> > at APC_LEVEL, which could explain why your event is never signaled (the I/O
> > Manager uses an APC to perform this task, but at APC_LEVEL, the delivery of
> > APCs is blocked).
>

PASSIVE_LEVEL

> > If this is the case, you will need to perform the signaling manually by
> > setting your own event in your completion routine.
>
I already do that
The problem is that my completion routine is never called !
My guess is that the Irp is stuck on the network. Bare in mind that the
problem only happens when I query on a folder and not on a file.

As for performing the original IRP_CREATE twice, each time specifying
DIRECTORY or NON_DIRECTORY, I tried that a while back but I had a problem
of receiving a bug check on the second Irp I passed. It had something to do
with having the same completion routine called twice for the same Irp.
My guess was that some other driver (Anti Virus ?) which registered a
completion routine for the create operation received two calls for its
completion routine because I passed down the Irp twice.


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

> > > At what IRQL are you calling KeWaitForSingleObject? I’m guessing that you are

> > at APC_LEVEL, which could explain why your event is never signaled (the I/O
> > Manager uses an APC to perform this task, but at APC_LEVEL, the delivery of
> > APCs is blocked).

PASSIVE_LEVEL

Do note that an IRP_MJ_CREATE might execute at DISPATCH_LEVEL -
though it’s
unlikely, but I’ve seen it.
So, if you continue your way, do the processing in a worker thread,
and return
STATUS_MORE_PROCESSING_REQUIRED in the completion.

I already do that
The problem is that my completion routine is never called !
My guess is that the Irp is stuck on the network. Bare in mind that the
problem only happens when I query on a folder and not on a file.

Hmm, can you post the code for the query?

As for performing the original IRP_CREATE twice, each time specifying
DIRECTORY or NON_DIRECTORY, I tried that a while back but I had a problem of
receiving a bug check on the second Irp I passed. It had something to do with having
the same completion routine called twice for the same Irp. My guess was that some
other driver (Anti Virus ?) which registered a completion routine for the create
operation received two calls for its completion routine because I passed down the
Irp twice.

It must be a bug in calling…
Always set your completion routine, and let it return
STATUS_MORE_PROCESSING_REQUIRED, and set the event. In the dispatch wait
for the
event, and if the call was unsuccessful, recall it.
Call IoCompleteRequest after all this.


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.


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

>

Hmm, can you post the code for the query?

Here is the query code:
// Initialize the completion event
KeInitializeEvent(&CompletionEvent, NotificationEvent, FALSE);

// Create and initialize the IRP
StackSize = pTargetDeviceObject->StackSize;
pNewIrp = IoAllocateIrp(StackSize, FALSE);
pNewIrp->AssociatedIrp.SystemBuffer =(PVOID)pInfo;
pNewIrp->UserEvent = &CompletionEvent;
pNewIrp->UserIosb = &IoStatus;
pNewIrp->Tail.Overlay.Thread = PsGetCurrentThread();
pNewIrp->Tail.Overlay.OriginalFileObject = pFileObject;
pNewIrp->RequestorMode =
KernelMode;//ExGetPreviousMode();

// Initialize the next IRP stack location
pNextStackLocation = IoGetNextIrpStackLocation(pNewIrp);

pNextStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pNextStackLocation->MinorFunction = IRP_MN_NORMAL;

pNextStackLocation->DeviceObject = pTargetDeviceObject;
pNextStackLocation->FileObject = pFileObject;

pNextStackLocation->Parameters.QueryFile.Length = InfoSize;
pNextStackLocation->Parameters.QueryFile.FileInformationClass =
InfoClass;

// Set the completion routine
IoSetCompletionRoutine(pNewIrp, IrpCompletionRoutine, NULL, TRUE, TRUE,
TRUE);

oldTopLevelIrp = IoGetTopLevelIrp();
IoSetTopLevelIrp(NULL);

// Send the request to the lower layer driver
ntStatus = IoCallDriver(pTargetDeviceObject, pNewIrp);

// Wait for the I/O completion
if (ntStatus == STATUS_PENDING)
KeWaitForSingleObject(&CompletionEvent, Executive, KernelMode, TRUE,
NULL);

IoSetTopLevelIrp(oldTopLevelIrp);

And here is the completion code:
IrpCompletionRoutine(
PDEVICE_OBJECT pDeviceObject,
PIRP pIrp,
PVOID pContext)
{
if (pIrp->UserIosb)
*pIrp->UserIosb = pIrp->IoStatus;
if (pIrp->UserEvent)
KeSetEvent(pIrp->UserEvent, 0, FALSE);
IoFreeIrp(pIrp);
return STATUS_MORE_PROCESSING_REQUIRED;
}

> As for performing the original IRP_CREATE twice, each time specifying
> DIRECTORY or NON_DIRECTORY, I tried that a while back but I had a problem of
> receiving a bug check on the second Irp I passed. It had something to do with having
> the same completion routine called twice for the same Irp. My guess was that some
> other driver (Anti Virus ?) which registered a completion routine for the create
> operation received two calls for its completion routine because I passed down the
> Irp twice.

It must be a bug in calling…
Always set your completion routine, and let it return
STATUS_MORE_PROCESSING_REQUIRED, and set the event. In the dispatch wait
for the
event, and if the call was unsuccessful, recall it.
Call IoCompleteRequest after all this.

I thought the whole point of the completion routine is to put the code
there and not in the IRP handler function.
What is the difference between handling the operation at the completion
rountine and handling it after the IoCallDriver returns at the dispatch
routine ?


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

> Do note that an IRP_MJ_CREATE might execute at DISPATCH_LEVEL -

though it’s
unlikely, but I’ve seen it.

Amazing. FASTFAT’s CREATE path will fail on it.

Max


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

No, IRP_MJ_CREATE dispatch will never be called at DISPATCH_LEVEL.
If somebody passes the create IRP down at DISPATCH_LEVEL it’s a bug.
I’d infact encourage you to make the create dispatch pageable. Most
filesystems do anyways.

Ravi


This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Monday, December 03, 2001 3:11 AM
To: File Systems Developers
Subject: [ntfsd] RE: Timeout on network IRP_MJ_QUERY_INFORMATION

> > At what IRQL are you calling KeWaitForSingleObject? I’m guessing
> > that you are at APC_LEVEL, which could explain why your event is
> > never signaled (the I/O Manager uses an APC to perform this task,
> > but at APC_LEVEL, the delivery of APCs is blocked).

PASSIVE_LEVEL

Do note that an IRP_MJ_CREATE might execute at DISPATCH_LEVEL -
though it’s unlikely, but I’ve seen it.
So, if you continue your way, do the processing in a worker thread,
and return STATUS_MORE_PROCESSING_REQUIRED in the completion.

I already do that
The problem is that my completion routine is never called ! My guess
is that the Irp is stuck on the network. Bare in mind that the problem

only happens when I query on a folder and not on a file.

Hmm, can you post the code for the query?

As for performing the original IRP_CREATE twice, each time specifying
DIRECTORY or NON_DIRECTORY, I tried that a while back but I had a
problem of receiving a bug check on the second Irp I passed. It had
something to do with having the same completion routine called twice
for the same Irp. My guess was that some other driver (Anti Virus ?)
which registered a completion routine for the create operation
received two calls for its completion routine because I passed down
the Irp twice.

It must be a bug in calling…
Always set your completion routine, and let it return
STATUS_MORE_PROCESSING_REQUIRED, and set the event. In the dispatch wait
for the event, and if the call was unsuccessful, recall it.
Call IoCompleteRequest after all this.


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers. Alfa
File Protector - File protection and hiding system for Win32 developers.


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.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

Sorry, meant IRP_MJ_CREATE completion:-)))

“Maxim S. Shatskih” wrote:

> Do note that an IRP_MJ_CREATE might execute at DISPATCH_LEVEL -
> though it’s
> unlikely, but I’ve seen it.

Amazing. FASTFAT’s CREATE path will fail on it.

Max


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


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.


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

I agree - as I mentioned in reply to Max, I was talking about completion
routine, as the original poster mentioned that he uses KeWaitForSingleObject
in the IRP_MJ_CREATE completion.

Regards, Dejan.

Ravisankar Pudipeddi wrote:

No, IRP_MJ_CREATE dispatch will never be called at DISPATCH_LEVEL.
If somebody passes the create IRP down at DISPATCH_LEVEL it’s a bug.
I’d infact encourage you to make the create dispatch pageable. Most
filesystems do anyways.

Ravi


This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Monday, December 03, 2001 3:11 AM
To: File Systems Developers
Subject: [ntfsd] RE: Timeout on network IRP_MJ_QUERY_INFORMATION

> > > At what IRQL are you calling KeWaitForSingleObject? I’m guessing
> > > that you are at APC_LEVEL, which could explain why your event is
> > > never signaled (the I/O Manager uses an APC to perform this task,
> > > but at APC_LEVEL, the delivery of APCs is blocked).
>
> PASSIVE_LEVEL

Do note that an IRP_MJ_CREATE might execute at DISPATCH_LEVEL -
though it’s unlikely, but I’ve seen it.
So, if you continue your way, do the processing in a worker thread,
and return STATUS_MORE_PROCESSING_REQUIRED in the completion.

> I already do that
> The problem is that my completion routine is never called ! My guess
> is that the Irp is stuck on the network. Bare in mind that the problem

> only happens when I query on a folder and not on a file.

Hmm, can you post the code for the query?

> As for performing the original IRP_CREATE twice, each time specifying
> DIRECTORY or NON_DIRECTORY, I tried that a while back but I had a
> problem of receiving a bug check on the second Irp I passed. It had
> something to do with having the same completion routine called twice
> for the same Irp. My guess was that some other driver (Anti Virus ?)
> which registered a completion routine for the create operation
> received two calls for its completion routine because I passed down
> the Irp twice.

It must be a bug in calling…
Always set your completion routine, and let it return
STATUS_MORE_PROCESSING_REQUIRED, and set the event. In the dispatch wait
for the event, and if the call was unsuccessful, recall it.
Call IoCompleteRequest after all this.


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers. Alfa
File Protector - File protection and hiding system for Win32 developers.


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


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


Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.


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