Hi, all
I found that the handle returned by NtCreateFile cannot be passed
to Win32 functions. They return ERROR_INVALID_PARAMETER
if you try it.
But the handle can be passed to IOCTL data structures (these
structures will go through Win32, Ntdll.dll, ntoskrnl, filters to the file
systems). So the handle must be valid in the native NT world.
Could anyone explain this ? Does Win32 layer store the handle in
a hash table, mapping the handle to some additional data ?
L.
Is this a kernel handle ? Kernel handles cannot be used from user mode.
-Kiran
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Wednesday, May 11, 2005 5:27 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Win32 handle vs. NT handle
Hi, all
I found that the handle returned by NtCreateFile cannot be passed to Win32
functions. They return ERROR_INVALID_PARAMETER if you try it.
But the handle can be passed to IOCTL data structures (these structures will
go through Win32, Ntdll.dll, ntoskrnl, filters to the file systems). So the
handle must be valid in the native NT world.
Could anyone explain this ? Does Win32 layer store the handle in a hash
table, mapping the handle to some additional data ?
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
> Is this a kernel handle ? Kernel handles cannot be used from user mode.
Normal handle. The NtCreateFile has been called
from user mode program. The handle value seems to be normal
like 0x000007F3 or so …
L.
> I found that the handle returned by NtCreateFile cannot be passed
to Win32 functions. They return ERROR_INVALID_PARAMETER
if you try it.
I know that a user mode event handle um_Handle can be “converted” into a
kernel mode event handle myExtension->pkm_Handle
(PKEVENT actually):
status = ObReferenceObjectByHandle(um_Handle,
EVENT_MODIFY_STATE, *ExEventObjectType, UserMode, // KernelMode ???
(PVOID*)&(myExtension->pkm_Handle), NULL);
Wild guess: what if the inverse is also possible?
Alex
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 7:57 AM
Subject: [ntfsd] Win32 handle vs. NT handle
> Hi, all
>
> I found that the handle returned by NtCreateFile cannot be passed
> to Win32 functions. They return ERROR_INVALID_PARAMETER
> if you try it.
>
> But the handle can be passed to IOCTL data structures (these
> structures will go through Win32, Ntdll.dll, ntoskrnl, filters to the file
> systems). So the handle must be valid in the native NT world.
>
> Could anyone explain this ? Does Win32 layer store the handle in
> a hash table, mapping the handle to some additional data ?
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@bellsouth.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
The result of ObReferenceObjectByHandle() is a object pointer. It is very
wrong to refere to
such a pointer as a "kernel mode event handle ", for it is not.
The inverse is of course possible. There are ways to open a object by
pointer.
Dan
----- Original Message -----
From: “xxxxx@Home”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 4:06 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
>> I found that the handle returned by NtCreateFile cannot be passed
>> to Win32 functions. They return ERROR_INVALID_PARAMETER
>> if you try it.
> I know that a user mode event handle um_Handle can be “converted” into a
> kernel mode event handle myExtension->pkm_Handle
> (PKEVENT actually):
>
> status = ObReferenceObjectByHandle(um_Handle,
> EVENT_MODIFY_STATE, ExEventObjectType, UserMode, // KernelMode ???
> (PVOID)&(myExtension->pkm_Handle), NULL);
>
> Wild guess: what if the inverse is also possible?
>
> Alex
>
>
> ----- Original Message -----
> From: “Ladislav Zezula”
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, May 11, 2005 7:57 AM
> Subject: [ntfsd] Win32 handle vs. NT handle
>
>
>> Hi, all
>>
>> I found that the handle returned by NtCreateFile cannot be passed
>> to Win32 functions. They return ERROR_INVALID_PARAMETER
>> if you try it.
>>
>> But the handle can be passed to IOCTL data structures (these
>> structures will go through Win32, Ntdll.dll, ntoskrnl, filters to the
>> file
>> systems). So the handle must be valid in the native NT world.
>>
>> Could anyone explain this ? Does Win32 layer store the handle in
>> a hash table, mapping the handle to some additional data ?
>>
>> L.
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@bellsouth.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> The result of ObReferenceObjectByHandle() is a object pointer. It is very
wrong to refere to
such a pointer as a "kernel mode event handle ", for it is not.
Well, if it works in all wait operations in the kernel mode (KeWait…), it
is “an event handle” for me.
If it looks like a dog, barks like a dog etc.
The inverse is of course possible. There are ways to open a object by
pointer.
This was not the question. Will the result work after being passed into the
user mode?
I personally doubt it.
Regards,
Alex
Ladislav Zezula wrote:
Hi, all
I found that the handle returned by NtCreateFile cannot be passed
to Win32 functions. They return ERROR_INVALID_PARAMETER
if you try it.
I do this regularly–
I suspect something else wrong with your call to win32.
I thught you got a different error if the handle wasn’t
valid (like ERROR_INVALID_HANDLE.) However…
The handle value seems to be normal
like 0x000007F3 or so …
I also thought that handles were always even
values (I could be wrong about that.)
In fact, in getting several handles I saw
0x79C, 0x798, and 0x794 as values.
Are you sure NtCreateFile is returning succes, and are you
sure you are passing in &hMyHandle to NtCreateFile, but plain
hMyHandle everyplace else?
I think HANDLE is typedef void* HANDLE so it is easy to
pass it wrong-- though I’m not sure if the compiler will
let you do what I’ve just suggested or not.
Thanks,
Joseph
>>works in all wait operations in the kernel mode (KeWait…), it is "an
>event handle" for me.
Your understanding of kernel mode operations and definitions of terms is
very limited.
Distinction between handles and object is elementar, and whithout it you
wont get far.
Dan
----- Original Message -----
From: “xxxxx@Home”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 5:58 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
>> The result of ObReferenceObjectByHandle() is a object pointer. It is very
>> wrong to refere to
>> such a pointer as a "kernel mode event handle ", for it is not.
> Well, if it works in all wait operations in the kernel mode (KeWait…),
> it is “an event handle” for me.
> If it looks like a dog, barks like a dog etc.
>
>> The inverse is of course possible. There are ways to open a object by
>> pointer.
> This was not the question. Will the result work after being passed into
> the user mode?
> I personally doubt it.
>
> Regards,
> Alex
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
xxxxx@Home wrote:
> The result of ObReferenceObjectByHandle() is a object pointer. It is
> very wrong to refere to
> such a pointer as a "kernel mode event handle ", for it is not.Well, if it works in all wait operations in the kernel mode (KeWait…),
it is “an event handle” for me.
If it looks like a dog, barks like a dog etc.
If you use ObReferenceObjectByHandle(), you do not
use ZwCloseHandle() to dispose of the resulting
‘thing’ (but rather ObDeferenceObject.)
Nor can you pass the resulting ‘thing’ to ZwReadFile
or ZwWriteFile. Indeed, it is not a handle, and can’t
be passed to any function requiring a handle.
In this case, it may look like a dog, but it
is howling like a wolf. The difference can get you
eaten (or cause a blue-screen of death.)
I’m pretty sure the compiler will happily let you
pass it to ZwCloseHandle() or any other handle taking
function (since handles are typed as void*)
But it surely won’t work. If you’re lucky it will
return a ERROR_INVALID_HANDLE status…
> The inverse is of course possible. There are ways to open a object by
> pointer.This was not the question. Will the result work after being passed into
the user mode?
I’m pretty sure it actually does-- but you have to be pretty
aware of your context when you create the handle, since it will
be created in the context of the process currently running.
(Don’t do this from arbitrary thread context, the results
won’t be pretty.)
Thanks,
Joseph
To Joseph:
you do not use ZwCloseHandle() to dispose of the resulting
True.
Indeed, it is not a handle, and can’t be passed to any function requiring
a handle.
Isn’t KeSetEvent one of these functions?
If yes (and the answer is yes), then your statement is not correct.
Ok, it sometimes barks like a dog, not always, but I did not state that
much, did I?
You seem to forget the essence of the original question.
Its idea was: how can I make an “exchange” between the two worlds, to get
AThing
from one world that (possibly not 100% but at least somewhat) resembles
AThing
in another world?
And my answer dealt with the question: I noted that in one direction (an
opposite
to what was necessary though, as I noted) it does work - with limitations,
part of which
you so generously listed.
I create user-mode events and pass them to my driver[s] for them to set
these events
using KeSetEvent. Functionally it looks like a [partial] “transformation”,
because the user-mode code successfully waits for those events
(WaitForSingleObject and
the like).
Oh, I suddenly realized that all this came from Oney’s book, ch.9 : “To get
around these two
problems with the event handle, the driver has to “convert” the handle to a
pointer to the
underlying KEVENT object.”
Well,Oney says “convert”, I said “transform”…
As I said, I do not know whether I can take KEVENT and - after some magic -
produce “something” that I can return to the user mode to be (in some cases)
used as a
HANDLE; I never tried but I doubt that it’s possible though.
To Dan:
Your understanding of kernel mode operations and definitions of terms is
very limited.
Probably true, but my poor IQ is discussed in a different message board.
Distinction between handles and object is elementar, and whithout it you
wont get far.
Absolutely.
I have no chances, even the most elementar ones.
You can’t get far whithout knowledge.
Respectfully yours,
Alex Shvedov
Alex, im not debating your IQ here. I only corrected your statement that a
object pointer is a handle, or “some kind of handle”. When you post an
answer to a quastion, be sure it is correct, and uses well defined terms.
Else, your answer can be misleading for either OP, either somebody who will
later browse the archives. Beginers wont detect the flaws in your post, and
thus you are misleading them. The conecpts of handles, objects, reference
counting are cornerstones in NT
kernel mode design.
>Indeed, it is not a handle, and can’t be passed to any function requiring
>a handle.
> Isn’t KeSetEvent one of these functions ?
KeSetEvent does not take a handle. You are wrong, and it seems that this
comes from you
not making a distinction between a handle and a object.
Dan
----- Original Message -----
From: “xxxxx@Home”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 7:47 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
> To Joseph:
>> you do not use ZwCloseHandle() to dispose of the resulting
> True.
>
>> Indeed, it is not a handle, and can’t be passed to any function requiring
>> a handle.
> Isn’t KeSetEvent one of these functions?
> If yes (and the answer is yes), then your statement is not correct.
>
> Ok, it sometimes barks like a dog, not always, but I did not state that
> much, did I?
>
> You seem to forget the essence of the original question.
> Its idea was: how can I make an “exchange” between the two worlds, to get
> AThing
> from one world that (possibly not 100% but at least somewhat) resembles
> AThing
> in another world?
>
> And my answer dealt with the question: I noted that in one direction (an
> opposite
> to what was necessary though, as I noted) it does work - with limitations,
> part of which
> you so generously listed.
>
> I create user-mode events and pass them to my driver[s] for them to set
> these events
> using KeSetEvent. Functionally it looks like a [partial]
> “transformation”,
> because the user-mode code successfully waits for those events
> (WaitForSingleObject and
> the like).
>
> Oh, I suddenly realized that all this came from Oney’s book, ch.9 : “To
> get around these two
> problems with the event handle, the driver has to “convert” the handle to
> a pointer to the
> underlying KEVENT object.”
>
> Well,Oney says “convert”, I said “transform”…
>
> As I said, I do not know whether I can take KEVENT and - after some
> magic -
> produce “something” that I can return to the user mode to be (in some
> cases) used as a
> HANDLE; I never tried but I doubt that it’s possible though.
>
> To Dan:
>> Your understanding of kernel mode operations and definitions of terms is
>> very limited.
> Probably true, but my poor IQ is discussed in a different message board.
>
>> Distinction between handles and object is elementar, and whithout it you
>> wont get far.
> Absolutely.
> I have no chances, even the most elementar ones.
> You can’t get far whithout knowledge.
>
> Respectfully yours,
> Alex Shvedov
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
KeSetEvent does not take a handle. As others have said, go back and learn
the basics.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“xxxxx@Home” wrote in message news:xxxxx@ntfsd…
> To Joseph:
>> you do not use ZwCloseHandle() to dispose of the resulting
> True.
>
>> Indeed, it is not a handle, and can’t be passed to any function requiring
>> a handle.
> Isn’t KeSetEvent one of these functions?
> If yes (and the answer is yes), then your statement is not correct.
>
> Ok, it sometimes barks like a dog, not always, but I did not state that
> much, did I?
>
> You seem to forget the essence of the original question.
> Its idea was: how can I make an “exchange” between the two worlds, to get
> AThing
> from one world that (possibly not 100% but at least somewhat) resembles
> AThing
> in another world?
>
> And my answer dealt with the question: I noted that in one direction (an
> opposite
> to what was necessary though, as I noted) it does work - with limitations,
> part of which
> you so generously listed.
>
> I create user-mode events and pass them to my driver[s] for them to set
> these events
> using KeSetEvent. Functionally it looks like a [partial]
> “transformation”,
> because the user-mode code successfully waits for those events
> (WaitForSingleObject and
> the like).
>
> Oh, I suddenly realized that all this came from Oney’s book, ch.9 : “To
> get around these two
> problems with the event handle, the driver has to “convert” the handle to
> a pointer to the
> underlying KEVENT object.”
>
> Well,Oney says “convert”, I said “transform”…
>
> As I said, I do not know whether I can take KEVENT and - after some
> magic -
> produce “something” that I can return to the user mode to be (in some
> cases) used as a
> HANDLE; I never tried but I doubt that it’s possible though.
>
> To Dan:
>> Your understanding of kernel mode operations and definitions of terms is
>> very limited.
> Probably true, but my poor IQ is discussed in a different message board.
>
>> Distinction between handles and object is elementar, and whithout it you
>> wont get far.
> Absolutely.
> I have no chances, even the most elementar ones.
> You can’t get far whithout knowledge.
>
> Respectfully yours,
> Alex Shvedov
>
>
???
CreateFile is a direct wrapper over NtCreateFile.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 3:57 PM
Subject: [ntfsd] Win32 handle vs. NT handle
> Hi, all
>
> I found that the handle returned by NtCreateFile cannot be passed
> to Win32 functions. They return ERROR_INVALID_PARAMETER
> if you try it.
>
> But the handle can be passed to IOCTL data structures (these
> structures will go through Win32, Ntdll.dll, ntoskrnl, filters to the file
> systems). So the handle must be valid in the native NT world.
>
> Could anyone explain this ? Does Win32 layer store the handle in
> a hash table, mapping the handle to some additional data ?
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Reset the 2 junior bits in the handle value.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 5:07 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
> > Is this a kernel handle ? Kernel handles cannot be used from user mode.
>
> Normal handle. The NtCreateFile has been called
> from user mode program. The handle value seems to be normal
> like 0x000007F3 or so …
>
> L.
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> I only corrected your statement that a object pointer is a handle, or
“some kind of handle”.
The code snippet made any actual confusion impossible.
When you post an answer to a quastion, be sure it is correct, and uses
well defined terms.
There is one more useful thing: not to forget the actual question.
The question was not about formal or less formal language.
[Note that a lot guru’s answers in this group are expressed in less than
“less than formal” language, take
mr. Don Burn, for example; he writes “when I try it on XP or 2003”, and
everyone, me included, is ok with that.]
The question was about “how can I create AThing There and transform it so
that it becomes usable in some reasonable way Here?”
KeSetEvent does not take a handle. You are wrong, and it seems that this
comes from you
not making a distinction between a handle and a object.
Well, I am sure you understood me just fine, “KeSet… actually works on an
OBJECT to which
the user-mode HANDLE referred to so both worlds talk to each other just
fine”.
It’s possible that you are not the only one who undesrtood it the same
way.
In any case, Dan and Don, I want to thank you both and consider the
discussion closed.
Regards
Alex Shvedov
>> The question was not about formal or less formal language.
Yes you are right. Lets all call pointers like we want. In a less formal
language Ill call a pointer from now on a 
Im not here to debate philosophy and retorics with you. Im here to make sure
that other ppl dont beleive that KeSetEvent() takes a handle as parameter,
as you implied black on white. A poster was kind enough to explain some
stuff to you, and you went strait ahead underlining that KeSetEvent() takes
a handle, and argue that he is wrong. Even now, you insist beeing right.
> Note that a lot guru’s answers
Im on this list for years. I dont have anything to note. You, on the other
hand, are quite new, and you should observe or note, as you say, a little
more, the way those ppl you consider guru give the anserws, and why
sometimes they say “On 2003” or “NT”. But I ensure you, a handle is still a
handle, regardless is Windows Nt ot Server 2003.
Dan
----- Original Message -----
From: “xxxxx@Home”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 10:53 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
>> I only corrected your statement that a object pointer is a handle, or
>> “some kind of handle”.
> The code snippet made any actual confusion impossible.
>
>> When you post an answer to a quastion, be sure it is correct, and uses
>> well defined terms.
> There is one more useful thing: not to forget the actual question.
>
> The question was not about formal or less formal language.
>
> [Note that a lot guru’s answers in this group are expressed in less than
> “less than formal” language, take
> mr. Don Burn, for example; he writes “when I try it on XP or 2003”, and
> everyone, me included, is ok with that.]
>
> The question was about “how can I create AThing There and transform it so
> that it becomes usable in some reasonable way Here?”
>
>> KeSetEvent does not take a handle. You are wrong, and it seems that this
>> comes from you
>> not making a distinction between a handle and a object.
> Well, I am sure you understood me just fine, “KeSet… actually works on
> an OBJECT to which
> the user-mode HANDLE referred to so both worlds talk to each other just
> fine”.
>
> It’s possible that you are not the only one who undesrtood it the same
> way.
>
> In any case, Dan and Don, I want to thank you both and consider the
> discussion closed.
>
> Regards
> Alex Shvedov
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
xxxxx@Home wrote:
> I only corrected your statement that a object pointer is a handle, or
> “some kind of handle”.The code snippet made any actual confusion impossible.
Mr. Shvedov: Number 1) Stop being silly and show Mr. Partelly some
respect. He’s earned it as a long time expert contributor to this group.
Mr. Shvedov: Number 2) The first parameter to NtCreateFile is of type
PHANDLE. The first parameter to KeSetEvent is a PRKEVENT. They are not
the same type. The difference is not merely pendantic or trivial as you
seem to suggest. Handles and pointers cannot be used interchangeably in
any situation. The object manager specifically accounts for HANDLES and
POINTERS to objects differently. Thus, the object manager has calls
that create HANDLES. And it has calls the create POINTERS to objects.
Everybody else who still cares: Number 3) Now, to amplify on answer Mr.
Shatskih’s entirely correct answer to Mr. Zezula’s original question:
Handles are managed on a per-process basis, and represent an offset
(actually a table and offset) into the processes handle table. There is
no difference between Win32 handles and those used by any other part of
the OS. So, to be absolutely sure I’m being clear: The proper
interpretation of a handle is entirely dependent upon the process
context in which the handle is used. Every process almost certainly has
a handle 0x8, for example. (Which leads us, Mr. Shvedov if you’re still
reading, to another important distinction between handles and pointers:
Handles are process-specific, and pointers to objects are not).
There IS also a kernel handle table. Handles in the kernel handle table
can only be created and used in kernel mode. The (other) interesting
and useful thing about handles in the kernel handle table is that they
are interpreted without regard to process context. As an implementation
detail, one will observe that handles located in the kernel handle table
have their high bit set. This allows them to be distinguished easily.
Finally, Mr. Shatskih alluded to the low two bits of the handle value,
which are set in Mr. Zezula’s example (IIRC, the value Mr. Zezula
provided was 0x000007F3). These two bits are, essentially, reserved for
use by user-mode entities, and are ignored by kernel-level code in the
OS. As Mr. Shatskih suggested, I would also recommend you try clearing
these two least significant bits.
Note that there’s a debugger extension, !handle, that can be used to
display information about the handle. You can even use this extension
to display the handle meaning for a give process, given either a
PEPROCESS or a process unique ID.
Peter
OSR
> Mr. Shvedov: Number 1) Stop being silly and show Mr. Partelly some
respect. He’s earned it as a long time expert contributor to this group.
I did not show any disrespect to anyone. I double-checked my recent posts -
none whatsoever.
I tried to stop this… strange convesation in which both sides actually
understand
what has been said (and what has not been) but as I now see I did not
succeed, and
my IQ yet again became a subject.
I am sorry with all my heart and what’s left of my IQ.
Mr. Shvedov: Number 2) The first parameter to NtCreateFile is of type
PHANDLE. The first parameter to KeSetEvent is a PRKEVENT. They are not
the same type.
Nobody said - in a formal context - they are.
There is, as I mentioned a couple of times, a difference between languages,
programming vs human.
I guess I am not the only one who - conversationally - used, let’s say,
“closing the handle” and “closing
a file” interchangeably, which may or may not be the same thing.
Human language allows such frivolities - to an extent, in context.
Handles and pointers cannot be used interchangeably in any situation.
Who ever stated that they can?
Everybody else who still cares: Number 3) Now, to amplify on answer Mr.
Shatskih’s entirely correct answer to Mr. Zezula’s original question:
I do care, and I’m sure almost all subscribers do.
Yours is an explanation I myself was looking for for quite some time.
Thank you for a deep, exhaustive answer.
You were more than helpful.
But really: it’s your turn to stop being … - well, to pretend that you
don’t understand what’s going on.
Writing drivers is the most challenging programming task, and all these
messages are for those who knows
the difference between a handle and an object.
Your [very professional] explanation is simply useless for anyone who does
not, isn’t it?
And yes, you, being a human, are allowed to use human language and say, for
example, “Handles are process-specific, and
pointers to objects are not”, and nobody suspects that you think that some
void* pA = 0x12345678 inside
process A and some void* pB = 0x12345678 inside process B are the same,
nobody dares to respond with
something like “Aha! He says that pointers are not process specific !!! He
thinks that pA and pB are the same !!!”
To me such suspicion would sound foolish or insulting or both - or just
funny.
So - it was never about pointers vs handles, and you know it.
In the meantime I’d better switch to printing your post. It’ll be time well
spent.
Regards,
Alex Shvedov
Sound interesting…
I tried to dig out more about the relations between HANDLE and OBJECT. I
couldn’t understand completely what you said, please correct me if I
wrong…
Each time a device-driver receives an IRP_MJ_CREATE request it should
create a new “internal device-handle”, filling the content of PFILE_OBJECT
(=>POBJECT, IO_TYPE_FILE): FsContext/FsContext2 etc… (Let’s ignore the
fact that some drivers ignore user-handles).
Previous to the request “IRP_MJ_CREATE” the object-manager (Ob* API)
creates the PFILE_OBJECT in response to some internal unknown system-call.
The handle which returns to the user/kernel is some complex undocumented
reference-countable wrapper around the POBJECT.
So the result of NtCreateFile is a handle to the object-manager, which
can be transformed to PFILE_OBJECT and PDEVICE_OBJECT by calling some
ObReferenceObjectByHandle.
So far for grade-school device-driver lesson, (I just wanted to clear myself
so the last thread will not repeat itself, and maybe I have some elementary
fault).
For my question,
Does the object manager marks the handle/file-object with a “Requestor-Mode”
and if so why should it store it in the “2 junior bits” in the handle? Isn’t
a security risk?
And the result of storing the “Requestor-Mode” inside the HANDLE or the
POBJECT may result in “Access-denied, invalid-param” if user-mode
(KeGetPreviousMode = UserMode) tries to access the handle.
P.S.
From what I can tell from a quick view of ntoskrnl.exe in WinDbg is that all
Nt* API starts with “KeGetPreviousMode” function call. So my theory may be
right.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, May 11, 2005 8:17 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Win32 handle vs. NT handle
Reset the 2 junior bits in the handle value.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 11, 2005 5:07 PM
Subject: Re: [ntfsd] Win32 handle vs. NT handle
> > Is this a kernel handle ? Kernel handles cannot be used from user mode.
>
> Normal handle. The NtCreateFile has been called
> from user mode program. The handle value seems to be normal
> like 0x000007F3 or so …
>
> L.
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@raztech.co.il
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thank you all for oppinions, but hang on with
fuhrter discussion. I haven’t even expected such
amount of answers 
I also see that I forgot to specify
some things more exactly, so I’m doing it now
The question had nothing to do with drivers,
even with kernel mode at all. The phenomenon
I observed was all in a small usermode testprogram.
(see below). It also was all in one process.
I mistypped the handle, it should be even (0x000007F4).
I tested the NtCreateFile against ReadFile again,
and it really does not seem to work (even if the handle
retrieved by NtCreateFile has the same numeric value
like the one returned by CreateFile).
Here is the code I used for test. It’s just a testprogram,
don’t write me that I forgot to close the handle or
there are some unused variables :-))
The NtCreateFile (if uncommented), ends with STATUS_SUCCESS.
The if you try to pass the handle to the ReadFile, it does not read anything
and returns ERROR_INVALID_PARAMETER (0x57).
If you want to see the complete testprogram as Visual Studio
project, get it from http://www.zezula.net/download/test.zip
As you can see, the testprogram is nothing special, just open and read.
void main(void)
{
OBJECT_ATTRIBUTES ObjAttr;
UNICODE_STRING NtFileName;
IO_STATUS_BLOCK IoStatus;
NTSTATUS Status = 0;
HANDLE hFile = NULL;
DWORD dwTransferred = 0;
TCHAR szNtFileName[MAX_PATH] = L"\??\E:\TestPST1.pst";
BYTE Buffer[200];
INIT_UNICODE_STRING(NtFileName, szNtFileName);
InitializeObjectAttributes(&ObjAttr, &NtFileName, OBJ_CASE_INSENSITIVE,
NULL, NULL);
/*
NtCreateFile(&hFile,
FILE_READ_DATA,
&ObjAttr,
&IoStatus,
NULL,
0,
FILE_SHARE_READ,
FILE_OPEN,
FILE_NON_DIRECTORY_FILE,
NULL,
0);
*/
hFile = CreateFile(_T(“E:\TestPST1.pst”), FILE_READ_DATA,
FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if(hFile != INVALID_HANDLE_VALUE && hFile != NULL)
{
ReadFile(hFile, Buffer, sizeof(Buffer), &dwTransferred, NULL);
if(dwTransferred == 0)
Status = GetLastError();
}
}