What happens during a Windows 7 Install?

During a chat discussion the topic of what happens at certain key points during the Windows 7 installation came up. Knowing what exactly happens at these points would be great in determining any issues that may arise during an installation. For example, during an installation, Windows 'expands' files to be installed. What happened that caused the installation to freeze at say 27% of expansion? Knowing the basic idea of what 'expanding' really means would be helpful.

There are 5 main steps to the Windows 7 installation process:

Copying Windows Files
Expanding Windows Files
Installing Features
Installing Updates
Completing Installation

What I'm looking for is a greater detail on what each of those steps really represent, and if there are specifics that we can extract from those steps (like what percentages may represent).

i.e. Does copying Windows files mean creating a ram disk and then copying installation files to that disk? Is the 27% typically where Windows is loading drivers? and so forth.

Solution 1:

Community Wiki documentation on the boot process

Since detailing the whole process into its finest details requires quite some analysis and research to be applicable to all Windows versions, and to outline the minor details of the setup; please help write this community wiki which can benefit other users in the future which are trying to understand where and why their boot procedure has failed... Thank you!

Copying Windows Files:

Since expanding everything from the installation medium would be tedious, setup first copies everything.

Copies boot.wim to C:\$Windows.~BT
Copies install.wim to C:\$Windows.~LS

Expanding Windows Files:

Now that we have our files, they can be expanded.

Expands install.wim in C:\, for Users, ProgramData, Program Files, Windows, ...
Expands boot.wim, containing the executable(s) and configuration to be able to boot.

Installing Features:

Enables and configures the features that need to be enabled, note that these can be customized. Given that the files are already in place, this is most likely making some hard links and changing some registry features to make the features present on the system.

Installing Updates:

Installs any KB updates that have been packed onto the installation medium. This is a common practice such that when you have to do multiple installations, it doesn't have to fetch the updates from the internet every time.

Completing Installation:

Detects your drivers, installing any drivers that came with the installation medium. If you need to install to a lot of computers of the same type, packing the drivers is worth it.
Cleans up anything temporary the setup has left behind.
Makes sure the system can be rebooted.
Makes sure the data on the hard drive has been synchronized and is no longer cached.
Reboots the system.

First Boot:

Some more configuration, mostly to further customize the OS to your hardware.

Audit Mode (optional):

If the system is set to boot in audit mode; either via unattended configuration, sysprep /audit or by holding Ctrl+Shift+F3 then the installation can be customized prior to making an user, this is useful to provide certain features (called crapware these days) before finalizing the installation. Note that usually this phase is automated, which finishes with a call to sysprep /oobe.

Out of Box Experience:

Finally, you arrive at the Welcome Screen where you can create your user profile.

The first login per user applies some further personal configuration.

Solution 2:

You don't necessarily need to document the various steps.

It's tedious work, given that there is not just one single setup...

You could do so, but that would only make your documentation specific to:

A certain version of Windows.
An installation versus an upgrade.
32-bit versus 64-bit
Hardware differences that can cause percents to be less / more precise.

If you're up to document it together with some others, that would be awesome. But it wouldn't be feasible if it's just one person doing it once. Because that's going to give a low return on investment.

You can simply see what happens during installation.

You probably know me by now, it's going to be... First letter: P

Exactly! Process Monitor is the right tool for this. Either get it on an USB drive or pack it onto the DVD. But this is going to leave you wondering, how does one run a program in the installation environment?

First, fire up the console using Shift+F10 then find the right drive letter and run procmon.exe.

In Process Monitor, just set it to capture everything and you will nicely see what exactly the installation is doing. This allows you to see the latest events at the moment of the freeze, you can't actually inspect their properties but it at least allows you to get an idea of what's going on.

If you want to save the events, you are going to have to do this before the ten second counter ends.

If you want to start capture the events after the boot, enable the boot logging option in the menu. When your computer has fully booted and you are logged in, opening Process Monitor will load the boot trace such that you can save the second part as well.

But what if a freeze or crash doesn't tell me enough?

For freezes:

You can set up Ctrl+Scroll Lock+Scroll Lock to do a user initiated crash on a Windows setup. So, perhaps this might as well be enabled by default in the Windows Setup. If it's not enabled by default one could try to edit the registry hives of the Windows PE environment of the Windows Setup, as to make sure that the setting is enabled by default.

If that doesn't work, the proper way people at Microsoft and System Builders do this is by enabling debugging and hooking up a debug cable between two computers, then they can simply pause the system during the freeze and debug it. The tool used for this will be outlined in the following section.

For crashes:

When experiencing a crash (BSOD), your first stop should be the Bug Check Code Reference to get an understanding what the particular bug check actually means. From there, the simple approach is to use WhoCrashed and perhaps see a particular cause.

The harder approach is learning WinDbg from the Debugging Tools of Windows, which allows you to analyze the dump and attempt to investigate what really happened. But sometimes this might not be clear and you'll have to do some hardware troubleshooting...