FSCTL_GET_RETRIEVAL_POINTERS

I am interested in getting the extent maps for a particular file in my
filter driver on NT 4.0
We tried using the NtFsControlFile() call but it returns a status of
STATUS_INVALID_USER_BUFFER.

However when i issued the same call from a User mode application it worked
fine. What could be the problem here ?

Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
function in my driver expecting to intercept the NtFsControlFile() call. But
it did not hit the breakpoint…Is my filter driver getting bypassed for this
call ?

Thanks,
RB.

This is a “well known problem”, where the FSD is checking to see if the
buffer address is valid - and the implementation of this assumes it must be
coming from user mode.

The “work around” is to use a user mode buffer. This is fixed in Windows
2000.

Regards,

Tony

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

-----Original Message-----
From: RB [mailto:xxxxx@softhome.net]
Sent: Monday, October 02, 2000 10:23 AM
To: File Systems Developers
Subject: [ntfsd] FSCTL_GET_RETRIEVAL_POINTERS

I am interested in getting the extent maps for a particular file in my
filter driver on NT 4.0
We tried using the NtFsControlFile() call but it returns a status of
STATUS_INVALID_USER_BUFFER.

However when i issued the same call from a User mode application it worked
fine. What could be the problem here ?

Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
function in my driver expecting to intercept the NtFsControlFile() call. But
it did not hit the breakpoint…Is my filter driver getting bypassed for this
call ?

Thanks,
RB.


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

i need some more help on this. I tried having a custom IOCTL code in my
driver which will be called from an app passing in the OutPut Buffer. Then
in the driver i allocate an IRP with the IoControlCode field to be
FSCTL_GET_RETRIEVAL_POINTERS and the Irp->UserBuffer set to the OutPut
buffer passed by the app. This Irp i pass to the Filesystem. The return
status i found was still
STATUS_INVALID_USER_BUFFER.

Is this a feasible way of providing a user mode buffer ? I would greatly
appreciate more help…

Thanks and regds
RB.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
Sent: Monday, October 02, 2000 9:23 PM
To: File Systems Developers
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

This is a “well known problem”, where the FSD is checking to see if the
buffer address is valid - and the implementation of this assumes it must be
coming from user mode.

The “work around” is to use a user mode buffer. This is fixed in Windows
2000.

Regards,

Tony

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

-----Original Message-----
From: RB [mailto:xxxxx@softhome.net]
Sent: Monday, October 02, 2000 10:23 AM
To: File Systems Developers
Subject: [ntfsd] FSCTL_GET_RETRIEVAL_POINTERS

I am interested in getting the extent maps for a particular file in my
filter driver on NT 4.0
We tried using the NtFsControlFile() call but it returns a status of
STATUS_INVALID_USER_BUFFER.

However when i issued the same call from a User mode application it worked
fine. What could be the problem here ?

Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
function in my driver expecting to intercept the NtFsControlFile() call. But
it did not hit the breakpoint…Is my filter driver getting bypassed for this
call ?

Thanks,
RB.


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@softhome.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Well, it sure looks like INVALID_USER_BUFFER is a generic return, so there
are LOTS of reasons why this one might return a failure. I presume you’ve
compiled FAT and walked through the code to see where it chokes, right? If
not, you should do so. If so, WHY is it choking?

Regards,

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

-----Original Message-----
From: RB [mailto:xxxxx@softhome.net]
Sent: Wednesday, October 04, 2000 10:25 AM
To: File Systems Developers
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

i need some more help on this. I tried having a custom IOCTL code in my
driver which will be called from an app passing in the OutPut Buffer. Then
in the driver i allocate an IRP with the IoControlCode field to be
FSCTL_GET_RETRIEVAL_POINTERS and the Irp->UserBuffer set to the OutPut
buffer passed by the app. This Irp i pass to the Filesystem. The return
status i found was still
STATUS_INVALID_USER_BUFFER.

Is this a feasible way of providing a user mode buffer ? I would greatly
appreciate more help…

Thanks and regds
RB.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
Sent: Monday, October 02, 2000 9:23 PM
To: File Systems Developers
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

This is a “well known problem”, where the FSD is checking to see if the
buffer address is valid - and the implementation of this assumes it must be
coming from user mode.

The “work around” is to use a user mode buffer. This is fixed in Windows
2000.

Regards,

Tony

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

-----Original Message-----
From: RB [mailto:xxxxx@softhome.net]
Sent: Monday, October 02, 2000 10:23 AM
To: File Systems Developers
Subject: [ntfsd] FSCTL_GET_RETRIEVAL_POINTERS

I am interested in getting the extent maps for a particular file in my
filter driver on NT 4.0
We tried using the NtFsControlFile() call but it returns a status of
STATUS_INVALID_USER_BUFFER.

However when i issued the same call from a User mode application it worked
fine. What could be the problem here ?

Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
function in my driver expecting to intercept the NtFsControlFile() call. But
it did not hit the breakpoint…Is my filter driver getting bypassed for this
call ?

Thanks,
RB.


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@softhome.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

For FAT(not know ) in NT 4 you must pass in user mode address
for both input and output buffers.
(The code in FASTFAT executes ProbeFroRead and ProbeForWrite
on these pointers without any verification of Irp->RequestorMode
=> this is a BUG !!!)

You can use one of two following workarounds:

  1. Allocate user mode virtual memory by using of
    Nt(Zw)AllocateVirtualMemory
    use it in the desired call and then free it by calling
    Nt(Zw)FreeVirtualMemory.

ADVANTAGE: it is very easy
DISADVANTAGE: the memory size requested has to be aligned to
PAGE_SIZE.

  1. Allocate buffer(s) in PagedPool by ExAllocatePool[With[Quota]Tag]
    Allocate MDL by IoAllocateMdl(with your buffer address)
    Lock down the buffer by calling MmProbeAndLockPages
    Map locked pages to user mode by MmMapLockedPages(, UserMode)
    use this address -> NtFsControlFile
    Call MmUnmapLockedPages to unpa the user mode addresses
    Call MmUnlockPages to unlock the buffer
    Call IoFreeMdl to free the MDL

ADVANTAGE: there is no need to allocate more memory than you need
DISADVANTAGE: entire process is complicated

I recommend to write separate two routines, one to map a buffer to
current process
virtual address space (use mode addreses) and one to unmap. For eg.:

PVOID
XxMapUserModeBuffer (
IN PVOID KernelAddress,
IN ULONG Length,
OUT PMDL *Mdl
)
{
*Mdl = IoAllocateMdl(KernelAddress, Length, FALSE, FALSE, NULL);
if (*Mdl == NULL)
{
return NULL; //or you can raise STATUS_INSUFFICIENT_RESOURCES
here
}

MmProbeAndLockPages(*Mdl, KernelMode, IoModifyAccess);
return MmMapLockedPages(*Mdl, UserMode);
}

VOID
XxUnmapUserModeBuffer (
IN PVOID UserAddress
IN PMDL Mdl
)
{
MmUnmapLockedPages(UserAddress, Mdl);
MmUnlcokPages(Mdl);
IoFreeMdl(Mdl);
}

Hope this helps.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of RB
Sent: Wednesday, October 04, 2000 4:25 PM
To: File Systems Developers
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

i need some more help on this. I tried having a custom IOCTL code in my
driver which will be called from an app passing in the OutPut Buffer.
Then
in the driver i allocate an IRP with the IoControlCode field to be
FSCTL_GET_RETRIEVAL_POINTERS and the Irp->UserBuffer set to the OutPut
buffer passed by the app. This Irp i pass to the Filesystem. The return
status i found was still
STATUS_INVALID_USER_BUFFER.

Is this a feasible way of providing a user mode buffer ? I would greatly
appreciate more help…

Thanks and regds
RB.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
Sent: Monday, October 02, 2000 9:23 PM
To: File Systems Developers
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

This is a “well known problem”, where the FSD is checking to see if the
buffer address is valid - and the implementation of this assumes it must
be
coming from user mode.

The “work around” is to use a user mode buffer. This is fixed in
Windows
2000.

Regards,

Tony

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

-----Original Message-----
From: RB [mailto:xxxxx@softhome.net]
Sent: Monday, October 02, 2000 10:23 AM
To: File Systems Developers
Subject: [ntfsd] FSCTL_GET_RETRIEVAL_POINTERS

I am interested in getting the extent maps for a particular file in my
filter driver on NT 4.0
We tried using the NtFsControlFile() call but it returns a status of
STATUS_INVALID_USER_BUFFER.

However when i issued the same call from a User mode application it
worked
fine. What could be the problem here ?

Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
function in my driver expecting to intercept the NtFsControlFile() call.
But
it did not hit the breakpoint…Is my filter driver getting bypassed for
this
call ?

Thanks,
RB.


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@softhome.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntfsd as: xxxxx@compelson.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

> Is this a feasible way of providing a user mode buffer ? I would greatly

appreciate more help…

Call ZwCreateSection (without the file handle)/ZwMapViewOfSection in your
driver while executing at PASSIVE_LEVEL in System process (from
ExQueueWorkItem callback, for instance).
This will give you the user mode memory belonging only for your driver.

Max

if the intent to obtain RETRIEVAL_POINTERS in the user mode then one more
way of doing this is to get handle to NtfsControlFile function from
ntdll.dll and then use this to get the retrieval pointers for the file.
I think on win2k you can use deviceIoControl function itself.

Harish

----- Original Message -----
From: RB
To: File Systems Developers
Sent: Wednesday, October 04, 2000 7:54 PM
Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS

> i need some more help on this. I tried having a custom IOCTL code in my
> driver which will be called from an app passing in the OutPut Buffer. Then
> in the driver i allocate an IRP with the IoControlCode field to be
> FSCTL_GET_RETRIEVAL_POINTERS and the Irp->UserBuffer set to the OutPut
> buffer passed by the app. This Irp i pass to the Filesystem. The return
> status i found was still
> STATUS_INVALID_USER_BUFFER.
>
> Is this a feasible way of providing a user mode buffer ? I would greatly
> appreciate more help…
>
> Thanks and regds
> RB.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
> Sent: Monday, October 02, 2000 9:23 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERS
>
>
> This is a “well known problem”, where the FSD is checking to see if the
> buffer address is valid - and the implementation of this assumes it must
be
> coming from user mode.
>
> The “work around” is to use a user mode buffer. This is fixed in Windows
> 2000.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: RB [mailto:xxxxx@softhome.net]
> Sent: Monday, October 02, 2000 10:23 AM
> To: File Systems Developers
> Subject: [ntfsd] FSCTL_GET_RETRIEVAL_POINTERS
>
>
> I am interested in getting the extent maps for a particular file in my
> filter driver on NT 4.0
> We tried using the NtFsControlFile() call but it returns a status of
> STATUS_INVALID_USER_BUFFER.
>
> However when i issued the same call from a User mode application it worked
> fine. What could be the problem here ?
>
> Also i tried setting a breakpoint for the IRP_MJ_FILE_SYSTEM_CONTROL
> function in my driver expecting to intercept the NtFsControlFile() call.
But
> it did not hit the breakpoint…Is my filter driver getting bypassed for
this
> call ?
>
> Thanks,
> RB.
>
>
> —
> 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@softhome.net
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@legato.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

RE: [ntfsd] RE: FSCTL_GET_RETRIEVAL_POINTERSHow about using ZwFsControlFile(which has same signature as that NtFsControlFile). From my driver code I was able to excute some FSCTLs using this call. I think buffer passed thru calls with Nt prefix( like NtFsControl) are probed by I/O manager( they should be valid user buffer) but the same is not done when passed using Zw calls.
ZwAllocateMemory call can be used to get user buffer, though i got away with kernel buffer only
This would be the case if the FSD is itself probing for the buffer