What happens before your desktop appears

By default Windows traces the first two minutes of a boot and the first ten seconds of each application start, and writes what it saw to a file in %SystemRoot%\Prefetch. That is the whole of the feature people are told to delete. The trace is not a log of anything you did, it holds no recoverable disk space worth counting, and it exists for one purpose: so that the next start can issue the same reads in large batches instead of discovering them one seek at a time.

§1The folder you are told to empty holds one trace file per program and one for the boot

Costs to trace a launch

first 10 s of application startup

Costs to trace a boot

first 2 min · 1 file, NTOSBOOT-B00DFAAD.PF

Costs in disk space

NOT ESTABLISHED — see §2

The most detailed first-party description of the mechanism is also the oldest. Mark Russinovich published it in the Sysinternals newsletter of 2001-08-20, which Microsoft now hosts on learn.microsoft.com, and the numbers in it are the ones every later document repeats. The cache manager watches the page faults a program takes as it starts; it traces the first two minutes of the boot process and the first ten seconds of an application start; the task scheduler post-processes that trace and writes it under \Windows\Prefetch as the program name, a dash, a hexadecimal hash of the file’s path, and a .pf extension. The boot’s own trace is the exception to the naming rule and is always called NTOSBOOT-B00DFAAD.PF.

An archived Microsoft blog post from 2014 restates the application half in current terms and attributes it to a named component: application-launch prefetch was implemented in Windows XP as part of the SysMain service (%systemroot%\System32\Sysmain.dll), it monitors up to the first ten seconds of startup with heuristics to stop sooner when the program stops faulting pages, and the trace file describes the pages that were historically accessed during launch. Both sources agree on the ten seconds, thirteen years apart.

What we could not establish. The Prefetch folder on a running machine also contains a ReadyBoot subdirectory, and that is the part of this article we could not tie to a Microsoft page. We looked at the Windows Performance Toolkit’s ReadyBoot reference, its boot-prefetch action page, the ReadyBoot summary table and the archived Microsoft blog material, and none of them names a path on disk for those traces. So the sentence we can defend is that the boot cache plan is built from earlier boots (§4); the sentence we cannot defend from a primary source is that the plan is stored inside the folder a cleaner empties. If you have a first-party citation for that path, the address is the contact form.

§2Deleting a trace file frees a negligible amount of disk and costs the next launch of every program you deleted

Costs to delete

1 unprefetched launch per program

Costs to rebuild

1 trace per program, written after its next start

Costs in a published measurement

10–80% launch gain claimed, method unpublished

The mechanism of the loss is on the same page as the mechanism of the gain. When a program is launched the prefetcher looks in the prefetch directory to see whether a .pf file is present; if it is, the kernel component issues asynchronous I/O to prefetch the metadata, data and image pages the trace describes. If it is not, none of that happens, and the start proceeds the slow way — each file found when it is first touched. Row D-04 is HARMFUL on that basis rather than NO-OP: the operation is not neutral, it discards information that took a real launch to collect, and the machine pays for it once per program until every trace is rebuilt.

The size of the gain is where we have to be careful, because the only figure anybody publishes is a claim rather than a measurement. The 2014 Microsoft blog says that in some recent tests the author saw between 10% and 80% improvement in application launch times across multiple devices and configurations, with the biggest improvements on devices under heavy I/O load and the smallest on an idle solid-state drive. That is a Microsoft engineer describing internal testing with no method, no hardware list and no distribution published, so it is CLAIMED, it is a wide range, and it is the best number in existence. Nobody has published an independent replication that we could find.

The arithmetic in Russinovich’s 2001 explanation is the part that has aged best, because it is arithmetic rather than a benchmark. Thirty binaries mapped into a simple program’s address space, at roughly ten milliseconds of seek latency each, is about 300 ms of seeking before a single useful instruction runs. On a solid-state drive that particular figure collapses, which is precisely why the answer changes by drive type in §5 rather than staying the same everywhere.

§3Layout.ini is the operating system telling the defragmenter where boot files should physically sit

Costs to regenerate

every 72 h at idle (2014) · every ~3 days (2001)

Costs on a rotating disk

1 layout pass · defrag /b

Costs on a fast SSD

0 — scheduled defrag excluded above 8 MB/s random read

The second file in that folder is Layout.ini, and it is the more interesting one. In the 2001 description, every three days or so the task scheduler builds a list of the files and directories in the order they are referenced during a boot or an application start, stores the list in \Windows\Prefetch\Layout.ini, and then launches the system defragmenter with a command-line option telling it to defragment according to the contents of that file rather than performing a full defragmentation; the defragmenter finds a contiguous area large enough for the listed files and moves them so they sit one after another. The 2014 blog gives the same mechanism with a modern owner and a precise interval: every 72 hours during system idle time the SysMain service provides information that the system defragmenter can use to order files and directories in launch-reference order, stored in %systemroot%\Prefetch\Layout.ini — and it adds the qualifier that matters, that SysMain does not run defragmentation itself, it only provides data for systems that have defragmentation enabled.

The sourcing here is weaker than the rest of this page and we are marking it rather than smoothing it. Both descriptions are archived: one is a 2001 Sysinternals newsletter, one is a Microsoft blog post archived under learn.microsoft.com/archive with an ms.date of 2014-03-14. Neither is current product documentation, and we found no live Microsoft page that describes Layout.ini at all. What is current is the operation they hand off to: the defrag command reference, updated 2023-09-28, still documents /b as Performs boot optimization to increase boot performance. Two archived descriptions written thirteen years apart, agreeing with each other and with a switch that still exists, is why this ships as DEPENDS on storage type rather than as an assertion. Row B-06 carries the same verdict for the older BootOptimizeFunction registry key, which is documented only for Windows Server 2003.

The condition is the drive. Windows disables the scheduled defragmentation on solid-state system drives, and Microsoft published the threshold it uses in 2009: the automatic schedule excludes partitions on devices that declare themselves as SSDs, and additionally excludes a system disk whose random-read performance is above 8 MB/s, a figure Microsoft describes as conservative and derived from internal analysis — of 182 hard disks tested, only six exceeded 2 MB/s. On such a machine the layout pass is not skipped because a tweak disabled it. It is skipped because the seek it was avoiding no longer costs anything.

§4ReadyBoot plans the next boot from the previous five, so a measurement taken straight after a change is measuring the old plan

Costs to build a plan

traces from the previous 5 boots

Costs in RAM

NOT ESTABLISHED — see §4

Costs to a valid before-and-after

≥5 boots after the change, then measure

ReadyBoot is the boot-time half of the system and it is documented, in the Windows Performance Toolkit reference, as boot acceleration technology that maintains an in-RAM cache used to service disk reads faster than a slower storage medium such as a disk drive. It reads data into that cache before it is requested, and reads served from it do not appear in the disk I/O graphs at all, because they never touch the disk — which the same page warns analysts about explicitly.

The training behaviour is the fact this article exists to publish. An archived Microsoft blog post from 2012-11-11, written in German, states it plainly: on a newly installed system ReadyBoot is not yet optimised, it analyses the last five boots (ReadyBoot analysiert die letzten 5 Bootvorgänge) and builds traces from them to train itself, and from those it constructs a boot plan recording which files were loaded during recent starts. The same post says the cache is discarded once the boot is finished. The tooling agrees with the number: the recommended way to prepare a fresh system for boot analysis is xbootmgr -prepsystem, which performs five restarts and builds a new plan from them.

The consequence is the part almost nobody states, and it invalidates most before-and-after boot claims ever published, including any we might be careless enough to make. If the plan is derived from the previous several boots, then the first boot after any change — a tweak, an uninstall, a new drive, an emptied Prefetch folder — runs against a plan built for the machine as it was. The second is better. By the time the plan has caught up, the person with the stopwatch has already published. This is not an argument that the tweak did nothing; it is an argument that the number does not mean what the person reporting it thinks it means. The honest method is in measure it yourself, with what is already installed: change one thing, boot at least five times, then start recording, and report the median and the spread rather than one run.

§5SysMain is the service that does this work, and Windows already decides per drive whether it should

Costs at the default

Automatic start · 1 service

Costs to disable

boot and launch prefetching stop with it

Costs on a qualifying SSD

0 — Windows disables it already

Every mechanism above belongs to one service. Microsoft’s current guidance on configuring system services, dated 2026-06-24, lists SysMain with a start type of Automatic, a description of Maintains and improves system performance over time, and a recommendation of Don’t disable. That is the live first-party position, and it is addressed to fixed-function devices, which is a scope worth stating rather than hiding.

The competing position is also Microsoft’s, and it is older and more specific. The Windows 7 engineering blog of 2009-05-05 states that by default Windows will disable Superfetch, ReadyBoost, and boot and application launch prefetching on SSDs with good random read, random write and flush performance, because those technologies were designed for drives where random-read performance is the bottleneck. It also records why the rule is conditional rather than absolute: the team initially turned all of it off on every SSD, hit sizable performance regressions on first-generation drives with bad random-write and flush behaviour, and turned it back on for those. Row S-07 is DEPENDS for exactly that reason, and the named condition is the system disk — a condition Windows evaluates itself, per drive, by benchmarking it.

So the tweak-list instruction to disable SysMain asks a reader to make, by hand and in advance, a decision the operating system already makes from a measurement of their own hardware. If the drive qualifies, the work is not happening and there is nothing to save. If it does not qualify, the work is happening because the drive is slow enough to need it. We think that is the whole of the argument, and we note that Microsoft has never reconciled its 2009 auto-disable language with its current Don’t disable guidance in writing. The registry value people are told to change alongside it, EnablePrefetcher, is UNVERIFIED in row M-09 for a related reason: the value table survives only in archived Windows Embedded documentation, so there is no documented default to restore afterwards.

§6Windows timed your boot without being asked, and Microsoft documents the field names nowhere

Costs to read it

0 · Event Viewer, already installed

Costs in documented field names

0 Microsoft pages found

Costs at the severity thresholds

30 s / 60 s post-boot · 60 s / 120 s boot

Open Event Viewer, go to Applications and Services Logs → Microsoft → Windows → Diagnostics-Performance → Operational, and filter for event ID 100. Every boot the operating system has recorded is there, with BootTime, MainPathBootTime and BootPostBootTime among the fields. It costs nothing, it needs no download, and it is the instrument that makes a boot-time claim falsifiable instead of anecdotal.

It also carries a caveat we are not going to leave out, because it is the reason row B-05 is UNVERIFIED rather than confirmed. We could not find a single Microsoft page that defines those field names. The Windows ADK documents the analogous assessment metrics for the On/Off Transition Performance assessment — Main Path Boot Duration is the time, in seconds, to resume from the end of BIOS initialization until Windows is initialized, Post On/Off Duration is the time, in milliseconds, that Windows took to complete all startup tasks after the desktop appeared, and Total Boot [Excluding BIOS] Duration is the sum including post-boot — but those are metric names in an OEM assessment tool, not the event-log fields. The only Microsoft-hosted text we found relating the two is an archived MSDN forum thread from 2010, in which a Microsoft employee gives the severity logic and the source-code threshold names (PostBootMinorThreshold_Sec 30, PostBootMajorThreshold_Sec 60, BootMinorThreshold_Sec 60, BootMajorThreshold_Sec 120) and states that the level attached to event 100 is the more severe of one computed from MainPathBootTime, defined there as BootTime minus PostBootTime, and one computed from post-boot time alone. That post carries the standard forum disclaimer that it is provided as is, with no warranties. We cite it because it is the best source that exists, and we label it because a number read from a field nobody documents cannot be checked against anything.

The practical use of the distinction survives the labelling. A machine whose desktop appears in twelve seconds and then thrashes for another ninety is not a fast-booting machine, and the two figures separate exactly that case. Whatever the field names are called, one of them stops when the shell is up and the other keeps counting.

§7The boot-speed module advertised here was a startup-program manager, and Windows 8 shipped the same feature with numbers attached

Costs of the in-box equivalent

0 · Task Manager, since Windows 8

High impact, as Microsoft defines it

>1 s CPU or >3 MB disk I/O at startup

Costs in coverage

3 autostart surfaces of at least 16

This domain sold a boot-speed feature, and its own help page says what the feature did. The second card above is the vendor’s description of the mechanism, in the vendor’s words, from a 2013 capture: the module listed the programs set to run at Windows start and let a user remove entries from that list, adding that removal disables the entry rather than deleting the program. That is a startup-program manager. It is not prefetch tuning, it is not a boot-layout pass, and nothing on the page describes touching any of the surfaces in §1 to §5 — which is worth saying, because it is the most defensible module the product had.

What removed the reason to buy it was Windows 8, and the replacement is better instrumented than the thing it replaced. Microsoft’s own developer guidance for that release defines startup apps as those launching from the Run keys, the RunOnce keys and the per-user and public Startup folders, and states the impact criteria the Task Manager Startup tab computes: high impact is more than 1 second of CPU time or more than 3 MB of disk I/O at startup, medium is 300–1000 ms of CPU or 300 KB–3 MB of disk I/O, low is under 300 ms and under 300 KB. A paid list with no numbers was superseded by a free list with thresholds, in 2012, which is why row B-02 is SUPERSEDED with a boundary of Win8.

The in-box list has a documented gap, and it is the same gap the paid tools had: three surfaces, out of at least sixteen places Windows can start a program. Scheduled tasks, services, drivers and a dozen other categories are not on that tab and were not in that module. The enumeration lives in sixteen places Windows can start a program; what belongs here is the narrower point that a startup manager covering three surfaces is not wrong, it is bounded, and a tool that does not publish its bounds is asking to be read as complete.

§8Neither automatic logon nor the processor-count box is a boot-speed feature

Costs of automatic logon

1 password, registry, plain text

Costs in who can read it

Authenticated Users, remotely

Costs of the processor-count box

0 cores added · up to n removed

The archived capability index lists automatic logon directly beneath boot-speed optimisation, which is where the confusion starts: it is filed as a speed feature and it is a credential-storage decision. Microsoft documents the mechanism in the support article originally numbered KB 324737, updated 2026-02-12. Automatic logon is turned on by writing AutoAdminLogon, DefaultUserName and DefaultPassword under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, and Microsoft states the cost on the same page without hedging: when autologon is turned on the password is stored in the registry in plain text, and the specific registry key that stores this value can be remotely read by the Authenticated Users group. Microsoft recommends the setting only where the computer is physically secured and untrusted users cannot reach the registry remotely.

So this is a TRADE with both sides stated in units: you save one password entry per boot, and one credential moves from a protected store to a registry value readable by a group most people have never enumerated. It is not HARMFUL as such — on a physically secured single-user machine it is a defensible convenience — but the archived claim above asserts the opposite of the documented behaviour, saying the feature also ensures the security of a computer connected to the internet. There is a supported way to reduce the cost: Microsoft’s own page notes that when AutoAdminLogon is configured with the Sysinternals Autologon tool the password is stored in a Local Security Authority secret instead of in the Winlogon key. This trade has no Ledger row yet; the boot section covers the speed claims and we are recording the gap here rather than citing a row that does not exist.

The other setting in this family is the one people still repeat as folklore. In msconfig → Boot → Advanced options there is a Number of processors box, widely described as unlocking cores that Windows is not using. The element it corresponds to is documented, and the documentation is one sentence: numproc Uses only the specified number of processors. The word is only. It is a cap, it can lower the number of processors the system uses and cannot raise it, and Microsoft’s own caution on that page is that changing some of these options could render the computer inoperable. Row B-01 is NO-OP on that basis. What we do not assert, and what row B-01 is careful about, is any claim about the checkbox itself: Microsoft documents the boot-configuration element, not the msconfig user interface, so the defensible statement is about the element and the direction it can move. Reverting is documented: bcdedit /deletevalue numproc.

§9What makes a boot slow now is mostly work that happens after the kernel is up

Costs after the desktop appears

counted separately, in ms

Costs of a restart

1 full boot · no hibernation file read

Costs in order of frequency

NOT ESTABLISHED — see §9

We cannot rank these by frequency and we are not going to pretend otherwise. Microsoft publishes no first-party distribution of boot-slowness causes across real machines, and any ordering we offered would be an impression. What follows is the list of things the first-party assessment tooling actually looks for, each with the surface a reader can check, and it is ordered from the cheapest thing to check to the most involved.

Startup programs, with numbers. The Task Manager Startup tab and its impact ratings are in §7. That is the intervention knowledgeable users endorse, and the thresholds above tell you which entries are worth the argument.

Reads issued during boot. The Windows ADK’s advanced analysis flags storage use as a first-class boot issue and its worked examples are stated in megabytes and flush counts — a process reading 23 MB during a boot phase, or a summary figure of 275 MB of reads and writes and 82 flushes across a whole transition. Its guidance to developers is specific enough to be checkable: use I/O sizes of 64 KB to 128 KB rather than small disruptive streams, and perform disk flushes only when necessary.

Managed code in the boot path. The same reference singles this out: .NET Common Language Runtime processes start during Windows boot, and the files the framework reads during runtime initialisation can add megabytes of storage reads that delay the boot process. Its recommendation to vendors is to avoid non-essential managed code in the boot path and to move the work to a scheduled or triggered task — which is the same architectural answer as the trigger-start services in what a service costs when it is doing nothing.

Work that continues after the desktop appears. This is the one most complaints are actually about. Post-boot duration is defined as time to complete all startup tasks after the desktop appeared, and the severity thresholds in §6 treat 30 and 60 seconds of it as escalating problems. A machine that reaches the shell quickly and is unusable for a minute is failing on the second number.

Whether it was a boot at all. Since Windows 8 a shutdown is a hybrid shutdown: Windows closes all applications, logs off all user sessions, then saves the kernel memory image including loaded kernel-mode drivers to Hiberfil.sys, and the next start loads that file rather than constructing a kernel image from scratch. Microsoft states three things about it that belong together and are usually separated: Fast Startup is enabled by default in Windows; the Fast Startup setting does not apply to Restart, so a restart performs a full boot cycle without the improvement; and disabling Fast Startup is not recommended. Row B-03 is SUPERSEDED for the vendor claim in this area, and the measurement consequence is blunt: a boot figure from before 2012 and a boot figure from after it are timing two different operations, so the comparison is void unless the method says which one it measured. Article what Windows 8 changed that broke the tweak industry takes that discontinuity apart.

On a domain-joined machine, policy. Fast Logon Optimization is on by default for domain and workgroup members, which applies policy asynchronously at startup and logon; it is disabled by roaming profiles, home directories and synchronous logon scripts, and administrators can turn it off deliberately with Always wait for the network at computer startup and logon. A managed machine that waits at startup is frequently doing what it was told to do, and no cleaning product can see that from a file list.

§10Standing: what this page establishes and what it does not

Costs in primary sources

17 cited, all accessed 2026-08-06

Costs in unresolved rows

2 UNVERIFIED of 8 touched

Costs we measured ourselves

0 — we run no software

§11Sources & method: every claim above, with the page it came from

Costs in fetches

17 sources, fetched 2026-08-06

Costs in vendor prose republished

0 sentences · 3 quotes, ≤22 words each

Costs in screenshots

0, permanently

Method, plainly: every page below was fetched and read on 2026-08-06, and the three archived vendor pages were fetched from the Internet Archive on the same date at the capture URLs printed in the claim cards. Where a mechanism is described only in archived Microsoft material — Layout.ini, ReadyBoot’s training, the event 100 fields — the age and the archive status of the source is stated in the sentence that uses it rather than left for a reader to discover. Nothing here was measured by us: this page contains no timings and no benchmark, because we do not run the software this category sells and we have never run Windows Winset.

1. Mark Russinovich, Sysinternals Newsletter Vol. 3, No. 2, 2001-08-20, hosted on learn.microsoft.com — the prefetching section, with the trace durations, the .pf naming rule, NTOSBOOT-B00DFAAD.PF and the Layout.ini defragmenter pass. Accessed 2026-08-06
2. What is Application Launch Prefetching?, archived Microsoft blog, ms.date 2014-03-14 — the ten-second monitor, the SysMain ownership, the 72-hour Layout.ini regeneration and the 10–80% claim. Accessed 2026-08-06
3. ReadyBoot Analysis (Windows Performance Toolkit, archived). Accessed 2026-08-06
4. ReadyBoot Summary Table — prefetch-hit and request-hit ratios, cache release time. Accessed 2026-08-06
5. Prefetching in Windows 7, Teil 1 — ReadyBoot, archived Microsoft blog in German, ms.date 2012-11-11 — the five-boot training and the boot plan. Accessed 2026-08-06
6. Quick Start: Capturing ReadyBoot Information — xbootmgr boot tracing. Accessed 2026-08-06
7. The Boot Prefetch Action — the ReadyBoot event types hit, prefetch, miss, pend and write. Accessed 2026-08-06
8. defrag, ms.date 2023-09-28 — /b boot optimization and the scheduled-task cadence. Accessed 2026-08-06
9. Support and Q&A for Solid-State Drives, Engineering Windows 7 blog, 2009-05-05 — the SSD auto-disable of Superfetch, ReadyBoost and prefetching, and the 8 MB/s random-read threshold. Accessed 2026-08-06
10. Guidance on configuring system services (Windows IoT Enterprise), ms.date 2026-06-24 — SysMain, Automatic, Don’t disable. Accessed 2026-08-06
11. On/Off Transition Performance (Windows ADK) — Main Path Boot Duration, Post On/Off Duration, Total Boot [Excluding BIOS] Duration, and the note that restart is a full reboot when fast startup is off. Accessed 2026-08-06
12. Common In-Depth Analysis Issues (Windows ADK) — managed code in the boot path, storage-use examples, I/O size guidance. Accessed 2026-08-06
13. Diagnostics-Performance log Event 100 — Critical, Error, or Warning: when and why?, archived MSDN forum thread, 2010-11-17. Carries an as-is, no-warranties disclaimer and is the only Microsoft-hosted text we found relating the event 100 fields. Accessed 2026-08-06
14. Startup apps (Windows 8 developer cookbook) — the three covered locations and the impact thresholds. Accessed 2026-08-06
15. Configure Windows to automate logon (KB 324737), ms.date 2026-02-12 — plain-text password storage, remote readability by Authenticated Users, and the Autologon LSA-secret alternative. Accessed 2026-08-06
16. BCDEdit /set, ms.date 2022-03-16 — numproc, and the caution about rendering a computer inoperable. Accessed 2026-08-06
17. Fast startup causes hibernation or shutdown to fail (KB 3211190), ms.date 2026-02-12, and Distinguishing Fast Startup from Wake-from-Hibernation — the hybrid shutdown sequence and the Restart exception. Accessed 2026-08-06
18. Logon Optimization (archived) — Fast Logon Optimization defaults and Always wait for the network at computer startup and logon. Accessed 2026-08-06

Previous · What a service costs when it is doing nothing — an idle service costs a countable number of threads, handles and kilobytes, and here is how to count them on your own machine.

Next · What “junk files” actually are, and what Windows already deletes — a third of what a cleaner reports as recoverable is already scheduled for deletion or is not there at all.