Open Handle in one Process and Close in another?
David F.
Hi,
So everything I've read seems to suggest that Handles are global in Windows
space and even between x64 and x32 processes. One thing I haven't seen
addressed is if opening a handle in one process and then closing in another
is allowed or does that create a potential for double closing the handle? I
mean the process that opened the handle would automatically close any open
handles, but would it know that the handle was closed? If not, I guess if
one wanted to transparently use a handle as it would itself one would
duplicate the handle from the other process and use then close the
duplicated handle and let the other process close the handle it opened. Or
pass something other than a handle to a process and open that within the
process where it will be used.
?
TIA!!
Don Burn
Handles are unique to processes, there is nothing global about them.
When the process that opens the handle terminates they get closed.
Passing a handle to another process will just cause it to get an invalid
handle or if you are really unlucky the wrong handle. If you want to
pass a handle look at the DuplicateHandle function, but this is creating
a new handle.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
"David F." <df2...@community.nospam> wrote in message
news:B6984F33-F6DE-4283...@microsoft.com:
__________ Information from ESET Smart Security, version of virus
signature database 4896 (20100225) __________
The message was checked by ESET Smart Security.
Jonathan de Boyne Pollard
So everything I've read seems to suggest that Handles are global in Windows space and even between x64 and x32 processes.
You haven't read nearly enough. Start with the MSDN Libary discussion of kernel objects.
David F.
"64-bit versions of Windows use 32-bit handles for interoperability. When
sharing a handle between 32-bit and 64-bit applications, only the lower 32
bits are significant, so it is safe to truncate the handle (when passing it
from 64-bit to 32-bit) or sign-extend the handle (when passing it from
32-bit to 64-bit). Handles that can be shared include handles to user
objects such as windows (HWND), handles to GDI objects such as pens and
brushes (HBRUSH and HPEN), and handles to named objects such as mutexes,
semaphores, and file handles."
From http://msdn.microsoft.com/en-us/library/aa384203(VS.85).aspx
"Jonathan de Boyne Pollard" <J.deBoynePoll...@NTLWorld.COM> wrote
in message
news:IU.D20100226.T...@J.de.Boyne.Pollard.localhost...
rogero
> I guess it depends on the type of handle:
It depends more on how it is created.
If you create a handle with inheritable attributes it is passed down
to the child process using the same handle value. However, each
process actually has its own handle to the same underlying kernel
object and each process must explicitly or implicitly close the handle
before the underlying object is released.
Simply passing the handle value to another process does not enable the
handle to be used by the other process -- in general this value may
even be a genuine handle in the target process but not to the same
object.
Example:
parentProcess.exe:
HANDLE h1 = OpenMutex(MUTEX_ALL_ACCESS, TRUE, "Global\\RogerOrr");
CreateProcess("childProcess.exe", ...)
childProcess.exe:
will be created with an already open handle to the mutex with the same
numeric value as h1.
siblingProcess:
HANDLE h2 = OpenMutex(MUTEX_ALL_ACCESS, TRUE, "Global\\RogerOrr");
h2 may or may not have the same numeric value as h1.
HTH,
Roger.
Pavel A.
>.......... One thing I haven't seen addressed is if opening a handle in one
>potential for double closing the handle?
What is the actual goal you need to achieve: sharing/locking a file between
two
or more processes? Detect if someone forcibly closes your handle?
There's a lot of weird perverse things that one could imagine,
but Windows API does not have "addressed".
Regards,
--pa
David F.
"Pavel A." <pav...@12fastmail34.fm> wrote in message
news:DE798563-7818-4463...@microsoft.com...
Needed a x32 app to support a COM interface only available in x64 on x64
(VSS) so a stub-app is created simply to create a handle to the volume
needed. First thought was to just pass the device name because it's in
global space. So looked up what was possible and also found something about
sharing a handle:
"64-bit versions of Windows use 32-bit handles for interoperability. When
sharing a handle between 32-bit and 64-bit applications, only the lower 32
bits are significant, so it is safe to truncate the handle (when passing it
from 64-bit to 32-bit) or sign-extend the handle (when passing it from
32-bit to 64-bit). Handles that can be shared include handles to user
objects such as windows (HWND), handles to GDI objects such as pens and
brushes (HBRUSH and HPEN), and handles to named objects such as mutexes,
semaphores, and file handles."
To me sharing doesn't mean just "inheriting", so googling found more
information about handles being global (maybe it was just windows handles or
for older windows versions?), so that left me the question, if the process
automatically closed a handle and I closed it in some other process, does
windows (in affect) tell each process the handle they created has been
closed so on termination it didn't try to close it again or would it cause a
problem.
But I guess that each handle is unique to a process and that quote above
deals with inheriting handles in child processes. In any case, I
implemented simply by passing the volume name in global space to open back
to the parent x32 app. Of course this whole episode could be provided if
the original interface just worked instead of having all kinds of
restrictions.
Jonathan de Boyne Pollard
maybe it was just windows handles or for older windows versions?
No. Remember that I pointed you to the MSDN Library discussion of
kernel objects? You asked in the microsoft.public.win32.programmer.kernel
newsgroup, and answers relevant to kernel object handles are
what you are receiving from people posting there. Other types of
objects are user and GDI objects (for which there are other newsgroups).
As I said, you need to read much more stuff, such as the remainder of
the "Handles and Objects" section of the MSDN Library that you've
already been pointed to, and this
(to pick one WWW page at random).
m
between 32-bit and 64-bit processes on the same desktop without Windows
acting as a proxy for the 32-bit applications. As you may know, GDI handles
(window handles / HWND, etc.) are not kernel object handles and are not
processes specific. They were once machine global, and are now desktop
specific for security reasons. The design goes back to cooperative
multi-tasking in Win16 and allows are the desktop level UI communication (ie
mouse clicks, keystrokes, clipboard etc.). Kernel object handles do not
reference UI elements, but objects maintained by the kernel like files,
threads, and events. These handles are process specific and act as
references to the underling kernel object. When a process terminates, the
OS will close any open handles that that process might have, allowing it to
cleanup any objects that might have been abandoned by a faulty application
(by contrast UI elements represented by GDI handles are cleaned up when the
owning thread terminates).
based on your other post, I assume that you are trying to pass a volume
handle. This is a kernel object handle and so you must either:
1) open a new handle to the same named object in the second process; or
2) use DuplicateHandle
in both cases, Windows handles 32 / 64 bit issues for you.
"David F." <df2...@community.nospam> wrote in message
news:E0195B4A-D9EE-4469...@microsoft.com...