Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


No more stack locations

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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:[email protected]]
    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: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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 Einstein
    ----- Original Message -----
    From: Tony Mason <[email protected]>
    To: File Systems Developers <[email protected]>
    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:[email protected]]
    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: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    // Copy the current IRP stack location to the next IRP stack location.
    #ifndef IoCopyCurrentIrpStackLocationToNext
    #define IoCopyCurrentIrpStackLocationToNext(Irp)
    {
    PIO_STACK_LOCATION irpSp;
    PIO_STACK_LOCATION nextIrpSp;
    irpSp = IoGetCurrentIrpStackLocation((Irp));
    nextIrpSp = IoGetNextIrpStackLocation((Irp));
    RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); nextIrpSp->Control = 0;
    }
    #endif


    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]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 Einstein
    > ----- Original Message -----
    > From: Tony Mason <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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:[email protected]]
    > 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: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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 <[email protected]>
    To: File Systems Developers <[email protected]>
    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)
    \
    {
    \
    PIO_STACK_LOCATION irpSp;
    \
    PIO_STACK_LOCATION nextIrpSp;
    \
    irpSp = IoGetCurrentIrpStackLocation((Irp));
    \
    nextIrpSp = IoGetNextIrpStackLocation((Irp));
    \
    RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); \
    nextIrpSp->Control = 0;
    \
    }
    #endif


    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]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 <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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:[email protected]]
    > 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: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_User-35OSR_Community_User-35 Member Posts: 154
    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:[email protected]]
    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 <[email protected]>
    To: File Systems Developers <[email protected]>
    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)
    \
    {
    \
    PIO_STACK_LOCATION irpSp;
    \
    PIO_STACK_LOCATION nextIrpSp;
    \
    irpSp = IoGetCurrentIrpStackLocation((Irp));
    \
    nextIrpSp = IoGetNextIrpStackLocation((Irp));
    \
    RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); \
    nextIrpSp->Control = 0;
    \
    }
    #endif


    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]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 <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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:[email protected]]
    > 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: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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) <[email protected]>
    To: File Systems Developers <[email protected]>
    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:[email protected]]
    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 <[email protected]>
    To: File Systems Developers <[email protected]>
    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)
    \
    {
    \
    PIO_STACK_LOCATION irpSp;
    \
    PIO_STACK_LOCATION ne
    xtIrpSp;
    \
    irpSp = IoGetCurrentIrpStackLocation((Irp));
    \
    nextIrpSp = IoGetNextIrpStackLocation((Irp));
    \
    RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); \
    nextIrpSp->Control = 0;
    \
    }
    #endif


    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]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 <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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:[email protected]]
    > 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: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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://www.pcausa.com&gt;



    ----- Original Message -----
    From: Ho Mun Chuen <[email protected]>
    To: File Systems Developers <[email protected]>
    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) <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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:[email protected]]
    > 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 <[email protected]>
    > To: File Systems Developers <[email protected]>
    > 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)
    > \
    >

    > \
    > PIO_STACK_LOCATION irpSp;
    > \
    > PIO_STACK_LOCATION ne
    > xtIrpSp;
    > \
    > irpSp = IoGetCurrentIrpStackLocation((Irp));
    > \
    > nextIrpSp = IoGetNextIrpStackLocation((Irp));
    > \
    > RtlCopyMemory(nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    > CompletionRoutine)); \
    > nextIrpSp->Control = 0;
    > \
    > }
    > #endif
    >
    >
    > > -----Original Message-----
    > > From: [email protected]
    > > [mailto:[email protected]]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 <[email protected]>
    > > To: File Systems Developers <[email protected]>
    > > 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:[email protected]]
    > > 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: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
    > > ---
    > > You are currently subscribed to ntfsd as: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > i see. so what's wrong with using
    >
    > *PtrNextIoStackLocation = *PtrCurrentIoStackLocation?

    It's OK if you will set the completion routine in the next stack location to
    NULL.
    But without it the completion routine will be copied - and will be called
    twice,
    thus leading to a crash.

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    thanks, Thomas. now i have a clearer picture. i always thought the
    completion routine is set in the current io stack location, so it is not.

    by using the macro for w2k, i do not seem to encounter the exception
    already. thanks to Jamey for supplying the macro.

    also thanks Max for replying.

    Ho Mun Chuen
    @@ "Not everything that counts can be counted;
    <" )~ and not everything that can be counted counts"
    /\/\ ..... Albert Einstein
    ----- Original Message -----
    From: Thomas F. Divine <[email protected]>
    To: File Systems Developers <[email protected]>
    Sent: Wednesday, May 10, 2000 1:59 PM
    Subject: [ntfsd] RE: No more stack locations


    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://www.pcausa.com&gt;
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Well, now I think that either I am wrong, or that you still have an unclear
    picture.

    Completion routine IS set in current stack location for each driver. If you
    just copy the next stack location, the Completion routine is also copied.
    The I/O manager calls the Completion routines for each of the stack
    locations. Now since the CompletionRoutine was also copied (actually the
    pointer), two stack locations have the pointer to same routine, and it will
    get called twice.

    Take a look at the definition of _IO_STACK_LOCATION. It has the pointer to
    completion routine (and followed by the context that is passed to the
    completion routine).

    To avoid this routine being called twice, either

    1. Copy the stack location, *and then* set a completion routine.
    2. Copy the stack location, *and then* clear the completion routine, if you
    do not want your own completion routine.
    3. Use the macro to do the same.

    NB: In step 2, you need to set the completion routine to NULL, or it will
    get called twice as it was copied. Essentially same as step 1, but the idea
    is different.

    Shweta.

    thanks, Thomas. now i have a clearer picture. i always thought the
    completion routine is set in the current io stack location, so it is not.

    by using the macro for w2k, i do not seem to encounter the exception
    already. thanks to Jamey for supplying the macro.

    also thanks Max for replying.

    Ho Mun Chuen
    @@ "Not everything that counts can be counted;
    <" )~ and not everything that can be counted counts"
    /\/\ ..... Albert Einstein
    ----- Original Message -----
    From: Thomas F. Divine <[email protected]>
    To: File Systems Developers <[email protected]>
    Sent: Wednesday, May 10, 2000 1:59 PM
    Subject: [ntfsd] RE: No more stack locations


    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://www.pcausa.com&gt;




    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ______________________________________________
    FREE Personalized Email at Mail.com
    Sign up at http://www.mail.com/?sr=signup
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    It is not needed to clear IrpSp->CompletionRoutine and/or IrpSp->Context.
    It should be better to clear IrpSp->Control field, because this bitmask can
    contain
    these values:

    #define SL_PENDING_RETURNED 0x01
    #define SL_INVOKE_ON_CANCEL 0x20
    #define SL_INVOKE_ON_SUCCESS 0x40
    #define SL_INVOKE_ON_ERROR 0x80

    Last three are associated with completion routine.
    If none of them is set then IoCompleteRequest calls no completion routine
    (even if its pointer is valid).

    The macro IoCopyCurrentIrpStackLocationToNext does in turn the
    same functionality. It first copies all fields from begin of IrpSp to
    CompletionRoutine. Ie. all fields except CompletionRoutine and
    Context are copied. Then to be clear it must zero the Control field
    and this ensures no completion routine will be called for this location.

    #define IoCopyCurrentIrpStackLocationToNext( Irp ) { \
    PIO_STACK_LOCATION irpSp; \
    PIO_STACK_LOCATION nextIrpSp; \
    irpSp = IoGetCurrentIrpStackLocation( (Irp) ); \
    nextIrpSp = IoGetNextIrpStackLocation( (Irp) ); \
    RtlCopyMemory( nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); \
    nextIrpSp->Control = 0; }

    One other thing is:
    IoSetCompletionRoutine will set the completion routine and context
    (plus bitmask to Control - SL_INVOKE_ON_XXX) not to the current stack
    location but to the next one. When the IoCompleteReqest calls the
    completion routine it passes to it three things: Irp, DeviceObject and
    Context.
    Irp is evident, Context is taken from the next stack location (from the
    perspective of the routine called) and DeviceObject is taken from current
    stack location.

    This means if the higher level driver builds an Irp and want to request the
    IoManager
    to call his completion routine there are two cases to do this:
    1. Reserve no stack location for itself -
    in this case the DeviceObject argument to compeltion routine will be
    NULL,
    because there is no current stack location for the creator. But his
    routine
    will be called because informations on this are stored in the next stack
    location - ie. in stack location for his next lower level driver.
    2. Reserve one stack location for itself -
    the caller must set the device object in his stack location to
    valid value, then set the next stack location as active. All other
    is common.

    Paul

    > -----P?vodn? zpr?va-----
    > Od: Shweta Dubey [SMTP:[email protected]]
    > Odesl?no: 11. kv?tna 2000 16:46
    > Komu: File Systems Developers
    > Kopie: [email protected]
    > P?edm?t: [ntfsd] RE: No more stack locations
    >
    > Well, now I think that either I am wrong, or that you still have an
    > unclear
    > picture.
    >
    > Completion routine IS set in current stack location for each driver. If
    > you
    > just copy the next stack location, the Completion routine is also copied.
    > The I/O manager calls the Completion routines for each of the stack
    > locations. Now since the CompletionRoutine was also copied (actually the
    > pointer), two stack locations have the pointer to same routine, and it
    > will
    > get called twice.
    >
    > Take a look at the definition of _IO_STACK_LOCATION. It has the pointer to
    > completion routine (and followed by the context that is passed to the
    > completion routine).
    >
    > To avoid this routine being called twice, either
    >
    > 1. Copy the stack location, *and then* set a completion routine.
    > 2. Copy the stack location, *and then* clear the completion routine, if
    > you
    > do not want your own completion routine.
    > 3. Use the macro to do the same.
    >
    > NB: In step 2, you need to set the completion routine to NULL, or it will
    > get called twice as it was copied. Essentially same as step 1, but the
    > idea
    > is different.
    >
    > Shweta.
    >
    > thanks, Thomas. now i have a clearer picture. i always thought the
    > completion routine is set in the current io stack location, so it is not.
    >
    > by using the macro for w2k, i do not seem to encounter the exception
    > already. thanks to Jamey for supplying the macro.
    >
    > also thanks Max for replying.
    >
    > Ho Mun Chuen
    > @@ "Not everything that counts can be counted;
    > <" )~ and not everything that can be counted counts"
    > /\/\ ..... Albert Einstein
    > ----- Original Message -----
    > From: Thomas F. Divine <[email protected]>
    > To: File Systems Developers <[email protected]>
    > Sent: Wednesday, May 10, 2000 1:59 PM
    > Subject: [ntfsd] RE: No more stack locations
    >
    >
    > 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://www.pcausa.com&gt;
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ______________________________________________
    > FREE Personalized Email at Mail.com
    > Sign up at http://www.mail.com/?sr=signup
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I have forgotten to say one other thing:
    In my opinion there is the best thing you can do to add two
    macros to the NT 4.0 NTIFS and/or NTDDK.
    These macros are IoCopyCurrentIrpStackLocationToNext and
    IoSkipCurrentIrpStackLocation.
    I have done this and there are no problems - it works fine.

    Paul

    > -----P?vodn? zpr?va-----
    > Od: Shweta Dubey [SMTP:[email protected]]
    > Odesl?no: 11. kv?tna 2000 16:46
    > Komu: File Systems Developers
    > Kopie: [email protected]
    > P?edm?t: [ntfsd] RE: No more stack locations
    >
    > Well, now I think that either I am wrong, or that you still have an
    > unclear
    > picture.
    >
    > Completion routine IS set in current stack location for each driver. If
    > you
    > just copy the next stack location, the Completion routine is also copied.
    > The I/O manager calls the Completion routines for each of the stack
    > locations. Now since the CompletionRoutine was also copied (actually the
    > pointer), two stack locations have the pointer to same routine, and it
    > will
    > get called twice.
    >
    > Take a look at the definition of _IO_STACK_LOCATION. It has the pointer to
    > completion routine (and followed by the context that is passed to the
    > completion routine).
    >
    > To avoid this routine being called twice, either
    >
    > 1. Copy the stack location, *and then* set a completion routine.
    > 2. Copy the stack location, *and then* clear the completion routine, if
    > you
    > do not want your own completion routine.
    > 3. Use the macro to do the same.
    >
    > NB: In step 2, you need to set the completion routine to NULL, or it will
    > get called twice as it was copied. Essentially same as step 1, but the
    > idea
    > is different.
    >
    > Shweta.
    >
    > thanks, Thomas. now i have a clearer picture. i always thought the
    > completion routine is set in the current io stack location, so it is not.
    >
    > by using the macro for w2k, i do not seem to encounter the exception
    > already. thanks to Jamey for supplying the macro.
    >
    > also thanks Max for replying.
    >
    > Ho Mun Chuen
    > @@ "Not everything that counts can be counted;
    > <" )~ and not everything that can be counted counts"
    > /\/\ ..... Albert Einstein
    > ----- Original Message -----
    > From: Thomas F. Divine <[email protected]>
    > To: File Systems Developers <[email protected]>
    > Sent: Wednesday, May 10, 2000 1:59 PM
    > Subject: [ntfsd] RE: No more stack locations
    >
    >
    > 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://www.pcausa.com&gt;
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ______________________________________________
    > FREE Personalized Email at Mail.com
    > Sign up at http://www.mail.com/?sr=signup
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I have forgotten to say one other thing:
    In my opinion there is the best thing you can do to add two
    macros to the NT 4.0 NTIFS and/or NTDDK.
    These macros are IoCopyCurrentIrpStackLocationToNext and
    IoSkipCurrentIrpStackLocation.
    I have done this and there are no problems - it works fine.

    Paul

    > -----P?vodn? zpr?va-----
    > Od: Shweta Dubey [SMTP:[email protected]]
    > Odesl?no: 11. kv?tna 2000 16:46
    > Komu: File Systems Developers
    > Kopie: [email protected]
    > P?edm?t: [ntfsd] RE: No more stack locations
    >
    > Well, now I think that either I am wrong, or that you still have an
    > unclear
    > picture.
    >
    > Completion routine IS set in current stack location for each driver. If
    > you
    > just copy the next stack location, the Completion routine is also copied.
    > The I/O manager calls the Completion routines for each of the stack
    > locations. Now since the CompletionRoutine was also copied (actually the
    > pointer), two stack locations have the pointer to same routine, and it
    > will
    > get called twice.
    >
    > Take a look at the definition of _IO_STACK_LOCATION. It has the pointer to
    > completion routine (and followed by the context that is passed to the
    > completion routine).
    >
    > To avoid this routine being called twice, either
    >
    > 1. Copy the stack location, *and then* set a completion routine.
    > 2. Copy the stack location, *and then* clear the completion routine, if
    > you
    > do not want your own completion routine.
    > 3. Use the macro to do the same.
    >
    > NB: In step 2, you need to set the completion routine to NULL, or it will
    > get called twice as it was copied. Essentially same as step 1, but the
    > idea
    > is different.
    >
    > Shweta.
    >
    > thanks, Thomas. now i have a clearer picture. i always thought the
    > completion routine is set in the current io stack location, so it is not.
    >
    > by using the macro for w2k, i do not seem to encounter the exception
    > already. thanks to Jamey for supplying the macro.
    >
    > also thanks Max for replying.
    >
    > Ho Mun Chuen
    > @@ "Not everything that counts can be counted;
    > <" )~ and not everything that can be counted counts"
    > /\/\ ..... Albert Einstein
    > ----- Original Message -----
    > From: Thomas F. Divine <[email protected]>
    > To: File Systems Developers <[email protected]>
    > Sent: Wednesday, May 10, 2000 1:59 PM
    > Subject: [ntfsd] RE: No more stack locations
    >
    >
    > 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://www.pcausa.com&gt;
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ______________________________________________
    > FREE Personalized Email at Mail.com
    > Sign up at http://www.mail.com/?sr=signup
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    It is not needed to clear IrpSp->CompletionRoutine and/or IrpSp->Context.
    It should be better to clear IrpSp->Control field, because this bitmask can
    contain
    these values:

    #define SL_PENDING_RETURNED 0x01
    #define SL_INVOKE_ON_CANCEL 0x20
    #define SL_INVOKE_ON_SUCCESS 0x40
    #define SL_INVOKE_ON_ERROR 0x80

    Last three are associated with completion routine.
    If none of them is set then IoCompleteRequest calls no completion routine
    (even if its pointer is valid).

    The macro IoCopyCurrentIrpStackLocationToNext does in turn the
    same functionality. It first copies all fields from begin of IrpSp to
    CompletionRoutine. Ie. all fields except CompletionRoutine and
    Context are copied. Then to be clear it must zero the Control field
    and this ensures no completion routine will be called for this location.

    #define IoCopyCurrentIrpStackLocationToNext( Irp ) { \
    PIO_STACK_LOCATION irpSp; \
    PIO_STACK_LOCATION nextIrpSp; \
    irpSp = IoGetCurrentIrpStackLocation( (Irp) ); \
    nextIrpSp = IoGetNextIrpStackLocation( (Irp) ); \
    RtlCopyMemory( nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
    CompletionRoutine)); \
    nextIrpSp->Control = 0; }

    One other thing is:
    IoSetCompletionRoutine will set the completion routine and context
    (plus bitmask to Control - SL_INVOKE_ON_XXX) not to the current stack
    location but to the next one. When the IoCompleteReqest calls the
    completion routine it passes to it three things: Irp, DeviceObject and
    Context.
    Irp is evident, Context is taken from the next stack location (from the
    perspective of the routine called) and DeviceObject is taken from current
    stack location.

    This means if the higher level driver builds an Irp and want to request the
    IoManager
    to call his completion routine there are two cases to do this:
    1. Reserve no stack location for itself -
    in this case the DeviceObject argument to compeltion routine will be
    NULL,
    because there is no current stack location for the creator. But his
    routine
    will be called because informations on this are stored in the next stack
    location - ie. in stack location for his next lower level driver.
    2. Reserve one stack location for itself -
    the caller must set the device object in his stack location to
    valid value, then set the next stack location as active. All other
    is common.

    Paul

    > -----P?vodn? zpr?va-----
    > Od: Shweta Dubey [SMTP:[email protected]]
    > Odesl?no: 11. kv?tna 2000 16:46
    > Komu: File Systems Developers
    > Kopie: [email protected]
    > P?edm?t: [ntfsd] RE: No more stack locations
    >
    > Well, now I think that either I am wrong, or that you still have an
    > unclear
    > picture.
    >
    > Completion routine IS set in current stack location for each driver. If
    > you
    > just copy the next stack location, the Completion routine is also copied.
    > The I/O manager calls the Completion routines for each of the stack
    > locations. Now since the CompletionRoutine was also copied (actually the
    > pointer), two stack locations have the pointer to same routine, and it
    > will
    > get called twice.
    >
    > Take a look at the definition of _IO_STACK_LOCATION. It has the pointer to
    > completion routine (and followed by the context that is passed to the
    > completion routine).
    >
    > To avoid this routine being called twice, either
    >
    > 1. Copy the stack location, *and then* set a completion routine.
    > 2. Copy the stack location, *and then* clear the completion routine, if
    > you
    > do not want your own completion routine.
    > 3. Use the macro to do the same.
    >
    > NB: In step 2, you need to set the completion routine to NULL, or it will
    > get called twice as it was copied. Essentially same as step 1, but the
    > idea
    > is different.
    >
    > Shweta.
    >
    > thanks, Thomas. now i have a clearer picture. i always thought the
    > completion routine is set in the current io stack location, so it is not.
    >
    > by using the macro for w2k, i do not seem to encounter the exception
    > already. thanks to Jamey for supplying the macro.
    >
    > also thanks Max for replying.
    >
    > Ho Mun Chuen
    > @@ "Not everything that counts can be counted;
    > <" )~ and not everything that can be counted counts"
    > /\/\ ..... Albert Einstein
    > ----- Original Message -----
    > From: Thomas F. Divine <[email protected]>
    > To: File Systems Developers <[email protected]>
    > Sent: Wednesday, May 10, 2000 1:59 PM
    > Subject: [ntfsd] RE: No more stack locations
    >
    >
    > 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://www.pcausa.com&gt;
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ______________________________________________
    > FREE Personalized Email at Mail.com
    > Sign up at http://www.mail.com/?sr=signup
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE