The problem concerns completion routines primarily. If the higher-level
caller specified a completion routine, then
*PtrNextIoStackLocation = *PtrCurrentIoStackLocation
Will copy it to the next location as well as the current location. When the
IRP is completed, the higher-level completion routine would be called twice.
There are three cases where using the simple stack location copy (above)
wouldn’t cause a problem:
1.) The higher-level driver didn’t specify a completion routine. In this
case, since there isn’t a higher level completion it wouldn’t be called once
or twice. No problem.
2.) If you use the simple copy (above) and then use IoSetCompletionRoutine
you’ll be OK. Although the simple copy (above) did duplicate the callers
completion in the nest stack location, your call to IoSetCompletionRoutine
over wrote it. You’ll be OK.
3.) The higher level driver doesn’t mind having it’s completion routine
called twice.
I suspect that FileMon is seeing case one. You might check. No higher-level
completion routine, no problem. (Will a highest-level filter driver ever see
a completion routine passed to it? Don’t think so… If FileMon was lower
down in a filter chain the situation would be more dicey)
As for Rajeev’s current location test. If the higher level drivers always
allocate the correct number of stack locations before calling you, you will
never encounter it.
I can say for a fact that in some types of filter drivers I do see Rajeev’s
current location test hit. I believe that Rajeev’s book describes some of
the situations. Tony’s book probably addresses this issue as well.
(However neither mention how to deal with it when you do encounter it…).
My strong advice is to use IoCopyCurrentIrpStackLocationToNext on W2k and to
clone it and use it on NT as well.
Then move on to real problems.
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:
----- Original Message -----
From: Ho Mun Chuen
To: File Systems Developers
Sent: Tuesday, May 09, 2000 9:42 PM
Subject: [ntfsd] RE: No more stack locations
> i see. so what’s wrong with using
>
> *PtrNextIoStackLocation = *PtrCurrentIoStackLocation?
>
> i noticed that Filemon uses that and it has no problem.
>
> Filemon also did not check if
>
> PtrIrp->CurrentLocation == 1
>
> like what Nagar did and it also works…
>
> comments, please…
>
> Ho Mun Chuen
> @@ “Not everything that counts can be counted;
> <” )~ and not everything that can be counted counts"
> //\ … Albert Einstein
> ----- Original Message -----
> From: COX,DAVID (HP-Roseville,ex1) <david_cox2>
> To: File Systems Developers
> Sent: Wednesday, May 10, 2000 12:31 AM
> Subject: [ntfsd] RE: No more stack locations
>
>
> Because it is not correct to copy the entire stack location. You don’t
> want to copy the completion routine, else it could get called twice.
>
> -----------------------------------------------------------------------
> Dave Cox
> Hewlett-Packard Co.
> HPSO/SSMO (Santa Barbara)
> https://ecardfile.com/id/Dave+Cox
>
>
> -----Original Message-----
> From: Ho Mun Chuen [mailto:xxxxx@pmail.ntu.edu.sg]
> Sent: Monday, May 08, 2000 7:22 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: No more stack locations
>
>
> thanks!
>
> but why is FIELD_OFFSET used instead of sizeof(IO_STACK_LOCATION)?
>
> Ho Mun Chuen
> Advanced Technology Solutions Centre
> CSO Development Laboratory
> (Office) 3732426 (Pager) 93253507
> @@ “Not everything that counts can be counted;
> <” )~ and not everything that can be counted counts"
> //\ … Albert Einstein
> ----- Original Message -----
> From: Jamey Kirby
> To: File Systems Developers
> Sent: Monday, May 08, 2000 5:50 PM
> Subject: [ntfsd] RE: No more stack locations
>
>
> // Copy the current IRP stack location to the next IRP stack location.
> #ifndef IoCopyCurrentIrpStackLocationToNext
> #define IoCopyCurrentIrpStackLocationToNext(Irp)
> <br>>
> <br>> PIO_STACK_LOCATION irpSp;
> <br>> PIO_STACK_LOCATION ne
> xtIrpSp;
> <br>> irpSp = IoGetCurrentIrpStackLocation((Irp));
> <br>> nextIrpSp = IoGetNextIrpStackLocation((Irp));
> <br>> RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
> CompletionRoutine)); <br>> nextIrpSp->Control = 0;
> <br>> }
> #endif
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Ho Mun Chuen
> > Sent: Monday, May 08, 2000 12:42 AM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: No more stack locations
> >
> >
> > how do i copy correctly in nt 4? currently i just use
> >
> > *PtrNextIoStackLocation = *PtrCurrentIoStackLocation;
> >
> > however, the problem seems to be solved if i follow Nagar’s code in his
> > filter driver example where the driver will check if
> >
> > PtrIrp->CurrentLocation == 1
> >
> > and return STATUS_INVALID_DEVICE_REQUEST… although i did
> > encounter system
> > hang once… but no NO_MORE_STACK_LOCATION exception…
> >
> > but how did the stack locations ended up to be only one?
> >
> > Ho Mun Chuen
> > @@ “Not everything that counts can be counted;
> > <” )~ and not everything that can be counted counts"
> > //\ … Albert Eins
> tein
> > ----- Original Message -----
> > From: Tony Mason
> > To: File Systems Developers
> > Sent: Friday, May 05, 2000 9:50 PM
> > Subject: [ntfsd] RE: No more stack locations
> >
> >
> > The most common cause of this problem is that you copy the stack
location
> > incorrectly. If you are using Windows 2000, you should use
> > IoCopyCurrentIrpStackLocationToNext. If you are using NT 4.0, you can
> > either (a) copy the stack location and make sure you set (or clear) the
> > competion routine using IoSetCompletionRoutine; or (b) since
> > IoCopyCurrentIrpStackLocationToNext is a macro, just use the same logic
as
> > the Windows 2000 macro.
> >
> > This is not the only possible cause, but it is the most likely.
> >
> > Regards,
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> > -----Original Message-----
> > From: Ho Mun Chuen [mailto:xxxxx@pmail.ntu.edu.sg]
> > Sent: Thursday, May 04, 2000 9:36 PM
> > To: File Systems Developers
> > Subject: [ntfsd] No more stack locations
> >
> >
> > i am writing a filter driver to attach to ntfs, fat and rdr. i can
> > successfuly attach to them on my test machine. with the driver running
on
> > this machine, i map a dir on this machine from my development machine
that
> > is w/o the driver. most of the time, i can display the contents
> > in this dir
> > with the development machine’s explorer. however, i will get the “no
more
> > stack locations” exception on the test machine if there is a lot
> > of files in
> > the dir to be listed. i will also sometimes get this exception if i am
> > trying to open a substantially large file on this dir…
> >
> > can anyone enlighten me?
> >
> > Ho Mun Chuen
> > @@ “Not everything that counts can be counted;
> > <” )~ and not everything that can be counted counts"
> > //\ … Albert Einstein
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> ></david_cox2></http:>