Kernel object handles are process specific. That is, a process must either
create a kernel object or open an existing object to obtain an object handle. Any
process can create a new handle to an existing kernel object (even one created
by another process), provided that the process knows the name of the object and
has access to the object as defined by user security. For more information
about security, see Security
Processes can inherit or duplicate handles to the following types of kernel
- Files (including file-mapping objects)
- Pipes (named and anonymous)
- Communications devices
All other kernel objects are private to the process that created them; object
handles cannot be duplicated or inherited.
A child process inherits an open handle from its parent process if inheritance
was specified when the original handle was created and if the child process
was created with the "inherit handles" flag set. An inherited handle is valid
only in the context of the child process.
function duplicates a handle into the current process or into another
process. If an application duplicates one of its handles into another process, the
duplicated handle is valid only in the context of the other process.
A duplicated or inherited handle is a unique value, but it refers to the same
object as the original handle.
Kernel object handles include access rights that indicate the actions the
application wants to perform on the object. An application specifies access rights
when it creates an object or obtains an existing object handle. Each type of
kernel object supports its own set of access rights. For example, event handles
can have "set" or "wait" access (or both), file handles can have "read" or
"write" access (or both), and so on. For more information about access rights, see Security
, and topics that describe individual objects.
In the following illustration, an application creates an event object. The CreateEvent
function creates the event object and returns an object handle.
After the event object has been created, the application can use the event
handle to set or wait on the event. The handle remains valid until the application
closes the handle or terminates.
Most kernel objects support multiple handles to a single object. For example,
the application in the preceding illustration could obtain additional event
object handles by using the OpenEvent
function, as shown in the following illustration.
This method enables an application to have handles with different access
rights. For example, Handle 1 might have "set" and "wait" access to the event, and
Handle 2 might have only "wait" access.
If another process knows the event name and has security access to the object,
it can create its own event object handle by using OpenEvent
, as shown in the following illustration.
The original application could also duplicate one of its handles into the same
process or into another process by using the DuplicateHandle
function, as shown in the following illustration.
The following illustration shows how a child process inherits a handle created
by its parent process.
A child process of an application automatically inherits handles created by
its parent process if inheritance was specified when the handles were created and
if the child process was created with the "inherit handles" flag set. Note
that in the preceding illustration, Handle 2 is not equivalent to Handle 1 but
does refer to the same event object.
For more information about inheritance, see Processes and Threads
An object remains in memory as long as at least one object handle exists. In
the following illustration, the applications use the CloseHandle
function to close their event object handles. When there are no event
handles, the system removes the object from memory, as shown in the following
Occasionally, an object remains in memory after all object handles have been
closed. For example, a thread could create an event object and wait on the event
handle. While the thread is waiting, another thread could close the same event
object handle. The event object remains in memory, without any event object
handles, until the event object is set to the signaled state and the wait
operation is completed. At this time, the system removes the object from memory.
Windows manages file objects somewhat differently from other kernel objects.
File objects contain the file pointer
the pointer to the next byte to be read or written in a file. Whenever an
application creates a new file handle, the system creates a new file object.
Therefore, more than one file object can refer to a single file on disk, as shown in
the next illustration.
Only through duplication or inheritance can more than one file handle refer to
the same file object, as shown in the following illustration.
The following table lists each of the Windows kernel objects and each object's
creator and destructor functions. The creator functions either create the
object and an object handle or create a new existing object handle. The destructor
functions close the object handle. When an application closes the last handle
to a kernel object, the system removes the object from memory.
||CreateProcess, OpenProcess, GetCurrentProcess
||CreateThread, CreateRemoteThread, GetCurrentThread
||OpenEventLog, RegisterEventSource, OpenBackupEventLog
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages
- Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database