What is a kernel object?

What is a kernel object?

As a wi n d o w s software developer, you often need to create, open, and operate various kernel objects. The system creates and operates on several types of kernel objects, such as access symbol object, event object, file object, file ing object, I/O completed port object, job object, mailbox object, mutex object, pipeline object, process object, Beacon object, thread object and wait time object. These objects are created by calling functions. For example, the C r e a t e f I l e m a p I n g function enables the system to create a file ing object. Each core object is only a memory block allocated by the kernel and can only be accessed by the kernel. The memory block is a data structure, and its members are responsible for maintaining various information about the object. Some data members (such as security descriptors and counts) are the same in all object types, but most data members belong to specific object types. For example, a process object has a process I D, a base priority, and an exit code, while a file object has a byte displacement, a sharing mode, and an open mode.

Because the data structure of the kernel object can only be accessed by the kernel, the application cannot find the data structure in the memory and change its content directly. M I c r o s o f t specifies this restriction condition to ensure that the kernel object structure remains consistent. This restriction also enables m I c r o s o f t to add, delete, and modify data members in these structures without disrupting any applications.

If we cannot directly change these data structures, how can our applications operate these kernel objects? The solution is that wi n d o w s provides a set of functions to operate these structures in a well-defined way. These kernel objects can always be accessed through these functions. When a function is called to create a kernel object, the function returns a handle to identify the object. This handle can be regarded as an opaque value, which can be used by any thread in your process. Pass this handle to the number of different functions of Wi n d o w s, so that the system can know which kernel object you want to operate. The features of these handles will be detailed later in this chapter.

To make the operating system more robust, these handle values are closely related to processes. Therefore, if you pass the handle value to a thread in another process (using some form of inter-process communication) then the call made by another process using the handle value of your process will fail. In section 3 "Sharing kernel objects across process boundaries", we will introduce three mechanisms so that multiple processes can successfully share a single kernel object.

Kernel Object usage count

The kernel object is owned by the kernel, not by the process. In other words, if your process calls a function to create a kernel object and then your process stops running, then the kernel object may not be undone. In most cases, the object will be revoked, but if another process is using the kernel object created by your process, the kernel knows that, do not undo this object before another process stops using this object. Remember that the existence time of the kernel object can be longer than that of the process that created this object.

The kernel knows how many processes are using a certain kernel object because each object contains a usage count. Counting is a common data member of all kernel object types. When an object is just created, its usage count is set to 1. Then, when another process accesses an existing kernel object, the Count increases by 1. When a process stops running, the kernel automatically determines the use count of all kernel objects that the process is still open. If the usage count of the kernel object is reduced to 0, the kernel will undo the object. This ensures that no kernel object is retained in the system when no process references this object.