This post kicks off a four-part series by u/_WinAsm dissecting one of the most fundamental — yet rarely explained — mechanisms in the Windows kernel: how the Object Manager creates kernel objects. Nearly every Windows primitive you've ever touched — files, processes, threads, mutexes, events, registry keys, sections — is a "kernel object" born through this exact code path. Yet most developers, even those writing drivers, treat ObCreateObject as an opaque black box.

Part 1 focuses on allocation and pre-initialization. The author walks through what actually happens between the moment a user-mode CreateFile or CreateMutex call enters the kernel and the moment the object body is handed off for type-specific initialization. Key topics covered across the series include:

• Object header layout — the OBJECT_HEADER structure that sits before every kernel object body, carrying reference counts, type info, and optional sub-headers (name info, handle info, quota info, creator info).
• Pool allocation — how the kernel computes the total size needed (header + optional sub-headers + body) and carves it out of paged or non-paged pool.
• Access checks (Part 2) — how the security reference monitor validates the caller's token against the object's DACL before the handle is granted.
• Name lookup and the object namespace (Part 3) — the directory tree at \??\, \Device\, \BaseNamedObjects\ and how named objects are inserted.
• Handle tables (Part 4) — the per-process three-level table that maps HANDLEs (those small integers you pass around in user mode) to the actual kernel object pointers, including the encoded access mask bits.

Why this matters: understanding the Object Manager is the prerequisite for everything interesting in Windows internals — rootkit detection, EDR hooking, handle hijacking attacks, privilege escalation via handle leaks, and even ordinary driver debugging. When you see a tool like Process Hacker enumerate handles, or a malware sample duplicate a SYSTEM token handle, this is the machinery underneath.

The series leans heavily on disassembly and the public ntoskrnl symbols, which makes it more rigorous than the typical "Windows Internals" textbook summary. If you've read Russinovich's book and wanted the next layer down, this is it.