Interop problem w/ NAV (Symantec Antivirus)...

NTFSD
1

We have a product that includes a file system filter driver. If we
install Symantec Antivirus Corporate Edition (v. 8.00.374) and enable
Driver Verifier tests for both our file system filter driver and for the
four drivers that ship with NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither a thread
stack nor a DPC stack.
(Typically, the driver doing this should be on the stack obtained by the
KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else aware of
this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not, are there any
legit techniques that should be used as alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically the writer(s)
of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

2

Do you have deadlock detection enabled? It used to be that case that
having this enabled would cause a crash on startup if NAV is also
installed, regardless of whether you are verifying the NAV drivers or
not.

There was a threads a few months back about the technique of
stack-swapping in filesystem filter drives. I’m pretty sure the
technique discussed was allocating your own memory and fudging ESP and
various other obscure variables to bypass the kernel thread stack
limitation. I do remember one of the Microsoft guys saying that this was
a very unreliable technique and that lots of companies had fallen flat
on their face trying to implement it correctly :).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver.
If we install Symantec Antivirus Corporate Edition (v.
8.00.374) and enable Driver Verifier tests for both our file
system filter driver and for the four drivers that ship with
NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither
a thread stack nor a DPC stack.
(Typically, the driver doing this should be on the stack
obtained by the KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else
aware of this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not,
are there any legit techniques that should be used as
alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically
the writer(s) of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

3

No, deadlock detection was not enabled. The enabled tests were:

-Special Pool
-Force IRQL Checking
-Pool Tracking
-I/O Verification
-Low Resource Simulation

So perhaps if Symantec implemented their stack switching correctly I can
consider this Verifier-induced bug check as being more a warning than an
actual error. Would you agree?

Nate

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Monday, April 14, 2003 2:49 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Do you have deadlock detection enabled? It used to be that case that
having this enabled would cause a crash on startup if NAV is also
installed, regardless of whether you are verifying the NAV drivers or
not.

There was a threads a few months back about the technique of
stack-swapping in filesystem filter drives. I’m pretty sure the
technique discussed was allocating your own memory and fudging ESP and
various other obscure variables to bypass the kernel thread stack
limitation. I do remember one of the Microsoft guys saying that this was
a very unreliable technique and that lots of companies had fallen flat
on their face trying to implement it correctly :).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver.
If we install Symantec Antivirus Corporate Edition (v.
8.00.374) and enable Driver Verifier tests for both our file
system filter driver and for the four drivers that ship with
NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither
a thread stack nor a DPC stack.
(Typically, the driver doing this should be on the stack
obtained by the KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else
aware of this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not,
are there any legit techniques that should be used as
alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically
the writer(s) of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

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

4

Heh. Perhaps Microsoft has now officialy ‘deprecated’ this behavior.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 2:13 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

No, deadlock detection was not enabled. The enabled tests were:

-Special Pool
-Force IRQL Checking
-Pool Tracking
-I/O Verification
-Low Resource Simulation

So perhaps if Symantec implemented their stack switching
correctly I can consider this Verifier-induced bug check as
being more a warning than an actual error. Would you agree?

Nate

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Monday, April 14, 2003 2:49 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Do you have deadlock detection enabled? It used to be that
case that having this enabled would cause a crash on startup
if NAV is also installed, regardless of whether you are
verifying the NAV drivers or not.

There was a threads a few months back about the technique of
stack-swapping in filesystem filter drives. I’m pretty sure
the technique discussed was allocating your own memory and
fudging ESP and various other obscure variables to bypass the
kernel thread stack limitation. I do remember one of the
Microsoft guys saying that this was a very unreliable
technique and that lots of companies had fallen flat on their
face trying to implement it correctly :).

  • Nicholas Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
> Sent: Monday, April 14, 2003 1:27 PM
> To: File Systems Developers
> Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…
>
>
> We have a product that includes a file system filter driver.
> If we install Symantec Antivirus Corporate Edition (v.
> 8.00.374) and enable Driver Verifier tests for both our file
> system filter driver and for the four drivers that ship with
> NAV, we end up with the following blue
> screen:
>
>
> *** Fatal System Error: 0x000000c4
> (0x00000090,0xFFDFF120,0x00000000,0x00000000)
>
> Break instruction exception - code 80000003 (first chance)
> Probably caused by : NAVAP.sys ( NAVAP+696d )
>
>
> This docs for this bug check are a bit slim on details. They say:
>
> The driver switched stacks, and the current stack is neither
> a thread stack nor a DPC stack.
> (Typically, the driver doing this should be on the stack
> obtained by the KB debugger command.)
>
> I’ve been told that NAV does switch stacks. Is anyone else
> aware of this?
>
> What exactly is stack switching?
>
> What problem(s) does stack switching cause?
>
> Are there legitimate reasons for stack switching? If not,
> are there any legit techniques that should be used as
> alternatives to stack switching?
>
> Finally, do any of the NAV driver developers, specifically
> the writer(s) of NAVAP.sys, participate on this list?
>
> Thanks,
>
> Nate Bushman
> PowerQuest Corp
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

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

5

The error should occur for I/O verification tests - I do recall NAV not
passing deadlock detection, but that seems to be another issue.
In either case, I do agree that Nate can ignore this error - as it’s not
his fault.

Heh. Perhaps Microsoft has now officialy ‘deprecated’ this behavior.

  • Nicholas Ryan

> No, deadlock detection was not enabled. The enabled tests were:

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

6

The alternative is to use your stack space sparingly and to not recurse
back into the top of the FSD; like NAV and most AV programs do.

I remember the days of stack switching; DOS wasn’t it?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver. If we
install Symantec Antivirus Corporate Edition (v. 8.00.374) and enable
Driver Verifier tests for both our file system filter driver and for the
four drivers that ship with NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither a thread
stack nor a DPC stack.
(Typically, the driver doing this should be on the stack obtained by the
KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else aware of
this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not, are there any
legit techniques that should be used as alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically the writer(s)
of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

7

Nope. Stack switching is bad, so you can assume the entire driver is bad
:slight_smile:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 2:13 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

No, deadlock detection was not enabled. The enabled tests were:

-Special Pool
-Force IRQL Checking
-Pool Tracking
-I/O Verification
-Low Resource Simulation

So perhaps if Symantec implemented their stack switching correctly I can
consider this Verifier-induced bug check as being more a warning than an
actual error. Would you agree?

Nate

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Monday, April 14, 2003 2:49 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Do you have deadlock detection enabled? It used to be that case that
having this enabled would cause a crash on startup if NAV is also
installed, regardless of whether you are verifying the NAV drivers or
not.

There was a threads a few months back about the technique of
stack-swapping in filesystem filter drives. I’m pretty sure the
technique discussed was allocating your own memory and fudging ESP and
various other obscure variables to bypass the kernel thread stack
limitation. I do remember one of the Microsoft guys saying that this was
a very unreliable technique and that lots of companies had fallen flat
on their face trying to implement it correctly :).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver.
If we install Symantec Antivirus Corporate Edition (v.
8.00.374) and enable Driver Verifier tests for both our file
system filter driver and for the four drivers that ship with
NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither
a thread stack nor a DPC stack.
(Typically, the driver doing this should be on the stack
obtained by the KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else
aware of this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not,
are there any legit techniques that should be used as
alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically
the writer(s) of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

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

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

8

Thanks Jamey. When you say “recurse back into the top of the FSD” are
you talking about the file system filter driver sending new I/O to the
very devices that it filters? I hadn’t considered that, and it really
could cause the stack to grow out of control. Messy.

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, April 15, 2003 10:31 AM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

The alternative is to use your stack space sparingly and to not recurse
back into the top of the FSD; like NAV and most AV programs do.

I remember the days of stack switching; DOS wasn’t it?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver. If we
install Symantec Antivirus Corporate Edition (v. 8.00.374) and enable
Driver Verifier tests for both our file system filter driver and for the
four drivers that ship with NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither a thread
stack nor a DPC stack.
(Typically, the driver doing this should be on the stack obtained by the
KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else aware of
this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not, are there any
legit techniques that should be used as alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically the writer(s)
of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

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

9

Most AV scanners halt the request, flag it and send a message to a
service that will also open the file. Their filters know how to detect
this recursion, most of the time, and act accordingly.

This is OK if you use no stack :slight_smile: However, what about other filters? It
is a little messy.

We have a driver that does this technique, but we were very careful in
our stack usage.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Tuesday, April 15, 2003 9:53 AM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Thanks Jamey. When you say “recurse back into the top of the FSD” are
you talking about the file system filter driver sending new I/O to the
very devices that it filters? I hadn’t considered that, and it really
could cause the stack to grow out of control. Messy.

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, April 15, 2003 10:31 AM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

The alternative is to use your stack space sparingly and to not recurse
back into the top of the FSD; like NAV and most AV programs do.

I remember the days of stack switching; DOS wasn’t it?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver. If we
install Symantec Antivirus Corporate Edition (v. 8.00.374) and enable
Driver Verifier tests for both our file system filter driver and for the
four drivers that ship with NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither a thread
stack nor a DPC stack.
(Typically, the driver doing this should be on the stack obtained by the
KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else aware of
this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not, are there any
legit techniques that should be used as alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically the writer(s)
of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

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

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

10

Also, what happens if you have a __try __except block and the trap
occurs on the way back up from a driver who has swapped stacks?

I suspect the driver below would also have to implement a __try __except
and make sure the stack was swapped back before allowing the exceptions
to propagate back up; this __try block would have to wrap all dispatch
and fastio entry points to be 100% sure the stack was swapped back.

This sounds like a hornets nest to me.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Tuesday, April 15, 2003 9:53 AM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Thanks Jamey. When you say “recurse back into the top of the FSD” are
you talking about the file system filter driver sending new I/O to the
very devices that it filters? I hadn’t considered that, and it really
could cause the stack to grow out of control. Messy.

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, April 15, 2003 10:31 AM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

The alternative is to use your stack space sparingly and to not recurse
back into the top of the FSD; like NAV and most AV programs do.

I remember the days of stack switching; DOS wasn’t it?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, April 14, 2003 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Interop problem w/ NAV (Symantec Antivirus)…

We have a product that includes a file system filter driver. If we
install Symantec Antivirus Corporate Edition (v. 8.00.374) and enable
Driver Verifier tests for both our file system filter driver and for the
four drivers that ship with NAV, we end up with the following blue
screen:

*** Fatal System Error: 0x000000c4
(0x00000090,0xFFDFF120,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)
Probably caused by : NAVAP.sys ( NAVAP+696d )

This docs for this bug check are a bit slim on details. They say:

The driver switched stacks, and the current stack is neither a thread
stack nor a DPC stack.
(Typically, the driver doing this should be on the stack obtained by the
KB debugger command.)

I’ve been told that NAV does switch stacks. Is anyone else aware of
this?

What exactly is stack switching?

What problem(s) does stack switching cause?

Are there legitimate reasons for stack switching? If not, are there any
legit techniques that should be used as alternatives to stack switching?

Finally, do any of the NAV driver developers, specifically the writer(s)
of NAVAP.sys, participate on this list?

Thanks,

Nate Bushman
PowerQuest Corp

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

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

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

11

> There was a threads a few months back about the technique of

stack-swapping in filesystem filter drives. I’m pretty sure the
technique discussed was allocating your own memory and fudging ESP
and

Amazing. Why not use ExQueueWorkItem instead? It will do effectively
the same, but with lesser headache.

Max

12

Lots of book-keeping involved, sychronization and serialization issues.
I’m not advocating fudging ESP, just saying that correctly using work
items requires, well, a lot of work. Microsoft should make improving the
kernel-mode stack situation a priority for future versions of Windows
(moving passive-level functionality from kernel-mode to user-mode would
be the best approach IMHO).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Tuesday, April 15, 2003 1:48 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

> There was a threads a few months back about the technique of
> stack-swapping in filesystem filter drives. I’m pretty sure the
> technique discussed was allocating your own memory and fudging ESP
and

Amazing. Why not use ExQueueWorkItem instead? It will do
effectively the same, but with lesser headache.

Max

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

13

I don’t think anybody should depend upon us doing anything to the kernel
stack for x86 necessarily.
Kernel stack is 12K and it’s a precious resource. We’re looking at core
components and making improvements there
to cut down stack usage, but the problem with increasing the stack size
affects scalability that will not be solved with more
RAM alone. The address space is the true limitation.

The new filter model will mitigate the issue a bit, since re-entrancy
will be considerably reduced, as well as getting rid of
the daisy chaining model of passing an IRP down.

However meanwhile - judicious use of stack, judicious use of work items
will help. Remove deep calls, reduce locals.
In particularly stack intensive paths - such as paging i/o paths for
instance, consider trimming down your locals. We are all
in this together, do your bit.

Stack switching as outlined below is NOT a good idea, as Max has pointed
out.Yes, exceptions are an issue, APC delivery is an issue,
I can go on here… Even if you hack it up right - you would need to be
very careful what you do on the switched stack, and that is
typically more difficult than making local improvements like I outlined
above.
Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Tuesday, April 15, 2003 8:44 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Lots of book-keeping involved, sychronization and serialization issues.
I’m not advocating fudging ESP, just saying that correctly using work
items requires, well, a lot of work. Microsoft should make improving the
kernel-mode stack situation a priority for future versions of Windows
(moving passive-level functionality from kernel-mode to user-mode would
be the best approach IMHO).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Tuesday, April 15, 2003 1:48 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

> There was a threads a few months back about the technique of
> stack-swapping in filesystem filter drives. I’m pretty sure the
> technique discussed was allocating your own memory and fudging ESP
and

Amazing. Why not use ExQueueWorkItem instead? It will do
effectively the same, but with lesser headache.

Max

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

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

14

I contend that workitems are easier than swapping stacks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Tuesday, April 15, 2003 8:44 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

Lots of book-keeping involved, sychronization and serialization issues.
I’m not advocating fudging ESP, just saying that correctly using work
items requires, well, a lot of work. Microsoft should make improving the
kernel-mode stack situation a priority for future versions of Windows
(moving passive-level functionality from kernel-mode to user-mode would
be the best approach IMHO).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Tuesday, April 15, 2003 1:48 PM
To: File Systems Developers
Subject: [ntfsd] RE: Interop problem w/ NAV (Symantec Antivirus)…

> There was a threads a few months back about the technique of
> stack-swapping in filesystem filter drives. I’m pretty sure the
> technique discussed was allocating your own memory and fudging ESP
and

Amazing. Why not use ExQueueWorkItem instead? It will do
effectively the same, but with lesser headache.

Max

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

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