Inside nt boot

The real takeover system of NT starts from the Boot Sector of the NT partition being booted. the Boot Code of the boot fan is written during NT installation. when NT is installed in the FAT partition, NT setup writes the boot code that can identify the fat Fs. When NT is installed in the NTFS partition, NT setup writes the NTFS boot code. therefore, the boot sector contains a piece of Related File System code. note! This code can only perform read operations on the file system, but not write operations.
When the Boot Sector is booted, one thing it does is to find ntldr. The file must exist in the root directory; otherwise, the system prompts:
Boot: Couldn't find ntldr. or a kernel file is missing from the disk. NT is dead. when ntldr is loaded, the system is still in the real mode. therefore, the first major task of ntldr is to switch the CPU from the real mode to the protection mode. after ntldr creates all the Memory Page descriptors below 1 MB, ntldr enables page ing. Now NT can access 4 GB memory. then, ntldr uses the built-in file system code to find the boot under the root directory. ini. (ntldr contains read-only code for fat and ntfs2 file systems. the INI content prompts you the optional operating system. this parameter is not selected by default. ntldr directs the default Operating System. if the user chooses dos, ntldr will set the bootsect under the root directory. DOS loaded into memory, (bootsect. DOS is a copy of the DOS boot fan .) then execute a hot start. if C: NTFS at this time, DOS will not be started. otherwise, DOS will be guided out.
Aha, then ntldr loads ntdect. com. this program will display ntdetect v4.0 ..... this ntdect. com calls intxx to execute a lot of BIOS system calls. used for System Configuration detection. all detected items will be stored under the HKLM/hardware/description in the system registry.
Then, execute the command again to restore to ntldr. the screen displays osloader v4.0 .... the following two files constitute the core of Windows NT. that is: Hal. DLL, ntoskrnl. EXE. the two files will be checked for PE checksum during loading, if there is a problem or cannot be found. NT is dying again. one thing to note. single-processor and multi-processor ntoskrnl. EXE is different. multi-processor ntoskrnl is supported. the file name of EXE in the installation disk is ntkrnlmp. EXE. however, once copied to the NT System directory, the name becomes ntoskrnl. EXE. because ntldr only loads ntoskrnl. EXE. after the two files are loaded, ntldr loads all the drivers required for the boot, and then loads the driver with the value of service_boot_start in HKEY_LOCAL_MACHINE/system/services. (Initialization is not performed at this time .) (I do not know how to write the driver of service_boot_start, because if the common KMD is started with the value of service_boot_start, it will fail .) then ntldr will lock ntoskrnl. EXE main () function, and then transfer the control to ntoskrnl. EXE.
BTW: The main () function of ntoskrnl. EXE is
Int main ()
{// Fire up nt!
//
Kisystemstartup ();
Return 0;
}
This describes the Initial Startup of NT for i386. from boot to load ntoskrnl. EXE. and there are still many branches not written. for example, processing last known good configeration. till now, NT has no appearance of NT, even the prototype of the operating system is not displayed.

Next, NT started initialization of its complex OS core. call expinitializeexecutive first, and this function calls Hal. the function hallnitsystem () in DLL (). at this time. NT completes the initialization of the interrupt controller and the time slice setting. when hallnitsystem () is returned, the following code initializes the Memory Manager, security reference monitor, object manager, and process manager. after the Memory Manager is initialized, NT displays Microsoft (r) Windows NT (TM) Version 4.0 (build 1381 ). the service pack number is retrieved from HKEY_LOCAL_MACHINE/system/CurrentControlSet/control/Windows/csdversion in the registry. after the process manager Initialization is complete (the Process Manager is ntoskrnl. EXE), the Process Manager generates two processes. one is the idle process. one is the system process. when expinitializeexecutive is returned, expinitializeexecutive becomes the idle thread. the idle thread has the lowest priority.

BTW: the most terrible is the scheduling algorithm of the NT server. each thread usually occupies Ms on an Intel processor. when the thread waits for an I/O process, it will certainly have an idle thread. because the Win32 subsystem of NT usually does not return to the caller before the IO execution is completed, and does not switch to other threads, generally, if it is called by SoftICE, it will always see that the system is stopped on the HLT command. when a hardware device completes I/O, an interruption occurs to end hlt. then, the caller is returned after a large pile of subsequent code. if you disable hlt. the system can improve the reaction speed within a limited range. my halpatch is used to disable the HTL command.
Okay. Go back to the starting topic of NT.

Now call Hal to activate the multi-CPU function. (If the system has more than two CPUs. workstation supports 2 CPUs. server supports 4 CPUs. enterprise Edition supports 8 CPUs. enterprise SP3 also supports 3 GB application space .) then, Object Manager, executive, kernel, security reference monitor, Memory Manager, cache manager, Configuration Manager, I/O manager, and Process Manager are called in sequence.
The IO manager initializes the driver whose startup value is service_boot_start, and then starts the loading of the startup value service_system_start in the registry.

After all the drivers are initialized, there is no user mode program or any environment subsystem. the system process calls the core function exinitializesystem to create the SMSs process. is the Session Manager process. SMSs is the first user mode application. he is a real native application. he does not rely on any subsystem. the only thing that SMSs needs is NTDLL. DLL. he created the Win32 subsystem.
Then SMSs:
Create LPC Port object/smapiport.2 threads and wait for customer requests, such as loading subsystems.
Create environment variables.
Define DoS symbolic join.
Create an additional page scheduling file.
Find the native application loaded during boot from HKEY_LOCAL_MACHINE/system/CurrentControlSet/Session Manager/bootexecute. chkdsk. EXE is usually used.
Call config manager to complete configuration of HKEY_LOCAL_MACHINE/SAM, HKEY_LOCAL_MACHINE/SAM/security, HKEY_LOCAL_MACHINE/software.
Then load win32k. SYS. Then the system is switched to the graphics state.
Start the Win32 subsystem, that is, CSRSS. EXE.
Start Winlogon. EXE.
Create an LPC port for debugging and create a thread for monitoring.
After completing these tasks, SMSs will always wait for the Winlogon and CSRSS process objects.
After Winlogon is started. start SCM (Service Manager ). start all "auto-start" services. of course, Winlogon does not wait for any service to be started. it is very likely that the user has logged on and the service has not been started. an error may occur when some applications in the START Group depend on some services. this is also an old topic discussed by programmers in newsgroups. just as our programmers and friends always love to write some very basic questions to their home page :) joke :).
After all services are started correctly, the HKEY_LOCAL_MACHINE/system/CurrentControlSet becomes the last known good control set.
After SCM is started, Winlogon creates a workstation, representing KBD, mouse, and monitor. and ensure that the service cannot access the workstation to ensure security. after the workstation is created, three desktops are opened. APP, SCR saver, Winlogon. ms claims that any activation code and data on the Winlogon desktop cannot be accessed. it's just a fart. as long as you know the physical memory address of the Winlogon code, what can't be modified? :) Of course, if you do not know the physical address of Winlogon, it is true: Then, establish LSA and LPC connections for login, logout, and password operations.
Call lsalookupauthenticationpackage to obtain the ID of msv1_0 for identity authentication. (copied from inside Windows NT :)) create a Winlogon window class. make sure that the window is called after the SAS sequence key is pressed. you can switch to another application desktop only after the Winlogon desktop is unlocked.

During logon, Winlogon calls Gina to confirm user login. this also provides a method to replace the login verification operation of NT itself. at the core discussion group of MS, there are always friends studying how to obtain passwd. the answer is often to provide a Gina stub.: Of course, I have never written Gina stub. but I read the MS documentation again... it is estimated that it is not enough to write a useful Gina stub. of course, I have a way to be lazy, and most programmers write Gina stub, that is, to concatenate themselves into the old Gina stub: dd MS is strongly not recommended.
After the user completes authentication, the login succeeds and the desktop is unlocked. and call USERINIT. EXE. this program will find the user's shell. and start it. then, end your life. this is why shell has no parent process in any process viewer. because the parent process has ended.

Now, NT is fully started. I want to describe the key part clearly. If it is possible in the future, I will polish the statement in the article. It doesn't look too boring.