Overview

You may have heard the about the fact that Windows 7 (and actually, Windows Vista too) has improved boot up times over Windows XP and dismissed it as “that there marketing speak”. Surprisingly, it’s actually true! On top of that, the boot process is also optimized over time to make things even faster. This blog post gives a high-level overview of how this works and also provides some actual measurements.

The descriptions given in this article are fairly high-level for a number of reasons. I wanted it to be readable for the general IT admin, and hard documentation on the exact workings of this stuff is virtually non-existent so it contains quite a lot of educated guesses. The epic Windows Internals book discusses both the logical prefetching and ReadyBoot mechanics in a lot of detail, but many of the services and registry keys mentioned in that book reference Windows Vista and they no longer apply to Windows 7 (although the functionality is still there and has been improved, it’s just less obvious which services and keys now control the process).

Logical Prefetcher

Various analysis of boot tracing have shown that one of the main factors that slows the boot process down are disk seek times. As the various boot files, dlls, and drivers are loaded there are lots of page faults and disk seek requests as different parts of files and directories are accessed. Windows 7 keeps track of what files were accessed and the location of these files on the disk and this tracing continues for up to 120 seconds after boot, or 30 seconds after the user’s shell (explorer.exe) starts, whichever comes first. These traces are stored in C:\Windows\PreFetch:

Logical Prefetcher Trace Folder

Each trace contains a list of the files and directories accessed when a given application starts (or during boot) and this information is used to give the prefetcher a chance to prefetch all the data required in one go, so that the loading of the application can be optimized.

In addition, any files referenced by these boot applications (DLLs, SYS files, etc) are also tracked in C:\Windows\PreFetch\Layout.ini. Every few days, when the system is idle, defrag.exe is called with a command-line parameter that causes all these referenced files to be moved to a contiguous area of the disk. This means that the prefetching of these files is much more efficient and further improves the boot time. You can manually invoke defrag to optimize boot files by running the following command (Windows 7 only, the parameters are different on Windows Vista):

defrag.exe c: /b

(This will only work after the machine has been booted around 6 times, otherwise you will get an error about the lack of boot optimization files)

Note: When fully optimized this defrag command should complete quickly (a couple of minutes or so) as the boot files will already be in a contiguous area of the disk. However, I’ve seen machines many months old that have taken up to an hour for this defrag command to complete which leads me to believe that the automatic idle processing may not actually work correctly in all situations. Therefore, it’s a good idea to run the command manually.

You can see the last time the automatic boot defrag occurred by checking the value of the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher\LastDiskLayoutTimeString. Unfortunately, this value doesn’t appear to be changed when you run the defrag command manually.

ReadyBoot

According to the Windows Internals book, the logical prefetching described above is used when the system has less than 512MB of memory. If the system has 700MB or more then an in-RAM cache is used to further optimize the boot process (it’s not clear from the book whether or not this ReadyBoot cache completely replaces the logical prefetching approach or just builds on it, my assumption is that both work together). After each boot the system generates a boot caching plan for the next boot using file trace information from up to the five previous boots which contains details of which files were accessed and where on the disk they were located. These traces are stored as .fx files in the C:\Windows\PreFetch\ReadyBoot folder.

ReadyBoot Trace Folder

Services

Under Windows 7, the service that handles ReadyBoot optimization is part of the Superfetch service.

Under Windows Vista, ReadyBoot optimization was part of the ReadyBoost service (ironically, when Windows Vista came out the advice on “tweaking” sites was to disable ReadyBoost if they weren’t going to use USB/ReadyBoost to improve performance – errrm, no…)

There are some semi-undocumented registry keys that control the prefetch and superfetch operations, but in all but the most exeptional cases they should not be touched. They are only documented on the Windows 7 embedded sites for Disabling Superfetch and Disabling Prefetch. The default value for boot these keys is 3 which enables both boot and appliction prefetching.

An Example

So, does this prefetching and boot optimizing actually work? The following table shows the boot times on an ancient Toshiba Tecra M5 (circa 2004) through its first boot, the subsequent five boots and finally after the disk is defragged with the boot optimization switch. The machine is using a vanilla version of Windows 7 Ultimate SP1 x86 – no applications are installed. The boot time is measured using the bootDoneViaPostBoot metric generated from the Windows Performance Toolkit (WPT) (The boot logging process is detailed in this previous blog post)

You can see the massive improvement that occurs in the first few boots and then some smaller but significant gains in the later boots and the final defrag optimization. This example used a vanilla machine with very few drivers installed and no additional applications. The more drivers and software installed the more files must be accessed during boot which means these optimizations are likely to have an even more pronounced effect.

As this optimization is automatic it’s not something that most people will need to worry about. But if you are building machine that you would like to boot as quickly as possible from the moment it is deployed (appliance PCs, laptops, etc.) then it may be worthwhile adding a “boot training” and defrag task to your deployment processes.

Other Articles You May Like

MDT and ConfigMgr Build Drivers for Windows 7 Welcome to the AutoIt Consulting Blog! Create a Windows 7 BitLocker Partition in ConfigMgr SCCM Package and Program Return Codes and Reboot Behaviour Windows Performance Toolkit: Simple Boot Logging