smss.exe – Session Manager subsystem – As the name suggests, this process is in charge of managing the session creation and logoff
Winlogon – “Winlogon handles interface functions that are independent of authentication policy. It creates the desktops for the window station, implements time-out operations, and provides a set of support functions for the GINA.” source: Microsoft MSDN
userinit.exe ( HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ): it specifies the programs that Winlogon runs when a user logs on. (https://technet.microsoft.com/en-us/library/cc939862.aspx)
mpnotify.exe ( C:\WINDOWS\system32\mpnotify.exe ): is responsible for loading network providers including the single sign on network provider (pnsson.dll) for the ICA client.
These are not the only processes invoked during logon process.
Windows Terminal Server Initialization
As the Windows Terminal Server boots and loads the core operating system, the Terminal Server service (Termsrv.exe) is started and creates listening stacks (one per protocol and transport pair) that listen for incoming connections. Each connection is given a unique session identifier or “SessionID” to represent an individual session to the Terminal Server. Each process created within a session is “tagged” with the associated SessionID to differentiate its namespace from any other connection’s namespace.
The console (Terminal Server keyboard, mouse, and video) session is always the first to load, and is treated as a special-case client connection and assigned SessionID. The console session starts as a normal Windows NT system session with the configured Windows NT display, mouse, and keyboard drivers loaded.
The Terminal Server service then calls the Windows NT Session Manager (Smss.exe) to create two (default = 2) idle client sessions (after creating the console session) that await client connections. To create the idle sessions, the Session Manager executes the Windows NT-based client/server runtime subsystem process (Csrss.exe), and a new SessionID is assigned to that process. The CSRSS process will also invoke the Winlogon (Winlogon.exe) process and the Win32k.sys (Window Manager and graphics device interface – GDI) kernel module under the newly associated SessionID. The modified Windows NT image loader will recognize this Win32k.sys as a SessionSpace-loadable image by a predefined bit set in the image header. It will then relocate the code portion of the image into physical memory, with pointers from the virtual kernel address space for that session, if Win32k.sys has not already been loaded. By design, it will always attach to a previously loaded image’s code (Win32k.sys) if one already exists in memory. For example, from any active application or session.
The data (or non-shared) section of this image will then be allocated to the new session from a newly created SessionSpace pageable kernel memory section. Unlike the console session, Terminal Server Client sessions are configured to load separate drivers for the display, keyboard, and mouse.
The new display driver is the Remote Desktop Protocol (RDP) display device Driver, Tsharedd.dll. The mouse and keyboard drivers communicate into the stack through the multiple instance stack manager, termdd.sys. Termdd.sys will send the messages for mouse and keyboard activity to and from the RDP driver, Wdtshare.sys. These drivers allow the RDP client session to be remotely available and interactive. Finally, Terminal Server will also invoke a connection listener thread for the RDP protocol, again managed by the multiple instance stack manager (Termdd.sys), which listens for RDP client connections on TCP port number 3389.
At this point, the CSRSS process exists under its own SessionID namespace, with its data instantiated per process as necessary. Any processes created from within this SessionID will execute within the SessionSpace of the CSRSS process automatically. This prevents processes with different SessionIDs from accessing another session’s data.
