Open Handle in one Process and Close in another?
in [Win32 Kernel]
|
Prev: Disable file system cache for a certain file
Next: Volume Shadow Copy Service error: Unexpected error calling routineCoCreateInstance. hr = 0x800401f0
From: Pavel A. on 26 Feb 2010 09:38 "David F." <df2705(a)community.nospam> wrote in message news:B6984F33-F6DE-4283-B036-CACC6767EBCE(a)microsoft.com... >.......... 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? 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
From: David F. on 26 Feb 2010 11:58 "Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message news:DE798563-7818-4463-93EF-E08203B4609B(a)microsoft.com... > "David F." <df2705(a)community.nospam> wrote in message > news:B6984F33-F6DE-4283-B036-CACC6767EBCE(a)microsoft.com... >>.......... 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? > > 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 > 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.
From: Jonathan de Boyne Pollard on 26 Feb 2010 18:02 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <blockquote cite="mid:A954CF83-3185-4207-BDD2-BA153C4FD2CB(a)microsoft.com" type="cite"> <p>maybe it was just windows handles or for older windows versions?</p> </blockquote> <p>No. Remember that I pointed you to the MSDN Library discussion of kernel objects? You asked in the <code>microsoft.public.win32.programmer.<em>kernel</em></code> newsgroup, and answers relevant to <em>kernel object</em> handles are what you are receiving from people posting there. Other types of objects are user and GDI objects (for which there are <a href="news:///microsoft.public.win32.programmer.gdi">other</a> <a href="news:///microsoft.public.win32.programmer.ui">newsgroups</a>). 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 <a href="http://techinterviews.com./windows-programming-interview-questions">this</a> (to pick one WWW page at random).</p> </body> </html>
From: m on 27 Feb 2010 14:29
This excerpt is discussing the behaviour of GDI to ensure interoperability 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." <df2705(a)community.nospam> wrote in message news:E0195B4A-D9EE-4469-99A3-21406785E111(a)microsoft.com... > I guess it depends on the type of 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." > > From http://msdn.microsoft.com/en-us/library/aa384203(VS.85).aspx > > > "Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups(a)NTLWorld.COM> > wrote in message > > news:IU.D20100226.T083821.P9445.Q0(a)J.de.Boyne.Pollard.localhost... > 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. |