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
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?
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.
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...