Why do Windows applications enter the kernel through stubs in ntdll.dll instead of issuing the syscall instruction themselves, and what does that imply about Windows system call numbers?

## The native API and the subsystem above it Windows NT was built with two API layers by design. The **native API** is the set of `Nt*` routines the kernel actually implements — `NtCreateFile`, `NtOpenProcess`, `NtQueryInformationProcess` and several hundred more. Above it were meant to sit several **environment subsystems**, each presenting a different personality to applications: Win32, OS/2 and POSIX all shipped in early NT. Win32 is the one that survived and became synonymous with Windows, but the architecture beneath it never collapsed. That history explains the call chain. `CreateFileW` in `kernel32.dll`/`kernelbase.dll` is a Win32 personality function: it parses a DOS path, applies Win32 flag semantics and defaults, builds an `OBJECT_ATTRIBUTES` structure, and calls `NtCreateFile` in `ntdll.dll`. Only the `ntdll.dll` stub touches the CPU's mode-switch instruction. ## What the stub does A stub is a handful of instructions: move a **system service number** into `EAX`, put the argument pointer where the kernel expects it, execute `syscall` (on x64; older 32-bit builds used `sysenter` or `int 2Eh`), return. On the kernel side the dispatcher uses that number as an index into the system service descriptor table, which yields the kernel routine's address and its argument count, then copies and validates arguments before calling it. The number is *not* part of any published contract. It is generated per build from the ordering of entries in the table, so inserting one new service can shift everything after it. ``` ; conceptual shape of an ntdll.dll x64 stub mov r10, rcx ; syscall clobbers rcx, so the first argument is preserved mov eax, <service #> ; index into the system service table for THIS build syscall ret ``` ## Nt versus Zw `ntdll.dll` exports both `NtCreateFile` and `ZwCreateFile`, and in user mode they are the same stub. The distinction is meaningful inside the kernel, where `ntoskrnl.exe` also exports both: the `Zw` form sets the *previous mode* to `KernelMode`, telling the service its caller is trusted, so buffer addresses are not validated as user pointers and access checks may be skipped; the `Nt` form leaves the previous mode as it is. That is why kernel-mode drivers are told to call the `Zw` variants when acting on their own behalf, and why a driver that carelessly calls a `Zw` routine on a pointer that came from user mode has just created a privilege-escalation bug. ## Why the indirection is worth the layer Three things fall out of putting the boundary in a DLL: 1. **Freedom to evolve the kernel.** Services can be split, merged, renumbered or removed between releases because the only thing that must stay in step is the `ntdll.dll` shipped with the same kernel. Microsoft has used that freedom for decades. 2. **A place to put user-mode work.** `ntdll.dll` also holds the loader, the heap, thread startup and exception dispatch — plenty of work that need not run in kernel mode happens there, which keeps the kernel smaller. 3. **A single, patchable chokepoint.** Compatibility shims and instrumentation can be applied at the DLL boundary without kernel changes. ## What breaks when you route around it Because the stubs are trivially regenerable, some software builds its own: it reads service numbers out of the on-disk `ntdll.dll`, or sorts the exported `Nt*` addresses to infer them, and issues `syscall` directly. Endpoint security products hook the in-memory `ntdll.dll` stubs to observe native calls, so "direct syscall" and "stub unhooking" techniques exist specifically to evade that monitoring. The defensive answer is not to hook harder in user mode but to observe from a place user-mode code cannot skip — kernel callbacks and kernel event-tracing providers. For ordinary engineering the rule is blunt: call the documented Win32 API; reach for native `Nt*` exports only when Win32 genuinely cannot express what you need, and then only through `ntdll.dll`'s exported names; never bake a service number into a binary. A build that ships hardcoded numbers works on the machine it was tested on and fails, often catastrophically and with no useful error, after the next feature update. ## The contrast an interviewer is fishing for On Linux the numeric syscall interface is itself a stability promise, so a statically linked binary trapping directly is supported practice. On Windows the promise lives one level up, in the DLLs. Both are coherent designs; the mistake is assuming Windows made the same promise and reasoning about `ntdll.dll` as though it were merely a convenience wrapper.