virtual address mapping across processes

Hello there,
I wish to create a virtual address in a process for
an address coming in from another process, any suggestions???

> Hello there,

I wish to create a virtual address in a process for
an address coming in from another process, any suggestions???

MmMapLockedPages(…UserMode…)
Don’t forget to unmap it on process termination.

Max

Is there a way to map handles across address spaces as well? In particular, I’m interested in handles produced by ZwCreateFile().

david

At 01:37 PM 4/16/00 +0400, you wrote:

> Hello there,
> I wish to create a virtual address in a process for
> an address coming in from another process, any suggestions???

MmMapLockedPages(…UserMode…)
Don’t forget to unmap it on process termination.

Max


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

Ahh, Nagar++. You can call ObReferenceObjectByHandle() to get a pointer to the object for which you have a handle, and ObOpenObjectByPointer() to get a handle from the pointer. These increment a count on the object, so remember to call ObDereferenceObject() enough times to get that count back to zero.

One small issue: ObOpenObjectByPointer is not documented in the DDK. How safe is it to use undocumented functions? Is there a way to test for the existence of a function short of using it? Anyone here been burned by changes to undocumented functions?

thanks,

david

At 10:27 PM 4/27/00 -0700, you wrote:

Is there a way to map handles across address spaces as well? In particular, I’m interested in handles produced by ZwCreateFile().

david

At 01:37 PM 4/16/00 +0400, you wrote:
> > Hello there,
> > I wish to create a virtual address in a process for
> > an address coming in from another process, any suggestions???
>
>MmMapLockedPages(…UserMode…)
>Don’t forget to unmap it on process termination.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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

I used ObReferenceObjectByHandle() & ObOpenObjectByPointer() to duplicate
registry handles once. It generally worked, but led to a rare deadlock.
I’m hard-pressed to remember the details, but it had to do with what
appeared to be a global ERESOURCE for serializing access to the registry.
Somehow, some thread that already had the lock ended up waiting on my
thread (ours is a storage driver) which was blocked trying to get the
lock inside ObOpenObject…

Just a word of warning, what you’re proposing does work, but you need
to be careful.

BTW, I found a different solution to my problem (open another handle to
a key whose full path I don’t have): ZwOpenKey() with the existing
handle as the parent, and an empty string as the relative path.

Of course, I wasn’t trying to get a handle in a different process context.
For that, you would need an intermediary object.


Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: david c. steere [mailto:xxxxx@cse.ogi.edu]
Sent: Friday, April 28, 2000 11:27 AM
To: File Systems Developers
Subject: [ntfsd] Re: virtual address mapping across processes

Ahh, Nagar++. You can call ObReferenceObjectByHandle() to get a pointer to
the object for which you have a handle, and ObOpenObjectByPointer() to get a
handle from the pointer. These increment a count on the object, so remember
to call ObDereferenceObject() enough times to get that count back to zero.

One small issue: ObOpenObjectByPointer is not documented in the DDK. How
safe is it to use undocumented functions? Is there a way to test for the
existence of a function short of using it? Anyone here been burned by
changes to undocumented functions?

thanks,

david

At 10:27 PM 4/27/00 -0700, you wrote:

Is there a way to map handles across address spaces as well? In particular,
I’m interested in handles produced by ZwCreateFile().

david

At 01:37 PM 4/16/00 +0400, you wrote:
> > Hello there,
> > I wish to create a virtual address in a process for
> > an address coming in from another process, any suggestions???
>
>MmMapLockedPages(…UserMode…)
>Don’t forget to unmap it on process termination.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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


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

Try to use Nt(Zw)DuplicateObject (if you need handle) or KeAttachProcess,
ObReferenceObjectByXxxx, KeDetachProcess (if you need pointer).

Paul

-----P?vodn? zpr?va-----
Od: david c. steere [SMTP:xxxxx@cse.ogi.edu]
Odesl?no: 28. dubna 2000 7:28
Komu: File Systems Developers
P?edm?t: [ntfsd] Re: virtual address mapping across processes

Is there a way to map handles across address spaces as well? In
particular, I’m interested in handles produced by ZwCreateFile().

david

At 01:37 PM 4/16/00 +0400, you wrote:
> > Hello there,
> > I wish to create a virtual address in a process for
> > an address coming in from another process, any suggestions???
>
>MmMapLockedPages(…UserMode…)
>Don’t forget to unmap it on process termination.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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

I saw an anomaly like this with file objects. Perhaps its an internal
executive deadlock, possibly an inverted locking order between two tightly
bound subsystems, such as the object manager and the process structure?

-----Original Message-----
From: COX,DAVID (HP-Roseville,ex1) [mailto:david_cox2@hp.com]
Sent: Friday, April 28, 2000 7:55 PM
To: File Systems Developers
Subject: [ntfsd] Re: virtual address mapping across processes

I used ObReferenceObjectByHandle() & ObOpenObjectByPointer()
to duplicate
registry handles once. It generally worked, but led to a
rare deadlock.
I’m hard-pressed to remember the details, but it had to do with what
appeared to be a global ERESOURCE for serializing access to
the registry.
Somehow, some thread that already had the lock ended up waiting on my
thread (ours is a storage driver) which was blocked trying to get the
lock inside ObOpenObject…

Just a word of warning, what you’re proposing does work, but you need
to be careful.

BTW, I found a different solution to my problem (open another
handle to
a key whose full path I don’t have): ZwOpenKey() with the existing
handle as the parent, and an empty string as the relative path.

Of course, I wasn’t trying to get a handle in a different
process context.
For that, you would need an intermediary object.



Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: david c. steere [mailto:xxxxx@cse.ogi.edu]
Sent: Friday, April 28, 2000 11:27 AM
To: File Systems Developers
Subject: [ntfsd] Re: virtual address mapping across processes

Ahh, Nagar++. You can call ObReferenceObjectByHandle() to get
a pointer to
the object for which you have a handle, and
ObOpenObjectByPointer() to get a
handle from the pointer. These increment a count on the
object, so remember
to call ObDereferenceObject() enough times to get that count
back to zero.

One small issue: ObOpenObjectByPointer is not documented in
the DDK. How
safe is it to use undocumented functions? Is there a way to
test for the
existence of a function short of using it? Anyone here been burned by
changes to undocumented functions?

thanks,

david

At 10:27 PM 4/27/00 -0700, you wrote:
>Is there a way to map handles across address spaces as well?
In particular,
I’m interested in handles produced by ZwCreateFile().
>
>david
>
>At 01:37 PM 4/16/00 +0400, you wrote:
> > > Hello there,
> > > I wish to create a virtual address in a process for
> > > an address coming in from another process, any suggestions???
> >
> >MmMapLockedPages(…UserMode…)
> >Don’t forget to unmap it on process termination.
> >
> > Max
> >
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
> >To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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


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

While I haven’t been burned by changes to undocumented functions, I have
been burned by changes to documented functions. Why does it matter?

-----Original Message-----
From: david c. steere [mailto:xxxxx@cse.ogi.edu]
Sent: Friday, April 28, 2000 1:27 PM
To: File Systems Developers
Subject: [ntfsd] Re: virtual address mapping across processes

Ahh, Nagar++. You can call ObReferenceObjectByHandle() to get
a pointer to the object for which you have a handle, and
ObOpenObjectByPointer() to get a handle from the pointer.
These increment a count on the object, so remember to call
ObDereferenceObject() enough times to get that count back to zero.

One small issue: ObOpenObjectByPointer is not documented in
the DDK. How safe is it to use undocumented functions? Is
there a way to test for the existence of a function short of
using it? Anyone here been burned by changes to undocumented
functions?

thanks,

david

At 10:27 PM 4/27/00 -0700, you wrote:
>Is there a way to map handles across address spaces as well?
In particular, I’m interested in handles produced by ZwCreateFile().
>
>david
>
>At 01:37 PM 4/16/00 +0400, you wrote:
> > > Hello there,
> > > I wish to create a virtual address in a process for
> > > an address coming in from another process, any suggestions???
> >
> >MmMapLockedPages(…UserMode…)
> >Don’t forget to unmap it on process termination.
> >
> > Max
> >
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
> >To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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

Can you tell me which documented function have burned you?

Btw. ObOpenObjectByPointer has its header in NTIFS.H. I think it is enough
for it to
be considered as documented.

-----P?vodn? zpr?va-----
Od: Rob Fuller [SMTP:xxxxx@NSISW.COM]
Odesl?no: 1. kv?tna 2000 16:33
Komu: File Systems Developers
P?edm?t: [ntfsd] Re: virtual address mapping across processes

While I haven’t been burned by changes to undocumented functions, I have
been burned by changes to documented functions. Why does it matter?

> One small issue: ObOpenObjectByPointer is not documented in
> the DDK. How safe is it to use undocumented functions? Is
> there a way to test for the existence of a function short of
> using it? Anyone here been burned by changes to undocumented
> functions?
>

I think this is not because of breaking the locking hierarchy. This can be
possible only
if the object type has registered OB_OPEN_METHOD. None of standard object
types
(with except of Desktop) has it registered.

Btw. Handle duplication should be done by Nt(Zw)DuplicateObject if possible.
One only
disadvantage is you must have handle to at least one process (in most cases
one can be
NtCurrentProcess()). This can be obtained by ObOpenObjectByPointer.

Thus there are potentially two solutins:

    • use ObOpenObjectByPointer to open handle to source(destination) process
  • use NtDuplicateObject to duplicate desired handle
  • use NtClose to close handle to source(destination) process
    • use KeAttachProcess to attach to source process
  • use ObReferenceObjectByHandle to reference desired object
  • use KeDetachProcess to detach from source process
  • use ObOpenObjectByPointer to get new handle to desired object
  • use ObDereferenceObject to dereference desired object

By looking to this scheme I think the first method should be prefered.
(If you look into NtDuplicateObject you’ll find some form of generalized
second method)

-----P?vodn? zpr?va-----
Od: Rob Fuller [SMTP:xxxxx@NSISW.COM]
Odesl?no: 1. kv?tna 2000 16:30
Komu: File Systems Developers
P?edm?t: [ntfsd] Re: virtual address mapping across processes

I saw an anomaly like this with file objects. Perhaps its an internal
executive deadlock, possibly an inverted locking order between two tightly
bound subsystems, such as the object manager and the process structure?

>
> I used ObReferenceObjectByHandle() & ObOpenObjectByPointer()
> to duplicate
> registry handles once. It generally worked, but led to a
> rare deadlock.
> I’m hard-pressed to remember the details, but it had to do with what
> appeared to be a global ERESOURCE for serializing access to
> the registry.
> Somehow, some thread that already had the lock ended up waiting on my
> thread (ours is a storage driver) which was blocked trying to get the
> lock inside ObOpenObject…
>
> Just a word of warning, what you’re proposing does work, but you need
> to be careful.
>
> BTW, I found a different solution to my problem (open another
> handle to
> a key whose full path I don’t have): ZwOpenKey() with the existing
> handle as the parent, and an empty string as the relative path.
>
> Of course, I wasn’t trying to get a handle in a different
> process context.
> For that, you would need an intermediary object.
>

It seems to me that your option 2 (below) is more general than what I want. If the object is in kernel memory space, the pointer to it should be valid for any kernel thread and you shouldn’t have to do the KeAttachProcess()… Note that I haven’t tried it yet so I don’t know if it works.

Also (excuse the blantant naivete of this question), I don’t see NtDuplicateObject listed in the DDK and given its name it appears to be a system call. Is it only available to the user level?

david.

At 05:41 PM 5/1/00 +0200, Pavel Hrdina wrote:

I think this is not because of breaking the locking hierarchy. This can be
possible only
if the object type has registered OB_OPEN_METHOD. None of standard object
types
(with except of Desktop) has it registered.

Btw. Handle duplication should be done by Nt(Zw)DuplicateObject if possible.
One only
disadvantage is you must have handle to at least one process (in most cases
one can be
NtCurrentProcess()). This can be obtained by ObOpenObjectByPointer.

Thus there are potentially two solutins:

    • use ObOpenObjectByPointer to open handle to source(destination) process
  • use NtDuplicateObject to duplicate desired handle
  • use NtClose to close handle to source(destination) process
    • use KeAttachProcess to attach to source process
  • use ObReferenceObjectByHandle to reference desired object
  • use KeDetachProcess to detach from source process
  • use ObOpenObjectByPointer to get new handle to desired object
  • use ObDereferenceObject to dereference desired object

By looking to this scheme I think the first method should be prefered.
(If you look into NtDuplicateObject you’ll find some form of generalized
second method)

> -----P?vodn? zpr?va-----
> Od: Rob Fuller [SMTP:xxxxx@NSISW.COM]
> Odesl?no: 1. kv?tna 2000 16:30
> Komu: File Systems Developers
> P?edm?t: [ntfsd] Re: virtual address mapping across processes
>
> I saw an anomaly like this with file objects. Perhaps its an internal
> executive deadlock, possibly an inverted locking order between two tightly
> bound subsystems, such as the object manager and the process structure?
>
> >
> > I used ObReferenceObjectByHandle() & ObOpenObjectByPointer()
> > to duplicate
> > registry handles once. It generally worked, but led to a
> > rare deadlock.
> > I’m hard-pressed to remember the details, but it had to do with what
> > appeared to be a global ERESOURCE for serializing access to
> > the registry.
> > Somehow, some thread that already had the lock ended up waiting on my
> > thread (ours is a storage driver) which was blocked trying to get the
> > lock inside ObOpenObject…
> >
> > Just a word of warning, what you’re proposing does work, but you need
> > to be careful.
> >
> > BTW, I found a different solution to my problem (open another
> > handle to
> > a key whose full path I don’t have): ZwOpenKey() with the existing
> > handle as the parent, and an empty string as the relative path.
> >
> > Of course, I wasn’t trying to get a handle in a different
> > process context.
> > For that, you would need an intermediary object.
> >
>


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

NtDuplicateObject is really system service. Prototype of this routine
(in fact of its Zw equivalent) is defined in NTIFS.H like this:

NTSYSAPI
NTSTATUS
NTAPI
ZwDuplicateObject(
IN HANDLE SourceProcessHandle,
IN HANDLE SourceHandle,
IN HANDLE TargetProcessHandle OPTIONAL,
OUT PHANDLE TargetHandle OPTIONAL,
IN ACCESS_MASK DesiredAccess,
IN ULONG HandleAttributes,
IN ULONG Options
);

All of Object Manager’s objects live in kernel memory space so pointer
to any object is valid in every process context. As I understand your
problem
you have to obtain object pointer once and then in every context you need
handle to it you must call ObOpenObjectByPointer. Is it right?

-----P?vodn? zpr?va-----
Od: david c. steere [SMTP:xxxxx@cse.ogi.edu]
Odesl?no: 1. kv?tna 2000 18:26
Komu: File Systems Developers
P?edm?t: [ntfsd] Re: virtual address mapping across processes

It seems to me that your option 2 (below) is more general than what I
want. If the object is in kernel memory space, the pointer to it should be
valid for any kernel thread and you shouldn’t have to do the
KeAttachProcess()… Note that I haven’t tried it yet so I don’t know if
it works.

Also (excuse the blantant naivete of this question), I don’t see
NtDuplicateObject listed in the DDK and given its name it appears to be a
system call. Is it only available to the user level?

david.

At 05:41 PM 5/1/00 +0200, Pavel Hrdina wrote:
>I think this is not because of breaking the locking hierarchy. This can
be
>possible only
>if the object type has registered OB_OPEN_METHOD. None of standard object
>types
>(with except of Desktop) has it registered.
>
>Btw. Handle duplication should be done by Nt(Zw)DuplicateObject if
possible.
>One only
>disadvantage is you must have handle to at least one process (in most
cases
>one can be
>NtCurrentProcess()). This can be obtained by ObOpenObjectByPointer.
>
>Thus there are potentially two solutins:
>
>1. - use ObOpenObjectByPointer to open handle to source(destination)
process
> - use NtDuplicateObject to duplicate desired handle
> - use NtClose to close handle to source(destination) process
>
>2. - use KeAttachProcess to attach to source process
> - use ObReferenceObjectByHandle to reference desired object
> - use KeDetachProcess to detach from source process
> - use ObOpenObjectByPointer to get new handle to desired object
> - use ObDereferenceObject to dereference desired object
>
>By looking to this scheme I think the first method should be prefered.
>(If you look into NtDuplicateObject you’ll find some form of generalized
>second method)
>
> > -----Puvodn? zpr?va-----
> > Od: Rob Fuller [SMTP:xxxxx@NSISW.COM]
> > Odesl?no: 1. kvitna 2000 16:30
> > Komu: File Systems Developers
> > Poedmit: [ntfsd] Re: virtual address mapping across processes
> >
> > I saw an anomaly like this with file objects. Perhaps its an internal
> > executive deadlock, possibly an inverted locking order between two
tightly
> > bound subsystems, such as the object manager and the process
structure?
> >
> > >
> > > I used ObReferenceObjectByHandle() & ObOpenObjectByPointer()
> > > to duplicate
> > > registry handles once. It generally worked, but led to a
> > > rare deadlock.
> > > I’m hard-pressed to remember the details, but it had to do with what
> > > appeared to be a global ERESOURCE for serializing access to
> > > the registry.
> > > Somehow, some thread that already had the lock ended up waiting on
my
> > > thread (ours is a storage driver) which was blocked trying to get
the
> > > lock inside ObOpenObject…
> > >
> > > Just a word of warning, what you’re proposing does work, but you
need
> > > to be careful.
> > >
> > > BTW, I found a different solution to my problem (open another
> > > handle to
> > > a key whose full path I don’t have): ZwOpenKey() with the existing
> > > handle as the parent, and an empty string as the relative path.
> > >
> > > Of course, I wasn’t trying to get a handle in a different
> > > process context.
> > > For that, you would need an intermediary object.
> > >
> >
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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

That’s correct. Thanks for the description of ZwDuplicateObject. Sorry for being a bonehead, I keep forgetting to look in ntifs.h.

david

At 06:43 PM 5/1/00 +0200, you wrote:

NtDuplicateObject is really system service. Prototype of this routine
(in fact of its Zw equivalent) is defined in NTIFS.H like this:

NTSYSAPI
NTSTATUS
NTAPI
ZwDuplicateObject(
IN HANDLE SourceProcessHandle,
IN HANDLE SourceHandle,
IN HANDLE TargetProcessHandle OPTIONAL,
OUT PHANDLE TargetHandle OPTIONAL,
IN ACCESS_MASK DesiredAccess,
IN ULONG HandleAttributes,
IN ULONG Options
);

All of Object Manager’s objects live in kernel memory space so pointer
to any object is valid in every process context. As I understand your
problem
you have to obtain object pointer once and then in every context you need
handle to it you must call ObOpenObjectByPointer. Is it right?

> -----P?vodn? zpr?va-----
> Od: david c. steere [SMTP:xxxxx@cse.ogi.edu]
> Odesl?no: 1. kv?tna 2000 18:26
> Komu: File Systems Developers
> P?edm?t: [ntfsd] Re: virtual address mapping across processes
>
> It seems to me that your option 2 (below) is more general than what I
> want. If the object is in kernel memory space, the pointer to it should be
> valid for any kernel thread and you shouldn’t have to do the
> KeAttachProcess()… Note that I haven’t tried it yet so I don’t know if
> it works.
>
> Also (excuse the blantant naivete of this question), I don’t see
> NtDuplicateObject listed in the DDK and given its name it appears to be a
> system call. Is it only available to the user level?
>
> david.
>
> At 05:41 PM 5/1/00 +0200, Pavel Hrdina wrote:
> >I think this is not because of breaking the locking hierarchy. This can
> be
> >possible only
> >if the object type has registered OB_OPEN_METHOD. None of standard object
> >types
> >(with except of Desktop) has it registered.
> >
> >Btw. Handle duplication should be done by Nt(Zw)DuplicateObject if
> possible.
> >One only
> >disadvantage is you must have handle to at least one process (in most
> cases
> >one can be
> >NtCurrentProcess()). This can be obtained by ObOpenObjectByPointer.
> >
> >Thus there are potentially two solutins:
> >
> >1. - use ObOpenObjectByPointer to open handle to source(destination)
> process
> > - use NtDuplicateObject to duplicate desired handle
> > - use NtClose to close handle to source(destination) process
> >
> >2. - use KeAttachProcess to attach to source process
> > - use ObReferenceObjectByHandle to reference desired object
> > - use KeDetachProcess to detach from source process
> > - use ObOpenObjectByPointer to get new handle to desired object
> > - use ObDereferenceObject to dereference desired object
> >
> >By looking to this scheme I think the first method should be prefered.
> >(If you look into NtDuplicateObject you’ll find some form of generalized
> >second method)
> >
> > > -----Puvodn? zpr?va-----
> > > Od: Rob Fuller [SMTP:xxxxx@NSISW.COM]
> > > Odesl?no: 1. kvitna 2000 16:30
> > > Komu: File Systems Developers
> > > Poedmit: [ntfsd] Re: virtual address mapping across processes
> > >
> > > I saw an anomaly like this with file objects. Perhaps its an internal
> > > executive deadlock, possibly an inverted locking order between two
> tightly
> > > bound subsystems, such as the object manager and the process
> structure?
> > >
> > > >
> > > > I used ObReferenceObjectByHandle() & ObOpenObjectByPointer()
> > > > to duplicate
> > > > registry handles once. It generally worked, but led to a
> > > > rare deadlock.
> > > > I’m hard-pressed to remember the details, but it had to do with what
> > > > appeared to be a global ERESOURCE for serializing access to
> > > > the registry.
> > > > Somehow, some thread that already had the lock ended up waiting on
> my
> > > > thread (ours is a storage driver) which was blocked trying to get
> the
> > > > lock inside ObOpenObject…
> > > >
> > > > Just a word of warning, what you’re proposing does work, but you
> need
> > > > to be careful.
> > > >
> > > > BTW, I found a different solution to my problem (open another
> > > > handle to
> > > > a key whose full path I don’t have): ZwOpenKey() with the existing
> > > > handle as the parent, and an empty string as the relative path.
> > > >
> > > > Of course, I wasn’t trying to get a handle in a different
> > > > process context.
> > > > For that, you would need an intermediary object.
> > > >
> > >
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@cse.ogi.edu
> >To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)


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

User-mode DuplicateHandle.

----- Original Message -----
From: david c. steere
To: File Systems Developers
Sent: Friday, April 28, 2000 9:27 AM
Subject: [ntfsd] Re: virtual address mapping across processes

> Is there a way to map handles across address spaces as well? In
particular, I’m interested in handles produced by ZwCreateFile().

Max

> One small issue: ObOpenObjectByPointer is not documented in the DDK.

How safe is it to use undocumented functions? Is there a way to test for
the
existence of a function short of using it? Anyone here been burned by
changes to undocumented functions?

Why not?
I used the similar function ObReferenceObjectByName - and also
undocumented ZwLoadDriver - to implement LoadLibrary in kernel.

Max