Of course, you are right as usual Jamey. I believe I suggested other
approaches and merely pointed out that IoGetBaseFileSystemDeviceObject()
doesn’t have an equivalent on W2K and earlier. Unfortunately, for those
of us who don’t get to always use the latest API’s because we’re
supporting NT4 and W2K, it doesn’t do us much good.
The first rule should be those that we have pointed out here and, bottom
line, watch stack usage.
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, December 14, 2001 1:44 PM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
Surly this is a very odd idea unless you know exactly what you are
doing. Do not send requests directly to the FSD at the bottom.
A couple of points:
-
Spend plenty of time reviewing your code and get everything off the
stack you can. Use ExAllocatePool() is you must.
-
Review FASTFAT source in IFSKIT. It uses a mechanism to determine
stack space. It checks the threshold and if there is insufficent stack
space, the request is posted off to an FSP (thread in a known process is
a better description than FSP).
-
Only call the base FSD directly if you know what you are doing; unless
you are adding or extending functionality of a very specific nature to
an existing FSD that you are intimate with. For example, EFS is tightly
bound to NTFS and it is possible that this driver could use this
technique; but I doubt it.
-
Using this method of calling the FSD directly will bypass
functionality in many filter drivers; mine included. Please do not do
this. You can not assume that you are the top dog (or bottom).
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar
Pudipeddi
Sent: Friday, December 21, 2001 9:57 AM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
Are you suggesting that in NT 4 & Win 2K filters should directly send
the IRP to the base filesystem so as to counter stack overflow
situations?
This is very unacceptable. Bypassing filters below you can have very
indeterminate effects.
Posting to a different thread is the best option available for
create/close in NT 4 & Win2K. Read/Write’s can be handrolled & sent down
to the next lower driver.
Thanks,
Ravi
–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use
-----Original Message-----
From: Kelley, Jerry [mailto:xxxxx@nsisoftware.com]
Sent: Friday, December 21, 2001 6:30 AM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
To clarify a point, you pass in a PFILE_OBJECT to
IoGetBaseFileSystemDeviceObject() and it’ll give you back the VDO for
the file system.
-----Original Message-----
From: Kelley, Jerry
Sent: Friday, December 21, 2001 8:42 AM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
Note that IoCreateFileSpecifyDeviceObjectHint() is not available in W2K
or NT4. For W2K and NT4, here’s a hint: look at
IoGetBaseFileSystemDeviceObject() which is defined in NTIFS.H. It’ll get
you the file system’s DO. You’ll need to roll your own IRP and catch it
on the way back up.
The stack overflow situation is familiar to me as well. The general rule
about conserving stack space should be adhered to or else you’re going
to see this as soon as you get another filter or two in the stack. If
you have a lot of variables or need a fair amount of space in a routine,
consider lookaside lists that the routines can use instead of automatic
variables.
You can get stack space estimates as you’re called and take some actions
(at least in debugging) to find out when the stack is getting low.
-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, December 20, 2001 3:07 PM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
Please be very conservative with stack space. I’d even say, take a
defensive approach to this problem. It’s very easy to blow the stack
with 2 filters on x86. I see this happen too often nowadays …
If you HAVE to issue a re-entrant operation - such as a ZwCreateFile
(and on XP you shouldn’t, you should be using
IoCreateFileSpecifyDeviceObjectHint()), please make sure that you have
enough stack space before issuing this. You can use
IoGetRemainingStackSize() to check how much stack is left.
If not, consider giving this operation a fresh stack by posting it to a
worker thread.
Please don’t put MAX_PATH buffers on the stack. Allocate them. Check for
allocation failures.
Please don’t try to put file path-names in a buffer that’s only MAX_PATH
long. Regardless of whether MAX_PATH is your own define or not.
A refresh of these rules seemed timely, though I know most of you are
aware of them (or found out the hard way :-)), already.
Thanks,
Ravi
–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use
-----Original Message-----
From: Ronen Agam [mailto:xxxxx@hotmail.com]
Sent: Thursday, December 20, 2001 11:37 AM
To: File Systems Developers
Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
The _MAX_PATH is my own define of 260 bytes. After all give me some
credit
that I know what I am doing. My point was also that we sometimes call
other
functions which consumes stack space, and thus shuold over look those
functions gets called from the dispatch func.
Ronen
From: Dejan Maksimovic
>Reply-To: “File Systems Developers”
>To: “File Systems Developers”
>Subject: [ntfsd] Re: Interference with Norton AntiVirus 2002
>Date: Thu, 20 Dec 2001 16:51:51 +0100
>
> > I know its hard to beleive that our driver is the cause for the
> > problem.
>I
> > thought the same.
>
> Well, from the points below, it wouldn’t be hard to believe:-)
>
> > I removed my fiter driver and scan the machine - it worked fine. I
> > put
>it
> > back and crash after norton was scanning 3/4 of the files. It didn’t
> > happened every time but 70% of the times. In my dispatch routine all
> > data I was using on the stack, such as the
>buffer
> > that holds the file name (_MAX_PATH) and other routine I was calling
>from my
> > dispatch routine I allocated those local variables from the heap.
> > That solved my problem. If it doesn’t, then try to contact NAV, who
> > knows
>what
> > are they doing there. Buy the way on NT 4.0 I never saw the problem,
> > it
>only
> > happens on 2000.
>
> Just a few notes:
> - This doesn’t mean the stack is the problem. NT has a smaller
>stack space!
> - MAX_PATH is not enough to hold many paths on Server
environments,
>which
>can easily go over 260 characters. It would be wise to do extra
checking
>for
>file name size before using the buffer and overflowing it potentially,
or
>to
>dynamically allocate the buffer after checking how big it needs to be.
>
>–
>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@hotmail.com To
>unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
—
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@nsisoftware.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
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@storagecraft.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@nsisoftware.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
