Windows User Mode Process Creation (Windows Subsystem) Part-1

I am on a discovery to understand how Windows internals works.

As part of this series, I will explore and document my research on process creation, thread creation & scheduling, security, memory management (Heap, Stack, Virtual Address space, page, Address translation, Cache files, etc.), etc.

This is my first document as part of the Windows internal exploration series. I will present my findings on Windows User Process creation, a complex operation. Windows Creation Process goes through different stages like parameter validation, access token, open image, architecture, memory allocation, thread creation, security checks, etc.

Therefore, it seems unrealistic to create one long document. So, I decided to divide my research into small understandable blocks instead of a gigantic paper :)

Windows User Process Creation

This document covers the Windows process creation initialization from the Windows Subsystem DLLs till control transitions to Windows Kernel mode.

Windows Process Creation Most work involves the Windows Subsystem DLLs, Windows Executive, and Windows Subsystem Process (CSRSS).

CSRSS stands for Client/Server Runtime Subsystem

Suppose I need to draw a big picture (with my current understanding). In that case, it should be like this where the creation process starts from Windows Subsystem (Windows User Mode) and transition to Windows Executive (Windows Kernel Mode) through NTDLL Library (middle layer to support Windows subsystem).

Windows User Process Creation

Here is some more detail about each of the above diagram components.

Windows Subsystems DLLs: User applications do not directly call Windows internals. Instead, they use the Windows Subsystem DLLs (Kernel32.dll, Advapi32.dll, User32.dll, and Gdi32.dll), and Subsystem DLLs translate the functions into proper Windows internals.

Windows Subsystem DLLs initiate the user mode process creation.

NTDLL.DLL: This Windows system library is independent of Windows Subsystem DLLs and works as a bridge(except for Windows USER, GDI, or DirectX APIs) between Subsystem DLLs and Windows Kernel. This library transitions from user mode to kernel mode service by calling the system service dispatcher.

System Service Dispatching

NTDLL is the user-mode face of the Windows kernel…

Windows Executive: This is the Kernel side of Windows, and Executive is usedto create the Process Structure, Process Memory, Section Object Mapping, Thread creation, etc.

Windows Subsystem Process (CSRSS): CSRSS maintains each window program run’s parallel structure (CSR_PROCESS). (I created this process in a diagram but have not linked it because I need to explore this area more yet)

Bottom line…

Windows Subsystem DLLs initiate the user process creation, and I’m using the Kernal32.dll subsystem DLL to understand the control flow.

Let’s explore the theory… :)

Experience without theory is blind, but theory without experience is mere intellectual play — Immanuel Kant

To understand the control flow, I downloaded the Windows debugger.

Afterward, I used the cmd.exe to create the notepad.exe process and added a breakpoint on CreateProcessInternal to see the call stack….

Windows Debugger (Disassembly…)

W at the end of the function name stands for wide (Unicode)

Windows Debugger (Call Stack)

I used the Windows Process Monitor to capture the transition between User-Mode(NtCreateUserProcess) to Kernel mode world.

Windows Process Monitor (Call Stack)

…and now the diagram looks like this.

CreateProcessInternelW function performs the necessary steps to gather information required to create a new process before making a call to NtCreateUserProcess(NTDLL) function.

Here are some of them I tried to gather by consulting different references.

• Windows Application name to be executed.
• Validate Command Line Arguments.
• Verify the Security Access token and use the default if not NULL.
• Creational Flags, E.g.
• DEBUG_PROCESS (if specified, the routine will create the debug gee process).
• NORMAL_PRIORITY_CLASS (used to assign the priority to the new thread…if not supplied, the function gives the Normal priority to process).
• Find the Current directory path if NULL, use the same directory as the calling process.
• Every Windows application should have a valid desktop instance(STARTUPINFO); the function attached the current caller desktop to the process if not supplied.

I will hold off at this point; in the next post, I will try to dig into NTDLL(…middle layer) and beyond… :)