NO_MORE_STACK_LOCATIONS on Win2K3 AD

NTFSD
1

I can’t figure this one out.
I’ve setup Win2K3 Ent. server with Active Directory.
Now, I have installed 4 of my filters on that machine. On reboot,
the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
| IRP_SYNCHRONOUS_API.
If I remove ANY of the filters, the bug check does not occur.
Any ideas?

At first I thought there’s a path where I am handling
IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
doesn’t seem to be the case.
The error happens during “Preparing Network Connections” dialog, so
I cannot go as far as logging in and checking how devices are setup in
the stack. There are no other drivers except mine on the system,
however.

–
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.

2

Where did the IRP originate? I ask because it is possible you’ve found some
new OS component that has used its own IRP pool with fixed size stack
location IRPs. We’ve seen it in older versions, there’s no reason that we
might not see it again.

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Friday, May 16, 2003 5:05 PM
To: File Systems Developers
Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD

I can’t figure this one out.
I’ve setup Win2K3 Ent. server with Active Directory.
Now, I have installed 4 of my filters on that machine. On reboot,
the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
| IRP_SYNCHRONOUS_API.
If I remove ANY of the filters, the bug check does not occur.
Any ideas?

At first I thought there’s a path where I am handling
IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
doesn’t seem to be the case.
The error happens during “Preparing Network Connections” dialog, so
I cannot go as far as logging in and checking how devices are setup in
the stack. There are no other drivers except mine on the system,
however.

–
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.

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

3

It’s not LanmanServer (I tried increasing IRPStackSize for it).
The IRP memory is already f***ed up when I do irp on it in SoftICE, so I
cannot tell anything from that.

Deja.

Tony Mason wrote:

Where did the IRP originate? I ask because it is possible you’ve found some
new OS component that has used its own IRP pool with fixed size stack location
IRPs. We’ve seen it in older versions, there’s no reason that we might not
see it again.

–
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.

4

After some debugging, I got the IRP info.
The primary device is Root (should that tell anything:-) of type
FILE_DEVICE_DFS
Could I be facing a race condition while attaching? (I recall some
requirement about synchronizing while doing IoAttachDeviceToDeviceStack, which
IoAttachDeviceToDeviceStackSafe fixed, but I have NT compatible driver, so it
uses the first one)

Regards, Dejan.

Tony Mason wrote:

Where did the IRP originate? I ask because it is possible you’ve found some
new OS component that has used its own IRP pool with fixed size stack location
IRPs. We’ve seen it in older versions, there’s no reason that we might not
see it again.

–
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.

5

I don’t think that the IoAttachDeviceToDeviceStack would cause this
problem. The IoAttachDeviceToDeviceStack problem is that your filter
device may receive an IRP before you update your lower device object
pointer in your filter’s device extension, thus causing a crash when
your filter tries to pass down the IRP. If you need to be NT compatible,
you can continue using IoAttachDeviceToDeviceStack but you need to check
for a null lower device object pointer in your passdown routine.

At the time of the crash, you may try walking the filesystem stack
that’s crashing by hand and verifying that each driver’s StackSize is
one less than the stack size of its attached device.

You can also assert on the sanity of pIrp->StackCount when passing down
an IRP.

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Friday, May 16, 2003 3:38 PM
To: File Systems Developers
Subject: [ntfsd] RE: NO_MORE_STACK_LOCATIONS on Win2K3 AD

After some debugging, I got the IRP info.
The primary device is Root (should that tell anything:-)
of type FILE_DEVICE_DFS
Could I be facing a race condition while attaching? (I
recall some requirement about synchronizing while doing
IoAttachDeviceToDeviceStack, which
IoAttachDeviceToDeviceStackSafe fixed, but I have NT
compatible driver, so it uses the first one)

Regards, Dejan.

Tony Mason wrote:

> Where did the IRP originate? I ask because it is possible you’ve
> found some new OS component that has used its own IRP pool
with fixed
> size stack location IRPs. We’ve seen it in older versions,
there’s no
> reason that we might not see it again.

–
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.

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

6

Yeah, I thought so - no NULL device.
This is definitely a fixed stack count issue - and I will have to check
Irp->CurrentLocation to be != 1.
I wonder why any component would use fixed size StackCount, and have it
SO low. I’ve seven filters all together, and a few more coming:-)

Nick Ryan wrote:

I don’t think that the IoAttachDeviceToDeviceStack would cause this
problem. The IoAttachDeviceToDeviceStack problem is that your filter
device may receive an IRP before you update your lower device object
pointer in your filter’s device extension, thus causing a crash when
your filter tries to pass down the IRP. If you need to be NT compatible,
you can continue using IoAttachDeviceToDeviceStack but you need to check
for a null lower device object pointer in your passdown routine.

At the time of the crash, you may try walking the filesystem stack
that’s crashing by hand and verifying that each driver’s StackSize is
one less than the stack size of its attached device.

You can also assert on the sanity of pIrp->StackCount when passing down
an IRP.

  • Nick Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
> Sent: Friday, May 16, 2003 3:38 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: NO_MORE_STACK_LOCATIONS on Win2K3 AD
>
>
>
> After some debugging, I got the IRP info.
> The primary device is Root (should that tell anything:-)
> of type FILE_DEVICE_DFS
> Could I be facing a race condition while attaching? (I
> recall some requirement about synchronizing while doing
> IoAttachDeviceToDeviceStack, which
> IoAttachDeviceToDeviceStackSafe fixed, but I have NT
> compatible driver, so it uses the first one)
>
> Regards, Dejan.
>
> Tony Mason wrote:
>
> > Where did the IRP originate? I ask because it is possible you’ve
> > found some new OS component that has used its own IRP pool
> with fixed
> > size stack location IRPs. We’ve seen it in older versions,
> there’s no
> > reason that we might not see it again.
>
> –
> 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.
>
>
>
>
> —
> 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@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

7

Dejan,

I don´t know if it will help you, but…

I was get the same problem with two of my drivers. I was using a file system
filter driver and a disk filter driver. If I removed some one the bug check
don´t occour.

The problem occour with I was deleting a device that has another device
attached to it. In my case, it was occoured with removeable devices (CDROM,
FLOPPY, ETC).

Heldai

----- Original Message -----
From: “Dejan Maksimovic”
To: “File Systems Developers”
Sent: Friday, May 16, 2003 6:05 PM
Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD

>
> I can’t figure this one out.
> I’ve setup Win2K3 Ent. server with Active Directory.
> Now, I have installed 4 of my filters on that machine. On reboot,
> the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> | IRP_SYNCHRONOUS_API.
> If I remove ANY of the filters, the bug check does not occur.
> Any ideas?
>
> At first I thought there’s a path where I am handling
> IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> doesn’t seem to be the case.
> The error happens during “Preparing Network Connections” dialog, so
> I cannot go as far as logging in and checking how devices are setup in
> the stack. There are no other drivers except mine on the system,
> however.
>
> –
> 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.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

8

Yes, having only 3 (but I need six to run together) drivers eliminates the
problem - but that’s not helpful, as I need customers to run at least 3 drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a fixed
IRPSTackSize?

Heldai wrote:

Dejan,

I don´t know if it will help you, but…

I was get the same problem with two of my drivers. I was using a file system
filter driver and a disk filter driver. If I removed some one the bug check
don´t occour.

The problem occour with I was deleting a device that has another device
attached to it. In my case, it was occoured with removeable devices (CDROM,
FLOPPY, ETC).

Heldai

----- Original Message -----
From: “Dejan Maksimovic”
> To: “File Systems Developers”
> Sent: Friday, May 16, 2003 6:05 PM
> Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
>
> >
> > I can’t figure this one out.
> > I’ve setup Win2K3 Ent. server with Active Directory.
> > Now, I have installed 4 of my filters on that machine. On reboot,
> > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> > 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> > | IRP_SYNCHRONOUS_API.
> > If I remove ANY of the filters, the bug check does not occur.
> > Any ideas?
> >
> > At first I thought there’s a path where I am handling
> > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > doesn’t seem to be the case.
> > The error happens during “Preparing Network Connections” dialog, so
> > I cannot go as far as logging in and checking how devices are setup in
> > the stack. There are no other drivers except mine on the system,
> > however.
> >
> > –
> > 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.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

9

Actually, I do not. However, the crash should give you the information
necessary - like the tag on the memory for that IRP and the completion
routine in the first stack location; these would normally indicate who
allocated the IRP in the first place, since they are probably going to want
it back.

If they are allocating it from the I/O Manager, the bug is more subtle (they
are asking for the wrong number of stack locations) but it should show up
(again) in the IRP or in the call stack.

If you want to send the dump along, I’ll analyze it and write it up (and
post it on the portal site and/or the NT Insider, of course.) If this is a
bona fide W2K3 bug, we need to identify it and report it to MS ASAP so we
can get the fix into SP1!

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 17, 2003 8:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

Yes, having only 3 (but I need six to run together) drivers eliminates
the
problem - but that’s not helpful, as I need customers to run at least 3
drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a
fixed
IRPSTackSize?

Heldai wrote:

Dejan,

I don?t know if it will help you, but…

I was get the same problem with two of my drivers. I was using a file
system
filter driver and a disk filter driver. If I removed some one the bug
check
don?t occour.

The problem occour with I was deleting a device that has another device
attached to it. In my case, it was occoured with removeable devices
(CDROM,
FLOPPY, ETC).

Heldai

----- Original Message -----
From: “Dejan Maksimovic”
> To: “File Systems Developers”
> Sent: Friday, May 16, 2003 6:05 PM
> Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
>
> >
> > I can’t figure this one out.
> > I’ve setup Win2K3 Ent. server with Active Directory.
> > Now, I have installed 4 of my filters on that machine. On reboot,
> > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> > 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> > | IRP_SYNCHRONOUS_API.
> > If I remove ANY of the filters, the bug check does not occur.
> > Any ideas?
> >
> > At first I thought there’s a path where I am handling
> > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > doesn’t seem to be the case.
> > The error happens during “Preparing Network Connections” dialog, so
> > I cannot go as far as logging in and checking how devices are setup in
> > the stack. There are no other drivers except mine on the system,
> > however.
> >
> > –
> > 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.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

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

10

I’ll make four PassThrough drivers, and see if it reproduces it - that will
tell if it’s a fixed stack size issue or something else.
I can mail the dump on the CD, but I can’t upload it:-)

Tony Mason wrote:

Actually, I do not. However, the crash should give you the information
necessary - like the tag on the memory for that IRP and the completion
routine in the first stack location; these would normally indicate who
allocated the IRP in the first place, since they are probably going to want
it back.

If they are allocating it from the I/O Manager, the bug is more subtle (they
are asking for the wrong number of stack locations) but it should show up
(again) in the IRP or in the call stack.

If you want to send the dump along, I’ll analyze it and write it up (and
post it on the portal site and/or the NT Insider, of course.) If this is a
bona fide W2K3 bug, we need to identify it and report it to MS ASAP so we
can get the fix into SP1!

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 17, 2003 8:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

Yes, having only 3 (but I need six to run together) drivers eliminates
the
problem - but that’s not helpful, as I need customers to run at least 3
drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a
fixed
IRPSTackSize?

Heldai wrote:

> Dejan,
>
> I don´t know if it will help you, but…
>
> I was get the same problem with two of my drivers. I was using a file
system
> filter driver and a disk filter driver. If I removed some one the bug
check
> don´t occour.
>
> The problem occour with I was deleting a device that has another device
> attached to it. In my case, it was occoured with removeable devices
(CDROM,
> FLOPPY, ETC).
>
> Heldai
>
> ----- Original Message -----
> From: “Dejan Maksimovic”
> > To: “File Systems Developers”
> > Sent: Friday, May 16, 2003 6:05 PM
> > Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
> >
> > >
> > > I can’t figure this one out.
> > > I’ve setup Win2K3 Ent. server with Active Directory.
> > > Now, I have installed 4 of my filters on that machine. On reboot,
> > > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > > LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> > > 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> > > | IRP_SYNCHRONOUS_API.
> > > If I remove ANY of the filters, the bug check does not occur.
> > > Any ideas?
> > >
> > > At first I thought there’s a path where I am handling
> > > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > > doesn’t seem to be the case.
> > > The error happens during “Preparing Network Connections” dialog, so
> > > I cannot go as far as logging in and checking how devices are setup in
> > > the stack. There are no other drivers except mine on the system,
> > > however.
> > >
> > > –
> > > 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.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> 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.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

11

SoftICE shows the top of the stack to be Mup!_DnrResolveName, BTW (after
retrieving symbols for MUP)

Tony Mason wrote:

Actually, I do not. However, the crash should give you the information
necessary - like the tag on the memory for that IRP and the completion
routine in the first stack location; these would normally indicate who
allocated the IRP in the first place, since they are probably going to want
it back.

If they are allocating it from the I/O Manager, the bug is more subtle (they
are asking for the wrong number of stack locations) but it should show up
(again) in the IRP or in the call stack.

If you want to send the dump along, I’ll analyze it and write it up (and
post it on the portal site and/or the NT Insider, of course.) If this is a
bona fide W2K3 bug, we need to identify it and report it to MS ASAP so we
can get the fix into SP1!

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 17, 2003 8:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

Yes, having only 3 (but I need six to run together) drivers eliminates
the
problem - but that’s not helpful, as I need customers to run at least 3
drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a
fixed
IRPSTackSize?

Heldai wrote:

> Dejan,
>
> I don´t know if it will help you, but…
>
> I was get the same problem with two of my drivers. I was using a file
system
> filter driver and a disk filter driver. If I removed some one the bug
check
> don´t occour.
>
> The problem occour with I was deleting a device that has another device
> attached to it. In my case, it was occoured with removeable devices
(CDROM,
> FLOPPY, ETC).
>
> Heldai
>
> ----- Original Message -----
> From: “Dejan Maksimovic”
> > To: “File Systems Developers”
> > Sent: Friday, May 16, 2003 6:05 PM
> > Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
> >
> > >
> > > I can’t figure this one out.
> > > I’ve setup Win2K3 Ent. server with Active Directory.
> > > Now, I have installed 4 of my filters on that machine. On reboot,
> > > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > > LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> > > 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> > > | IRP_SYNCHRONOUS_API.
> > > If I remove ANY of the filters, the bug check does not occur.
> > > Any ideas?
> > >
> > > At first I thought there’s a path where I am handling
> > > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > > doesn’t seem to be the case.
> > > The error happens during “Preparing Network Connections” dialog, so
> > > I cannot go as far as logging in and checking how devices are setup in
> > > the stack. There are no other drivers except mine on the system,
> > > however.
> > >
> > > –
> > > 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.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> 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.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

12

Another interesting point: Irp->PendingReturned is TRUE before my
drivers are called!
DFSDriver is attached on top of my drivers for NTFS, but not for MUP
driver, so there is nothing above my drivers.
DeviceTree shows my drivers to be set up as follows, for MUP:
MUP->AFPANsi->AFPUni->AFM->ATEAnsi
AFPAnsi, AFPUni and ATEAnsi, during IRP_MJ_CREATE, set a completion
routine which returns copies the Irp->IoStatus.Status to my variable,
does KeSetEvent on provided EVENT and returns STATUS_SUCCESS, wait on
the event, and logs the file name if the call was successful (other than
STATUS_REPARSE).
AFM’s completion returns STATUS_MORE_PROCESSING_REQUIRED, and dispatch
calls IoCompleteRequest.
If I’m missing something, it’s strange it did not come up sooner:-)

What is worrying is that if AFM has a passthrough IRP_MJ_CREATE
handler, the bug check does NOT occur.

Regards, Dejan.

Tony Mason wrote:

Actually, I do not. However, the crash should give you the information
necessary - like the tag on the memory for that IRP and the completion
routine in the first stack location; these would normally indicate who
allocated the IRP in the first place, since they are probably going to want
it back.

If they are allocating it from the I/O Manager, the bug is more subtle (they
are asking for the wrong number of stack locations) but it should show up
(again) in the IRP or in the call stack.

If you want to send the dump along, I’ll analyze it and write it up (and
post it on the portal site and/or the NT Insider, of course.) If this is a
bona fide W2K3 bug, we need to identify it and report it to MS ASAP so we
can get the fix into SP1!

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 17, 2003 8:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

Yes, having only 3 (but I need six to run together) drivers eliminates
the
problem - but that’s not helpful, as I need customers to run at least 3
drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a
fixed
IRPSTackSize?

Heldai wrote:

> Dejan,
>
> I don´t know if it will help you, but…
>
> I was get the same problem with two of my drivers. I was using a file
system
> filter driver and a disk filter driver. If I removed some one the bug
check
> don´t occour.
>
> The problem occour with I was deleting a device that has another device
> attached to it. In my case, it was occoured with removeable devices
(CDROM,
> FLOPPY, ETC).
>
> Heldai
>
> ----- Original Message -----
> From: “Dejan Maksimovic”
> > To: “File Systems Developers”
> > Sent: Friday, May 16, 2003 6:05 PM
> > Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
> >
> > >
> > > I can’t figure this one out.
> > > I’ve setup Win2K3 Ent. server with Active Directory.
> > > Now, I have installed 4 of my filters on that machine. On reboot,
> > > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > > LanManRedirector). I see that the Irp->StackCount for the faulty IRP is
> > > 5, and that the flags are IRP_CREATE_OPERATION | IRP_DEFER_IO_COMPLETION
> > > | IRP_SYNCHRONOUS_API.
> > > If I remove ANY of the filters, the bug check does not occur.
> > > Any ideas?
> > >
> > > At first I thought there’s a path where I am handling
> > > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > > doesn’t seem to be the case.
> > > The error happens during “Preparing Network Connections” dialog, so
> > > I cannot go as far as logging in and checking how devices are setup in
> > > the stack. There are no other drivers except mine on the system,
> > > however.
> > >
> > > –
> > > 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.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> 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.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

13

MUP does do name resolution; I wouldn’t have imagined it used fixed size
stack locations, but that’s certainly a possibility. I’ll see if I can dig
anything up on this; hopefully the MS folks might be able to shed some
additional light here as well…

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Sunday, May 18, 2003 10:05 AM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

SoftICE shows the top of the stack to be Mup!_DnrResolveName, BTW (after
retrieving symbols for MUP)

Tony Mason wrote:

Actually, I do not. However, the crash should give you the information
necessary - like the tag on the memory for that IRP and the completion
routine in the first stack location; these would normally indicate who
allocated the IRP in the first place, since they are probably going to
want
it back.

If they are allocating it from the I/O Manager, the bug is more subtle
(they
are asking for the wrong number of stack locations) but it should show up
(again) in the IRP or in the call stack.

If you want to send the dump along, I’ll analyze it and write it up (and
post it on the portal site and/or the NT Insider, of course.) If this is
a
bona fide W2K3 bug, we need to identify it and report it to MS ASAP so we
can get the fix into SP1!

Regards,

Tony

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

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 17, 2003 8:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

Yes, having only 3 (but I need six to run together) drivers eliminates
the
problem - but that’s not helpful, as I need customers to run at least 3
drivers
with an AV scanner, and possibly some other filter.

Tony, do you have a clue which device, other than LanmanServer, has a
fixed
IRPSTackSize?

Heldai wrote:

> Dejan,
>
> I don?t know if it will help you, but…
>
> I was get the same problem with two of my drivers. I was using a file
system
> filter driver and a disk filter driver. If I removed some one the bug
check
> don?t occour.
>
> The problem occour with I was deleting a device that has another device
> attached to it. In my case, it was occoured with removeable devices
(CDROM,
> FLOPPY, ETC).
>
> Heldai
>
> ----- Original Message -----
> From: “Dejan Maksimovic”
> > To: “File Systems Developers”
> > Sent: Friday, May 16, 2003 6:05 PM
> > Subject: [ntfsd] NO_MORE_STACK_LOCATIONS on Win2K3 AD
> >
> > >
> > > I can’t figure this one out.
> > > I’ve setup Win2K3 Ent. server with Active Directory.
> > > Now, I have installed 4 of my filters on that machine. On reboot,
> > > the machine gives me a IRP_NO_MORE_STACK_LOCATIONS (0x35) bug check,
> > > when accessing \Domain\SysVol directory in IRP_MJ_CREATE (filtering
> > > LanManRedirector). I see that the Irp->StackCount for the faulty IRP
is
> > > 5, and that the flags are IRP_CREATE_OPERATION |
IRP_DEFER_IO_COMPLETION
> > > | IRP_SYNCHRONOUS_API.
> > > If I remove ANY of the filters, the bug check does not occur.
> > > Any ideas?
> > >
> > > At first I thought there’s a path where I am handling
> > > IoCompleteRequest/STATUS_MORE_PROCESSING_REQUIRED incorrectly. That
> > > doesn’t seem to be the case.
> > > The error happens during “Preparing Network Connections” dialog,
so
> > > I cannot go as far as logging in and checking how devices are setup in
> > > the stack. There are no other drivers except mine on the system,
> > > however.
> > >
> > > –
> > > 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.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@terra.com.br
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> 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.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
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.

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

14

As I said, it seemed to be fixed size (because when the system does not bug
check I see that the number of stack locations is VERY low, on the last driver
(2)).
The weird part is that making one of the drivers in the chain a pass-through
driver, the problem does not occur:-(

Regards, Dejan.

Tony Mason wrote:

MUP does do name resolution; I wouldn’t have imagined it used fixed size stack
locations, but that’s certainly a possibility. I’ll see if I can dig anything
up on this; hopefully the MS folks might be able to shed some additional light
here as well…

–
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.

15

I installed another driver, so there were 5 drivers attached to
LanmanRedirector - and no problem. Removed the new one and back came the bug
check.
Removing just a specific one (AFM), with 4 remaining, results in NO bug
check. So, I do have a bug in there somewhere… Or, I’m not aware of some OS
component’s behavior.

Tony Mason wrote:

MUP does do name resolution; I wouldn’t have imagined it used fixed size stack
locations, but that’s certainly a possibility. I’ll see if I can dig anything
up on this; hopefully the MS folks might be able to shed some additional light
here as well…

–
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.

16

In your various dispatch routines, put a debug print of the stack
information from the IRP. Include total stack allocations and the
current stack location index. Do this for every place you can get an
IRP that you will forward onward somewhere. You could also add a
display where you forward the IRP and make sure you haven’t bumped the
next stack location somehow. There is also a possibility that some
forwarding of the IRP might have caused it to come back in thru your
driver again, so display the IRP’s address each time including in any
completion routines.

----- Original Message -----
From: “Dejan Maksimovic”
To: “File Systems Developers”
Sent: Sunday, May 18, 2003 4:59 PM
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

>
> I installed another driver, so there were 5 drivers attached to
> LanmanRedirector - and no problem. Removed the new one and back came
the bug
> check.
> Removing just a specific one (AFM), with 4 remaining, results in
NO bug
> check. So, I do have a bug in there somewhere… Or, I’m not aware of
some OS
> component’s behavior.
>
> Tony Mason wrote:
>
> > MUP does do name resolution; I wouldn’t have imagined it used fixed
size stack
> > locations, but that’s certainly a possibility. I’ll see if I can
dig anything
> > up on this; hopefully the MS folks might be able to shed some
additional light
> > here as well…
>
> –
> 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.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

17

David,


Why does it always take a second go and someone telling you to do
things right:-) (tried that with no success)

Now, I dumped a little more:
And it seems I found the problem.
An IRP, which seems to be reused, is sent to my top driver with
Irp->CurrentLocation set to 4, instead of 5, as two previous times (5 is
the right StackCount!). The IRP is sent by MUP as I mentioned. Now, how I
resolve why I am sent an IRP with a Irp->CurrentLocation which is one less
than what it should be? (My completion show that Irp->CurrentLocation was
restored to 5 when the IRP was used last times)

Regards, Dejan.

“David J. Craig” wrote:

In your various dispatch routines, put a debug print of the stack
information from the IRP. Include total stack allocations and the
current stack location index. Do this for every place you can get an
IRP that you will forward onward somewhere. You could also add a
display where you forward the IRP and make sure you haven’t bumped the
next stack location somehow. There is also a possibility that some
forwarding of the IRP might have caused it to come back in thru your
driver again, so display the IRP’s address each time including in any
completion routines.

–
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.

18

To add here:

  • 3 FS filters on the stack work OK
  • 5 FS filters work OK
  • 4 FS filters bug check!
    and unlike my previous thinking, it does NOT matter which of the
    drivers are on the stack.

Deja.

Dejan Maksimovic wrote:

David,


> Why does it always take a second go and someone telling you to do
> things right:-) (tried that with no success)
>
Now, I dumped a little more:
And it seems I found the problem.
An IRP, which seems to be reused, is sent to my top driver with
Irp->CurrentLocation set to 4, instead of 5, as two previous times (5 is
the right StackCount!). The IRP is sent by MUP as I mentioned. Now, how I
resolve why I am sent an IRP with a Irp->CurrentLocation which is one less
than what it should be? (My completion show that Irp->CurrentLocation was
restored to 5 when the IRP was used last times)

Regards, Dejan.

–
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.

19

Hi David,

I am just wondering How the following can happen??

-Ramaraj

“There is also a possibility that some
forwarding of the IRP might have caused it to come back in thru your
driver again, so display the IRP’s address each time including in any
completion routines.”

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David J. Craig
Sent: Sunday, May 18, 2003 2:28 PM
To: File Systems Developers
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

In your various dispatch routines, put a debug print of the stack
information from the IRP. Include total stack allocations and the
current stack location index. Do this for every place you can get an
IRP that you will forward onward somewhere. You could also add a
display where you forward the IRP and make sure you haven’t bumped the
next stack location somehow. There is also a possibility that some
forwarding of the IRP might have caused it to come back in thru your
driver again, so display the IRP’s address each time including in any
completion routines.

----- Original Message -----
From: “Dejan Maksimovic”
To: “File Systems Developers”
Sent: Sunday, May 18, 2003 4:59 PM
Subject: [ntfsd] Re: NO_MORE_STACK_LOCATIONS on Win2K3 AD

>
> I installed another driver, so there were 5 drivers attached to
> LanmanRedirector - and no problem. Removed the new one and back came
the bug
> check.
> Removing just a specific one (AFM), with 4 remaining, results in
NO bug
> check. So, I do have a bug in there somewhere… Or, I’m not aware of
some OS
> component’s behavior.
>
> Tony Mason wrote:
>
> > MUP does do name resolution; I wouldn’t have imagined it used fixed
size stack
> > locations, but that’s certainly a possibility. I’ll see if I can
dig anything
> > up on this; hopefully the MS folks might be able to shed some
additional light
> > here as well…
>
> –
> 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.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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