NO_MORE_IRP_STACK

Ismo Bergroth

unread,

Mar 22, 1996, 3:00:00 AM3/22/96

to

I am developing a filter driver that looks at file i/o. Everything works like
a charm on a stand-alone computer.
However, when the driver is running on machine A, I access a file on A from
machine B, A bluescreens with the message NO_MORE_IRP_STACK_LOCATIONS. What is
causing this behaviour? Shouldn't file access look the same regardless of what
machine is accessing the file? Any suggestions what might be going wrong?

I was also wondering, when I have trapped an event and gotten the fileobject,
how can I determine who is opening it? Is there any way to tell if the opener
is on the local machine or coming over the network?

Any help or ideas greatly appreciated.

Ismo Bergroth

Son VoBa

unread,

Mar 22, 1996, 3:00:00 AM3/22/96

to

One of the higher level drivers called your driver through the
IoCallDriver() interface, but there are no more stack locations
in the packet, hence, your driver would not be able to access its
parameters, as there are no parameters for it. The calling higher
level driver thinks it has filled in the parameters for your
driver but since there is no stack location for your driver, the
higher level driver went off the end of the packet.

Bottom line, memory being trashed by someone (perhaps by your
driver 8^).

------------------------------------------------------------------
Son VoBa (206) 865-8758
Digital Equipment Corporation FAX (206) 865-8890
Computer Systems Division 14475 NE 24th Street
Windows NT Business Segment Bellevue, Washington 98007-3739
DECwest Engineering U.S.A.
------------------------------------------------------------------

Walter Dixon

unread,

Mar 23, 1996, 3:00:00 AM3/23/96

to

Ismo Bergroth wrote:
>
> I am developing a filter driver that looks at file i/o. Everything works like
> a charm on a stand-alone computer.
> However, when the driver is running on machine A, I access a file on A from
> machine B, A bluescreens with the message NO_MORE_IRP_STACK_LOCATIONS. What is
> causing this behaviour? Shouldn't file access look the same regardless of what
> machine is accessing the file? Any suggestions what might be going wrong?

> ...
> Ismo Bergroth

A given IRP can access a predetermined number of stack locations. Whether
these locations are physically in the IRP is not important. As requests
trickle down to lower level drivers, different stack locations are used.
If you run out of stack locations without reaching the lowest level driver,
NT is not happy.

How does your filter driver attach itself? Do you use
IoGetDeviceObjectPointer or IoAttachDevice? Are you allocating IRPs
yourself?

Tony Mason

unread,

Mar 27, 1996, 3:00:00 AM3/27/96

to

Typically, I've seen this problem when a filter driver is called from
SRV. This indicates one of two problems:

(1) you've exceeded the number of IRP stack locations SRV allocates (4
by default). You can fix this in the Registry - the key is documented
in the resource kit (I never recall from the top of my head.)

(2) You've copied the contents of one stack location to the next stack
location (RtlMoveMemory/RtlCopyMemory.) In this case it is likely you
aren't setting the completion routine properly and it is copied
inadvertently. You MUST set the IoCompletion routine - even if just to
zero - if you copy one stack location to the next.

--
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
VOICE: (603) 595-6500 FAX: (603) 595-6503
ma...@osr.com

OSR is a consulting firm specializing in training,
design, and development of systems software for Windows NT. Our 1996 public training schedule is now available (training for: kernel mode drivers, NDIS drivers, and file systems drivers.) Call for information.