Windows Objects and Handles: How Windows Manages System Resources

Windows contains many different types of resources.

Processes, threads, files, registry keys, events, mutexes, devices, and other resources all need to be created, managed, and accessed.

Windows uses a fundamental concept to organize many of these resources:

Objects and handles.

Understanding them is essential for understanding how Windows programs interact with the operating system.

What Is a Windows Object?

A Windows object is a kernel-managed representation of a system resource or operating-system entity.

Examples include:

• Processes

• Threads

• Files

• Events

• Mutexes

• Semaphores

• Sections

• Tokens

• Jobs

• Registry keys

A simplified view is:

Windows Object
│
├── Type
├── Name (if applicable)
├── Security Information
├── Reference Information
└── Object-Specific Data

Different object types contain different information.

Why Does Windows Use Objects?

Windows uses objects to provide a consistent way for applications and system components to interact with many operating-system resources.

Instead of every resource having a completely different management model, many resources follow the Windows object model.

For example:

Application
    ↓
Windows API
    ↓
Object Manager
    ↓
Kernel Object

This creates a structured interface between applications and the operating system.

What Is a Handle?

A handle is a value that a process uses to refer to an operating-system object.

You can think of a handle as a reference or access token provided by Windows for interacting with an object.

For example:

Process
│
└── Handle Table
       │
       ├── Handle 0x50 → File Object
       ├── Handle 0x64 → Process Object
       └── Handle 0x78 → Event Object

The handle value itself is not simply the object's memory address.

Windows uses the handle to look up the corresponding object and enforce the appropriate access rights.

Handle Tables

Each process has a handle table used to keep track of many of the kernel objects that the process has opened or created.

Conceptually:

Process
     ↓
Handle Table
     ↓
┌───────────────┐
│ Handle → Object│
├───────────────┤
│ Handle → Object│
├───────────────┤
│ Handle → Object│
└───────────────┘

This allows a process to work with many different operating-system resources.

Example: Opening a File

Suppose an application wants to access a file.

Conceptually:

Application
     ↓
CreateFile / Open
     ↓
Windows
     ↓
File Object
     ↓
Handle Returned

The application receives a handle.

It can then use that handle with other APIs to perform operations on the file.

Example: Creating a Process

Windows APIs can also return handles to processes.

Conceptually:

Create Process
      ↓
Process Object
      ↓
Process Handle

The application can then use the handle to interact with that process according to the permissions associated with it.

Handles Have Access Rights

A handle isn't necessarily unlimited access.

When a handle is created or opened, Windows can associate specific access rights with it.

For example, a process handle might allow some operations but not others.

Conceptually:

Handle
│
├── Query Information ✓
├── Read Memory ✓
├── Write Memory ✗
└── Terminate ✗

The actual rights depend on the object type and how the handle was obtained.

This is an important part of Windows security.

Closing Handles

Handles consume operating-system resources.

When a program is finished using a handle, it should close it.

For many Windows objects, applications use:

CloseHandle()

Conceptually:

Open Object
     ↓
Use Handle
     ↓
CloseHandle()
     ↓
Handle Released

If software repeatedly creates handles without closing them, it can cause a handle leak.

Object Lifetime

Windows needs to know when an object is no longer being used.

Objects can have references associated with them.

Conceptually:

Process A → Handle ──┐
                     ↓
                  Object
                     ↑
Process B → Handle ──┘

As long as references to an object remain, Windows can keep the object alive.

When it is no longer referenced, the operating system can eventually clean it up.

The exact object-lifetime rules are more sophisticated than this simplified model.

The Windows Object Manager

The Object Manager is a Windows Executive component responsible for managing many types of objects.

It helps handle things such as:

• Object creation

• Object naming

• Object lookup

• Object lifetime

• Security checks

• References to objects

A simplified architecture is:

Application
    ↓
Windows APIs
    ↓
Object Manager
    ↓
Kernel Objects

Named Objects

Some Windows objects can have names.

For example, synchronization objects such as events and mutexes can be named.

This allows different processes to refer to the same object.

Process A
   ↓
"SharedEvent"
   ↑
Process B

Both processes can potentially access the same named object if they have appropriate permissions.

Object Namespaces

Windows maintains namespaces for objects.

Some objects can be referenced through paths in the Windows Object Manager namespace.

Tools such as WinObj can expose parts of this namespace.

For example:

\Device
\Driver
\BaseNamedObjects

These are examples of namespaces or directories used by Windows internally.

The object namespace is deeper and more complex than the normal filesystem namespace.

Object Types

Windows maintains different object types.

Examples include:

• Process

• Thread

• File

• Event

• Mutex

• Section

• Job

• Token

• Key

Each object type has its own behavior and associated operations.

Conceptually:

Object Manager
│
├── Process Objects
├── Thread Objects
├── File Objects
├── Event Objects
├── Token Objects
└── Job Objects

Objects, Handles, and Security

Objects and handles are closely connected to Windows security.

When a process requests access to an object, Windows can perform an access check.

A simplified flow is:

Process
   ↓
Request Object
   ↓
Security Check
   ↓
Handle Created
   ↓
Allowed Access

This helps prevent processes from accessing resources without appropriate permissions.

Kernel Handles

Some handles are associated with kernel-mode contexts rather than ordinary user-mode processes.

Kernel-mode components can use handles when interacting with objects, although kernel code also has additional ways to work with object references.

This distinction becomes important when studying Windows kernel internals.

Objects and Malware Analysis

Objects and handles are extremely useful during malware investigations.

An analyst might examine:

• Which processes a suspicious program has handles to

• Which files it opened

• Which registry keys it accessed

• Which events or mutexes it created

• Which processes it can interact with

• Which security tokens it uses

For example:

Suspicious Process
       ↓
Handle Table
       │
       ├── File
       ├── Registry Key
       ├── Process
       ├── Thread
       └── Event

This can reveal relationships that aren't obvious from the process name alone.

Why Malware Analysts Care About Handles

Handles can provide clues about what a program is doing.

For example, a suspicious process opening another process with powerful access rights may deserve further investigation.

However, a handle by itself does not prove malicious activity.

Legitimate software often needs access to other processes, files, devices, and synchronization objects.

Context is essential.

Useful Tools

Process Explorer

Can display handles associated with processes.

Process Hacker

Provides detailed process and handle information.

WinObj

A Sysinternals utility that allows researchers to explore the Windows Object Manager namespace.

WinDbg

Provides deeper debugging and kernel-level investigation capabilities.

Objects vs Handles

This distinction is extremely important:

Object = the kernel-managed resource.

Handle = a process's reference used to access that object.

For example:

File Object
     ↑
     │
Handle 0x50
     ↑
Process

The handle is how the process refers to the object.

It is not the object itself.

A Simple Analogy

Imagine a hotel.

The room is the object.

The key card is the handle.

Key Card
   ↓
Hotel Room

The key card doesn't contain the room.

It provides authorized access to it.

Similarly, a Windows handle provides a process with access to a kernel object.

Final Thoughts

Windows Objects and Handles form a fundamental part of the operating system's architecture.

Remember:

Objects represent resources managed by Windows.

Handles provide processes with access to those objects.

Handle tables track many handles owned by a process.

Access rights determine what operations a handle can perform.

Once you understand objects and handles, many Windows concepts become easier to connect—including processes, threads, files, events, jobs, tokens, and registry objects.

In the next article, we'll explore the Windows Registry and understand how Windows stores configuration information and system settings.