In my FS filter I want to write data to the FS from inside my filter.
I used ZwCreateFile to open a file handle in DriverEntry. I saved this
handle for later use. When I tried to write some data in some other IRP
handler, I got invalid handle. I read up the OSR thread about similar
problems, http://www.osronline.com/showThread.cfm?link=12031 However I
cannot understand how to use the solution presented here. I can use
ObReferenceObjectByHandle to get the FileObject, but then how do I use it to
write data? Also do I have to call this function, in driverentry?
How do I solve this problem, is there a simpler way?
I used ZwCreateFile to open a file handle in DriverEntry. I saved this
handle for later use. When I tried to write some data in some other IRP
handler, I got invalid handle. I read up the OSR thread about similar
problems, http://www.osronline.com/showThread.cfm?link=12031 However I
cannot understand how to use the solution presented here. I can use
ObReferenceObjectByHandle to get the FileObject, but then how do I use
it to write data? Also do I have to call this function, in driverentry?
How do I solve this problem, is there a simpler way?
To get the handle from the object pointer (which should be global)
again, you can use ObOpenObjectByPointer, declared in the IFS Kit.
In my FS filter I want to write data to the FS from inside my filter.
I used ZwCreateFile to open a file handle in DriverEntry. I saved this
handle for later use. When I tried to write some data in some other IRP
handler, I got invalid handle.
That’s because a handle is only valid is the context of the thread which
created it.
I read up the OSR thread about similar
problems, http://www.osronline.com/showThread.cfm?link=12031 However I
cannot understand how to use the solution presented here. I can use
ObReferenceObjectByHandle to get the FileObject, but then how do I use
it to write data? Also do I have to call this function, in driverentry?
How do I solve this problem, is there a simpler way?
I had a similar problem. What I did was to create a thread (with
PsCreateSystemThread()) and write data from this thread. Then your
driver sends the Irps to this thread using a simple communication
mechanism and a linked list. This method has got the advantage that if
your processing is long, it will not monopolize a work item.
You mean to say, that I use ObReferenceObjectByHandle in driverentry after
createfile suceeds to getthe FO, store away the FO somewhere and when I need
to write, I use ObOpenObjectByPointer, pass the FO to it andget a handle to
the file, then use ZwWriteFile to write to it?
That's because a handle is only valid is the context of the thread which
created it.
Actually inside the process. As far as I remember the handle table(s)
exist(s) on a per-process basis, not on a per-thread basis.
Regards,
Oliver Schneider
(Research & Development)
Lavasoft AB (Gothenburg, Sweden)
This message and any attachment are confidential and may be privileged
or otherwise protected from disclosure. If you are not the intended
recipient, please telephone or email the sender and delete this message
and any attachment from your system. If you are not the intended
recipient you must not copy this message or attachment or disclose the
contents to any other person.
You mean to say, that I use ObReferenceObjectByHandle in driverentry
after createfile suceeds to getthe FO, store away the FO somewhere and
when I need to write, I use ObOpenObjectByPointer, pass the FO to it
andget a handle to the file, then use ZwWriteFile to write to it?
In my opinion that should work. Just make sure the reference count of
the object does not drop to zero.
I am, however, not sure whether the object type for files is public. I
would have to look this up. The object manager functions seem to match
the object type against the object passed into the functions und certain
circumstances.
Regards,
Oliver Schneider
(Research & Development)
Lavasoft AB (Gothenburg, Sweden)
This message and any attachment are confidential and may be privileged
or otherwise protected from disclosure. If you are not the intended
recipient, please telephone or email the sender and delete this message
and any attachment from your system. If you are not the intended
recipient you must not copy this message or attachment or disclose the
contents to any other person.
"System components and device drivers often need to open handles to
objects that user-mode applications shouldn’t have access to. This is
done by creating handles in the kernel handle table (referenced
internally with the name ObpKernelHandleTable). The handles in this
table are accessible only from kernel mode and in any process context.
This means that a kernelmode function can reference the handle in any
process context with no performance impact. The object manager
recognizes references to handles from the kernel handle table when the
high bit of the handle is set?that is, when references to
kernel-handle-table handles have values greater than 0x80000000. "
There is some confusion about the kernel handles, since reading the
above text i too tried to access kernel handles form different
context, but i invariably crashed in ZwClose while closing the handle.
Kernel handles are different from normal usermode handles and are
supposed to available to all process running in kernel mode. I think
you are probably solving the wrong problem.
Thanks & Regards
Faraz /
On 3/20/06, amitr0 wrote: > hi all, > > In my FS filter I want to write data to the FS from inside my filter. > > I used ZwCreateFile to open a file handle in DriverEntry. I saved this > handle for later use. When I tried to write some data in some other IRP > handler, I got invalid handle. I read up the OSR thread about similar > problems, http://www.osronline.com/showThread.cfm?link=12031 However I > cannot understand how to use the solution presented here. I can use > ObReferenceObjectByHandle to get the FileObject, but then how do I use it to > write data? Also do I have to call this function, in driverentry? > > How do I solve this problem, is there a simpler way? > > Thanks > > – > > - amitr0 > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ > To unsubscribe send a blank email to xxxxx@lists.osr.com >
“Kernel handles are different from normal usermode handles and are
supposed to available to all process running in kernel mode. I think
you are probably solving the wrong problem.”
Well faraz, then how to solve the problem correctly…
How about specifying OBJ_KERNEL_HANDLE in InitializeObjectAttributes before
ZwCreateFile and make the handle valid in all process contexts.
IUknown
On 3/21/06, amitr0 wrote: > > “Kernel handles are different from normal usermode handles and are > supposed to available to all process running in kernel mode. I think > you are probably solving the wrong problem.” > > Well faraz, then how to solve the problem correctly… > — Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 You are currently subscribed > to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank > email to xxxxx@lists.osr.com >
"Kernel handles are different from normal usermode handles and are
supposed to available to all process running in kernel mode. I think
you are probably solving the wrong problem."
Well faraz, then how to solve the problem correctly...
The idea is not too bad. What he means is probably to specify
OBJ_KERNEL_HANDLE in the flags of OBJECT_ATTRIBUTES when creating that file.
Regards,
Oliver Schneider
(Research & Development)
Lavasoft AB (Gothenburg, Sweden)
This message and any attachment are confidential and may be privileged
or otherwise protected from disclosure. If you are not the intended
recipient, please telephone or email the sender and delete this message
and any attachment from your system. If you are not the intended
recipient you must not copy this message or attachment or disclose the
contents to any other person.
Would this enable me to access the file using the handle retunred from
other dispatch routines at other IRQLs?
Yes and no. It should enable to be called in other process contexts
(i.e. threads in a process different from the one that created/opened
the file). However, the IFS Kit clearly states the following:
-> Callers of ZwCreateFile must be running at IRQL = PASSIVE_LEVEL and
with APCs enabled.
-> Callers of ZwReadFile must be running at IRQL = PASSIVE_LEVEL and
with APCs enabled.
-> Callers of ZwWriteFile must be running at IRQL = PASSIVE_LEVEL and
with APCs enabled.
So you are quite limited with the IRQL. But AFAIK that applies to all
Zw* and Nt* functions in NTOSKRNL.EXE!
Regards,
Oliver Schneider
(Research & Development)
Lavasoft AB (Gothenburg, Sweden)
This message and any attachment are confidential and may be privileged
or otherwise protected from disclosure. If you are not the intended
recipient, please telephone or email the sender and delete this message
and any attachment from your system. If you are not the intended
recipient you must not copy this message or attachment or disclose the
contents to any other person.
“How about specifying OBJ_KERNEL_HANDLE in InitializeObjectAttributes before
ZwCreateFile and make the handle valid in all process contexts.”
Yes it should work.
But … Some how specifying OBJ_KERNEL_HANDLE gave me an kernel handle
starting with 0x8000* but it still crashed. (Iam sure i was doing something
wrong)
Neways Amit the only way to correctly solve it, is as the doyens described,
do way with storing handles save the pointer instead and get the Handle from
the pointer as an when needed. Only pitfall is balancing the ZwClose call
for every handle that you take. Please read the object manager for more
information on handle count and refernece counts.
Not balancing the Open and Close for handle in kernel mode can take to
UNIMAGINABLE CRASHED in stacks of code u wont even know. So pay a lot of
attention to it.
I did away with the handle i never needed it anyways, i needed a section
object, i got it and closed the file immidiately.
Regards
Faraz.
On 3/21/06, amitr0 wrote: > > “Kernel handles are different from normal usermode handles and are > supposed to available to all process running in kernel mode. I think > you are probably solving the wrong problem.” > > Well faraz, then how to solve the problem correctly… > — Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 You are currently subscribed > to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank > email to xxxxx@lists.osr.com >
“Would this enable me to access the file using the handle retunred from
other dispatch routines at other IRQLs?”
Refine your desing, you should avoid having the need of doing
EXOTIC stuff like going to sleep and accessing non paged pool with IRQL >
PASSIVE. Neways you cannot access the handle at any IRQL, to get around the
problem queue the work item, next i see is you would decide to wait for work
item to complete, this is contradicting your first solution i.e dont
sleep at a higher IRQL
So dont do it. Redesign the code, that is easiest way out.
To get a kernel handle this works for me.
InitializeObjectAttributes(&ObjectAttributes,
volumeName,
OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE,
NULL,
NULL);
On 3/21/06, amitr0 wrote: > > well, OBJ_KERNEL_HANDLE doesnt work. I tried it. I still get status > invalid handle. > — Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 You are currently subscribed > to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank > email to xxxxx@lists.osr.com >
thanks for all th help and sample codes. I am immensely grateful. However,
there is something else in this matter i want to ask you guys. Calling Zw*
routines inside FSFD causes reentrancy problems, this fact is well known.
Can some one give me some pointers to reading materials aboutt he same.
There was something in OSR if I am not mistaken, still if you have any thing
worht sharing…
> This works for me.
Well, I believe he has problems to use the handles afterwards in a call
that expects file handle and probably in a different context then.
However, there is something else in this matter i want to ask you guys.
Calling Zw* routines inside FSFD causes reentrancy problems, this fact
is well known. Can some one give me some pointers to reading materials
aboutt he same. There was something in OSR if I am not mistaken, still
if you have any thing worht sharing...
Why not hand selfmade IRPs down to the driver below you? I mean
reentrancy occurs only because you get back an object you created. Yet
you know who sits below you, so why not talk to that guy directly?
I did consider that option. But I am fairly new to drivers. I am not sure
how to go about doing what you suggested. ZwWriteFile breaks into multiple
IRPS, how do I emulate this system call flawlessly at my level, is there any
sample code that can guide me?
i.e dont