Everhart, Glenn (FUSA)
From: Rajeev Nagar [rnagar@ntcoresvcs.com]
Sent: Monday, May 17, 1999 12:16 PM
To: Yogita Bijani; ntfsd@atria.com; ntdev@atria.com
Subject: RE: Re : Re: [ntdev] [ntfsd] write timeout ??
Yogita:
Your driver appears to be filtering disk i/o requests *below* a FSD.
In this situation, most i/o requests you will receive will be "paging i/o"
requests. Some of these requests may also be targeted to page files.
Some requests (sometimes, an overlapping set) will have been initiated
by the VMM. Other requests may have been initiated via the Win32
(or other) subsystem (again, an overlapping set).
You appear to be "bouncing" requests back to user-space. If your user-space
application does any of the following:
(a) encounter a page fault
(b) call back into the Win32 subsystem (which has it's own locking
hierarchy)
(c) recurse back on the same file
OR a myriad other situations, you will likely cause a form of "deadlock".
Basically, the level at which your driver exists in the I/O stack is not very
conducive to doing the kind of processing you are doing.
With further details on your requirements, perhaps I or others on the list
may be able to offer more constructive comments?
Regards,
- rajeev
*****************************************************************
Name: Rajeev Nagar
Email: rnagar@ntcoresvcs.com
Web: < >, < >
Voice: (408) 246 3623 x11
Fax: (408) 248 7004
Providing accurate, reliable information and services to
Windows NT kernel-mode developers. Register at our web site
for more information on developing Windows NT kernel-mode drivers
*****************************************************************
-----Original Message-----
From: owner-ntfsd@atria.com [mailto:owner-ntfsd@atria.com]On Behalf Of Yogita Bijani
Sent: Monday, May 17, 1999 6:37 AM
To: ntfsd@atria.com; ntdev@atria.com
Subject: Re : Re: [ntdev] [ntfsd] write timeout ??
Hi!
Continuing with the description of my filter driver ...
I'm calling IoMarkPending() before queing the IRP to a queue global
to the driver and then returning STATUS_PENDING from the Dispatch
Routine.
In another Dispatch Routine( DeviceioControl ), I pass the details to a
user process for some processing and once it is done with it , I get
another IRP (DeviceIoControl ) to signal that the IRP can be passed to the
next lower level driver.
I am not setting a Cancel Routine while queuing the IRP which could be
the reason why system crashes when I abort an application . Thanks a lot for
your suggestion, I'll be adding that soon.
But the hang problem remains ...
According to Task Manager Performance Window, values of
Physical Memory
File Cache
Kernel Memory
both Paged and Non Paged
Commit Charge
Total
all seem well below the maximum
What other parameter, if any, can I monitor through Performance Monitor
or some other tool to find which system limit is being reached ?
thanks for the help
yogita
Jamie Hanrahan wrote :
>Giga Giguashvili writes:
>> 4) You say that the system hangs when you try to copy several files.
>> Usually, file operations
>> including copy are synchronous. After you block an IRP, all the next
>> ones will wait for their
>> turn to get processed in your dispatch routine.
>
>I think that after he holds onto a bunch and tries to do yet more
>file copies, some process (or maybe the mythical "system" process
>whose worknig set includes the file system cache) is running into the
>IoPageLockLimit, or the limit on how much pool can be allocated. Or
>there just aren't any more physical pages available for locking for
>doing direct IO.
>