This article supports the Windows 7 Startup article.

I have documented the Windows components that are important to the Windows 7 Startup article. This article contains three diagrams to describe the Windows environment created at startup:

• kernel-mode system processes.
• user-mode application support primarily provides the environment sub-systems to run programs and the Win32 API.
• user-mode system processes primarily create sessions and allow users to logon.

The diagrams can be re-used by you

The diagrams in this article are not drawings but HTML/CSS tables so if you want to use them they are easy to copy and relatively easy to modify for your own purposes. Just remember to attribute this article as the source.

Icons highlight key issues

The Windows startup article uses icons to highlight key issues. Some of those icons are used here.

32-bit and 64-bit Windows have some significant differences:
32 applies to 32-bit Windows only.
64 applies to 64-bit Windows only.

Where the startup feature was changed from Windows Vista:
 7  indicates a new feature for Windows 7.

If you are troubleshooting then look for these icons:
 !  indicates a critical process (processes set this status themselves) which can crash or halt Windows if it fails.

 

To give you a picture of how the Windows components fit together I have added a few diagrams. The first of these, Diagram 1 - An overview of kernel-mode components, focuses on the important system processes that run at the highest priority on the CPU. This is called privilege 0 or ring 0 priority and it corresponds to kernel-mode processing. User-mode is ring 3 where the CPU can ensure that user-mode processes cannot call code at ring 0. All kernel-mode components share the same address space but they do not access the data structures any way they like. They generally use structured interfaces to ensure that kernel-mode operations are orderly. 

The kernel-mode components in diagram 1 are layered from the bottom to the top just like many of the other diagrams you will see.

Diagram 1 - An overview of kernel-mode components
Ring 0 Kernel mode	↓		↓		↓				↓
System threads
Idle threads	↓		↓		↓				↓
Kernel trap handlers
System Service Dispatcher
Executive APIs						Windows sub-System Win32K API
IO Mgr.	SRM	...	...	ALPC	Window Manager	GDI			DirectX
Device, File System, Filter,	Executive					Graphics Device Drivers (WDDM)
and Network Drivers	Object Manager					Interface (DDI) Drivers
	Kernel
Hardware Abstraction Layer (HAL)
Hardware Interface

 

Hardware interfaces

Hardware interfaces for the motherboard components of your computer.

Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer (HAL) mainly handles the BIOS and chipset features. It has no user-mode API and it has some core drivers compiled into it..

While we are discussing the HAL, it is worth noting that the system hardware determines which version of the HAL and NTOSKRNL images are installed. The HAL image depends upon the level of Advanced Configuration and Power Interface (ACPI) support and the type of Programmable Interrupt Controller (PIC). Multiprocessor systems use an Advanced PIC (APIC).

Device Drivers

Drivers are in two main groups. Only the graphics drivers interface directly to the hardware interfaces. All other interfaces are to the HAL.

Kernel

The kernel is loaded as the smaller part (about 5%) of NTOSKRNL You might see it referred to as the "microkernel" which it technically is not because a true microkernel would not share memory space with other components. The kernel has two main functions:

• an abstraction layer for the CPU so it handles scheduling and other low-level activities.
• Traps, exceptions and interrupt dispatch which is how user-mode processes access kernel-mode. See the top two levels which are the kernel trap handlers used to transition user-mode processes into kernel-mode and the System Service Dispatcher which manages entry to and exit from kernel-mode.

Two factors determine which NTOSKRNL image is used: the number of processors - not the actual number of CPUs but the number of processing units so it includes Hyperthreading - and, if the processors are 32-bit, then whether Physical Address Extension (PAE) is being used to allow more than 4GB of memory to be addressed: NTKRNL.EXE for uniprocessor, NTKRNLMP for multiprocessor; then NTKRNPA and NTKRPAMP for PAE support.

Executive

The kernel Executive is the remainder (about 95%) of NTOSKRNL. It is made up of the various kernel-mode services (I haven't listed them all) such as the Security Reference Monitor (SRM) and the Advanced Local Procedure Call (ALPC) facility  7 , which is used for communications between components. It is modified from the older LPC. The Executive provides for extensions to the operating system i.e. device drivers.

Two components handle communication with the device drivers:

• The IO Manager handles communications with the non-graphics device drivers.
• Win32K.sys handles communications with the graphics device drivers. This is the kernel-mode portion of Win32 hence the appended 'K' for kernel. It includes the Window Manager which handles user input and screen output, the Graphics Device Interface (GDI) for drawing to devices (normally screens or printers), and DirectX graphics. GDI+ adds newer features to the GDI including better support for common file formats such as JPEG, PNG, Flash and SVG.

I mentioned the formal interfaces used to access kernel-mode data structures. The Object Manager is the major component for providing this. It manages resources particularly those that are named, shared by components, or exported to user mode.

System threads

Finally, we have the system threads and the idle threads (one per CPU). Technically these threads are not processes but they are generally treated as such because they use system time which is normally accounted for.

Undocumented APIs

The kernel-mode APIs are largely undocumented except for reverse-engineering by developers looking to replace Win32. Examples are WINE on Linux and REACTOS.

The Win32K API is the portion of the WIN32 API that was moved to kernel mode in an earlier version of Windows.

The kernel-mode Executive has a lot of components that are not listed here. Those components provide APIs but notice that the lower-level Kernel does not.

At this point, Windows starts the major user-mode processes which are primarily DLLs to provide programs with access to standard libraries of features including access to kernel-mode components. Diagram 2 summarises these components and the programs that use them: system processes, services, Windows applications, DOS applications, and applications in other GUI environments such as POSIX (Portable Operating System Interface).

User-mode system processes are mainly omitted

I have omitted the user-mode system processes from this diagram to keep it simple and to emphasise that this part of startup is primarily about getting all the APIs (in DLLs) in place so Windows can commence normal operation. The user-mode system processes are associated with session management, security, and logon so they will be more usefully displayed in a diagram that emphasizes the startup sequence. That is Diagram 3 - User-mode system processes.

The Windows Sub-System is the core of user mode

The Windows Sub-System has two major components:

• The Client Server Runtime Sub-System (CSRSS.EXE) is the primary process that runs for every session in Windows.
• The Win32 API is the primary user-mode API for Windows 32 i.e. Win32. It is made up from numerous DLLs but the main ones are included in the diagram.

You will find that almost every diagram on user-mode does not elaborate on the Windows Sub-system. That is because it is complex and difficult to illustrate. Even this diagram will be potentially misleading as there are so many different relationships with other Windows components.

Two important points about Windows that are not very obvious are that Windows is designed for multiple different user environments/interfaces and each executable program must be associated with one.

• When a program is compiled the sub-system is set to tie it to a specific sub-system. Then when a program is to be executed Windows reads the sub-system setting so it can attempt to execute the program under the correct sub-system. For further specifics refer to the notes for the programs diagrams in the article Windows Startup Terminology.
• Each environmental subsystem can then have its own APIs and its own support processes.
• The environmental sub-systems are defined in the registry under the key HKLM\System\CurrentControlSet\Control\Session Manager\Subsystems. Refer to the Session Manager (SMSS) which loads CSRSS and other environment processes.

I included two examples in Diagram 2:

• 16-bit DOS applications are executed in an emulated DOS environment provided by NTVDM.EXE. 32
• POSIX applications have their own environment sub-system called SUA and POSIX processes are executed by POSIX.EXE which can be considered an equivalent of CSRSS. While POSIX could have its own user interface DLLs with a consequent duplication of resources, Windows is designed to use the Windows Subsystem, i.e. the Win32 API also provides SUA with its user interface.

The kernel mode and user mode diagrams can be combined

The overall flow of diagram 1 is from the user at the top to the kernel-mode components which would sit below this diagram. If you wanted to get a larger overall picture then you can attach Diagram 1, Kernel-mode components, below the line at the bottom of the table. I have done this for you in Diagram 4.

I have indicated with arrows the flow of calls towards the DLL kernel. Note that some of those calls will bypass the higher-level DLLs to use the NTDLL.DLL or even bypass that and use the kernel-mode APIs.

Diagram 2 - An overview of user-mode components
	Windows Services		Windows Applications		DOS Applications 32		POSIX Applications
	Windows services		Windows application		DOS Application		POSIX application
	Service DLLs		Application DLLs		Application DLLs		Application DLLs
	↓		↓		↓		↓
Windows Environment Sub-system
	Win32 (See below)		Win32 (See below)		Win32 (See below) + VDM DLLs		Sub-system for Unix Applications (SUA) API PsxDLL.DLL
Windows Environment Support Image
	CSRSS (See below)		CSRSS (See below)		NT Virtual DOS Machine NTVDM.EXE or Command Interpreter CMD.EXE		POSIX.EXE
	↓		↓		↓		↓

The Windows Sub-system including the Win32 API  !
							Client DLLs - major DLLs  !
	Client Server Runtime Sub-System  CSRSS.EXE  !  One instance for non-interactive session 0 One to n instances for interactive sessions 1-n					← →	Other     AdvAPI32 .DLL	BASE     Kernel32 .DLL	USER     User32 .DLL	GDI     GDI32 .DLL
			Server DLLs - for each CSRSS instance  !				Other Win32 DLLs  !
		Console Host  ConHost .EXE	BASE     BaseSrv .DLL	Multi-user Windows   WinSrv .DLL	Client Server Runtime CSRSrv .DLL		Windows Common Dialogs Library ComDlg32 .DLL	Windows Common Controls Library ComCtl32 .DLL	Windows Shell Common DLL Shell32 .DLL	Shell Light-weight Utility Library ShLWAPI .DLL	etc.

↓

↓

↓

↓

Native Windows API NTDLL .DLL  !

↓

↓

↓

↓

Ring 3 User mode

---

If you wanted to get a larger overall picture then you can attach Diagram 1, Kernel-mode components, below the line above as I have in Diagram 4.

 

NTDLL.DLL

NTDLL.DLL is called the Native Windows API but it is somewhat misnamed because technically it does not expose the entire Native API to user-mode.

NTDLL.DLL duplicates most of the Win32 API so it can be used by kernel-mode sub-systems and user-mode applications before the Win32 API is available. It also provides kernel-mode access which is not in the Win32 API.

Applications that link directly to NTDLL.DLL are called Native Applications. They are built using the Windows Driver Development Kit (WDDK) and cannot be run in normal user-mode. They include the Session Control Manager (SMSS), the Client-Server Runtime (CSRSS), and the disk check program (autochk.exe). Native applications are a small proportion of all Windows applications because the Kernel32.DLL in the Win32 API also exposes many of the kernel functions provided by NTDLL.DLL.

Win32 API - The Windows Sub-System

The Win32 API is primarily provided by the DLLs loaded by the Windows Subsystem. It is important to remember that the Windows Subsystem is the process Client-Server Runtime Sub-system (CSRSS.EXE) and associated DLLs which must be running if Windows is to run. CSRSS primarily handles the Windows console and the shutdown of the graphical user interface (GUI). This is a lot less than the functions it performed in earlier versions of Windows.

CSRSS loads two groups of DLLs:

• Client DLLs which provide the base API (Kernel32.DLL), the Windows interface API (User32.DLL), the drawing API (GDI32.DLL), and other advanced features (AdvAPI32.DLL).
• Server DLLs to manage processes and threads (BaseSrv.DLL), provide Side-by Side (SxS) support (WinSrv.DLL), and console management (CSRSrv.DLL). 

CSRSS performs two further tasks:

• It runs the Console Host which provides drag & drop and applies WIndows themes to the Windows command line or command interpreter window.   7 
• It performs some functions that support the Win32 API which would otherwise have to be handled by a kernel-mode component.

Client DLLs

The Windows 32 Base API (KERNEL32.DLL) means base resources for Windows such as the file system, devices, processes & threads, and error handling. Base also manages memory, handles IO (Input/Output), and creates processes and threads.

The Advanced Windows 32 Base API (ADVAPI32.DLL) are services additional to the kernel such as the registry API, shutdown & restart, windows services (start, stop, create), and managing user accounts.

The Interface Window Manager Multi-User Windows API (USER32.DLL) produces desktops, windows, and menus. The GDI is called by User to render the user interface on screen.

The Graphics Device Interface CLient DLL (GDI32.DLL) outputs graphics to monitors, printers, and any other suitable output device.

These DLLs can call further DLLs for additional functions. For example, dialogs are produced by COMDLG32.DLLp which also produces progress bars, list views, and the File Open, Save, and Save As dialogs. It uses both USER32.DLL and GDI32.DLL. Here's some more:

• Dialogs are in the Windows Common Dialogs Library (COMDLG32.DLL).
• Controls are in the WIndows Common Controls Library (COMCTL32.DLL).
• Windows shell is in the Windows Shell Common DLL (SHELL32.DLL) and the Shell Light-Weight Utility Library (SHLWAPI.DLL). SHELL32 provides access to the Windows Desktop objects and user interface (UI) objects. SHLWAPI has a large and diverse set of features including URL paths, colour settings, and registry entries.

Server DLLs

The Windows NT BASE API Server DLL (BASESRV.DLL) create and deletes processes & threads. It also provides 16-bit DOS emulation for 32-bit WIndows 32.

The Multi-User Windows Server DLL (WINSRV.DLL) handles Side-by-Side (SxS) DLL manifests which allow multiple versions of DLLs to coexist.

The Client Server Runtime Process (CSRSRV.DLL) handles console management.

Windows provides for non-Windows environment sub-systems

Remember that the kernel mode portion of the Windows Subsystem is Win32K.sys. Other non-Windows environments can be supported such as POSIX, a standard for UNIX-based systems.

The Sub-system for Unix-based Applications (SUA) provides specific POSIX support. But SUA still uses the Win32 API to provide the user interface and other generic features.. Although it would be possible for POSIX applications to run in user mode without using any Windows DLLs, it is more efficient for make use of components that are already running. For example, the Graphical Device Interface for drawing to screens and other devices.

The user-mode system processes are largely the system startup processes in user mode. I have not described them here if I they are already described in the Windows 7 Startup article. So that means the components that I discuss here are primarily the LSASS components to user logon. The authentication pathways are indicated in red to differentiate them from the startup flow which proceeds from bottom to top.

Note that the user-mode system processes are often referred to as system processes but this creates confusion when the same term is used for kernel-mode programs so I always qualify the name with the mode.

Local Security Authority Sub-System (LSASS) authenticates locally or over a network

LSASS authenticates users depending upon the status of a domain controller so I have included that in Diagram 3 although it is not needed to logon to a stand-alone computer. Notice that I only show the domain controller processes as far as the authentication packages. Behind them are the same LSASS processes as on the user's system here.

• If there is no domain controller, the workstation is disconnected from the network, or there is no network then the legacy authentication package for NT LAN Manager (MSV1_0.DLL) is used.
• If the domain controller uses a Windows version before Windows 2000 then the legacy authentication package for LAN Manager (MSV1_0.DLL) is also used.
• If the domain controller is Windows 2000 or later then the Kerberos authentication package is used.

Security Account Manager (SAMSRV.DLL)

The Security Account Manager (SAM) server caches password information for local logon. If the computer were on a network domain then those cached passwords are used to authenticate users when a domain controller is not available. Note that the complete passwords are not stored. The passwords are hashed and half the password hash is stored which is enough to confirm the password.

Diagram 3 - User-mode system processes
					LSASS on a domain controller
	Explorer EXPLORE.EXE				NT LAN Manager MSV1_0.DLL		Kerberos Key Distribution Centre KDCSVC.DLL
	↑				↕		↕
	User Initialization USERINIT.EXE  !				NetLogon NETLOGON.DLL
	↑				↕		↕
			Local Security Authority Sub-System (LSASS)
	↑				NetLogon NETLOGON.DLL		↕
			Authentication package: based on the domain controller (DC):		↕		↕
	↑		No network/DC or disconnected		Pre-2000 DC		2000 or later DC
			NT LAN Manager MSV1_0.DLL  !		NT LAN Manager MSV1_0.DLL  !		Kerberos Client KERBEROS.DLL
	↑		↕		↕		↕
			Security Account Manager (SAM) Server SAMSRV.DLL  !	↔ ↔	⌟ ↔	↔	↕ ⌟
	↑		SAM database HKLM\SAM  !
	↑		↕
	Windows Logon WINLOGON.EXE  !	↔	LSA Server  !
	Logon User Interface LOGONUI. EXE		LSASS database HKLM\SECURITY  !
	Credential Provider(s)		↑
	↑		Local Security Authority Sub-System LSASS.EXE  !
	↑		↑
					Local Session Manager LSM.EXE  !		Service Control Manager SCM.EXE  !
	↑		↑		↑		↑
			Windows Initialization WININIT.EXE  !	→ →	⌟ →	→	↑ ⌟
	↑		↑
	Client-Server Runtime Sub-System CSRSS.EXE  !		Client-Server Runtime Sub-System CSRSS.EXE  !
	↑		↑
	Session Manager Sub-System SMSS.EXE  !		Session Manager Sub-System SMSS.EXE  !
	Interactive session(s) 1 to n		Non interactive session 0
	↑		↑
	⌞	←	Session Manager Sub-System SMSS.EXE  !
Ring 3 User mode			↑

---

Notice that I included LogonUI with WinLogon as there was no space for it in another column. The benefit of this is that it highlights that LogonUI is a child process of WinLogon which performs the authentication check with LSASS. 

 

As mentioned before here are Diagram 1 and Diagram 2 combined. If you want to combine Diagram 3 then it attaches to the side of Diagram 2.

Diagram 4 - An overview of Windows components
	Windows Services		Windows Applications		DOS Applications 32		POSIX Services
	Windows services		Windows application		DOS Application		POSIX application
	Service DLLs		Application DLLs		Application DLLs		Application DLLs
	↓		↓		↓		↓
Windows Environment Sub-system
	Win32 (See below)		Win32 (See below)		Win32 (See below) + VDM DLLs		Sub-system for Unix Applications (SUA) API PsxDLL.DLL
Windows Environment Support Image
	CSRSS.EXE (See below)		CSRSS.EXE See below		NT Virtual DOS Machine NTVDM.EXE or Command Interpreter CMD.EXE		POSIX.EXE
	↓		↓		↓		↓

The Windows Sub-system including the Win32 API  !
							Client DLLs - major DLLs  !
	Client Server Runtime Sub-System  CSRSS.EXE  !  One instance for non-interactive session 0 One to n instances for interactive sessions 1-n					← →	Other     AdvAPI32 .DLL	BASE     Kernel32 .DLL	USER     User32 .DLL	GDI     GDI32 .DLL
			Server DLLs - for each CSRSS instance  !				Other Win32 DLLs  !
		Console Host  ConHost .EXE	BASE     BaseSrv .DLL	Multi-user Windows   WinSrv .DLL	Client Server Runtime CSRSrv .DLL		Windows Common Dialogs Library ComDlg32 .DLL	Windows Common Controls Library ComCtl32 .DLL	Windows Shell Common DLL Shell32 .DLL	Shell Light-weight Utility Library ShLWAPI .DLL	etc.

↓

↓

↓

↓

Native Windows API NTDLL .DLL  !

↓

↓

↓

↓

Ring 3 User mode

---

Ring 0 Kernel mode	↓		↓		↓				↓
System threads
Idle threads	↓		↓		↓				↓
Kernel trap handlers
System Service Dispatcher
Executive APIs						Windows sub-System Win32K API
IO Mgr.	SRM	...	...	ALPC  7	Window Manager	GDI			DirectX
Device, File System, Filter,	Executive					Graphics Device Drivers (WDDM)
and Network Drivers	Object Manager					Interface (DDI) Drivers
	Kernel
Hardware Abstraction Layer (HAL)
Hardware Interface

 

• Windows Startup Terminology summarises terms that are used in this article. The terms generally relate to running programs so there is section on how programs start and run.
• Windows 7 Startup is an overview of the startup phases and activities for Windows 7. It also describes the main Windows components and lists more detailed activities including relevant registry keys and values.
• What Everybody Should Know About the Windows Registry

Microsoft references:

• The Windows Internals book does not specifically look at Windows startup but it does look at the components involved in many aspects of startup. The 6th Edition looks at Windows 7 and the two volumes are cheap at the moment because the next edition which covers Windows 8 should be available later in 2014.

Back to the top of the article.