Slow Windows Boot? Here’s How to Trace It With Microsoft’s Windows Performance Toolkit

When a Windows PC keeps churning well after you’ve logged in, neither the startup apps list nor Autoruns can tell you what’s going on. A free Microsoft utility, the Windows Performance Toolkit, can capture a complete boot trace that shows when every service and driver started and how their work overlapped. Use it to work out which layer needs attention: services, storage or hardware. It isn’t a shortcut for finding a single app to blame.

Why startup tools can’t explain a slow boot

Autoruns and the startup list in Task Manager show what’s configured to launch. They can’t show when each entry actually started, how long it ran or what else was happening alongside it.

Windows can bring up the desktop while plenty of startup work is still going on in the background. In one example, an 8GB Core i5 laptop showed its desktop after roughly 25 seconds, yet the boot trace revealed substantial activity continuing past that point. That lingering busyness is exactly what startup lists can’t account for.

Because a boot trace logs activity across several layers at the same time, it captures work that ordinary startup views never measure.

Capture a full boot trace

Everything you need ships with the Windows Performance Toolkit, a component of the Windows ADK (Assessment and Deployment Kit, Microsoft’s free collection of deployment and testing tools).

1. Install the Windows Performance Toolkit as part of the Windows ADK.
2. Run xbootmgr to record a trace covering a complete boot.
3. Run xperf to extract reports from the trace file, among them the service initialization report and the driver-delay report.
4. For boot phase data, which can reveal when Explorer initializes, load the trace in WPA (Windows Performance Analyzer).

Check that you have lots of free disk space before you begin. A single boot trace on the 8GB Core i5 laptop weighed in at about 1.07 GB, which is a sizable amount of data to sift through.

Interpret the service initialization report

This report lists the time each service needed to initialize, and it may turn up lengthy intervals for services you’ve never given a second thought. In the example trace, these five took the longest:

• HNS: 9.648s (virtual networking)
• DellClientManagementService: 6.906s (Dell’s management tool)
• IntelAudioService: 5.641s (audio)
• DusmSvc: 5.574s (data usage tracking)
• BITS: 4.757s (background downloads)

Resist the urge to total these figures. Since the intervals overlap, their sum won’t match your boot time. Each value reflects how long that particular service spent initializing, not how long it kept you waiting for the desktop.

Nor will the services appear as one tidy cluster. In the example, BITS sat lower in the report, while DellClientManagementService turned up considerably later. Windows doesn’t run through a single startup list in order; separate batches of work kick off and overlap at different moments.

Interpret the driver-delay report

Rather than whole services, the driver-delay report lists individual events. The biggest entries won’t necessarily come from third-party software. In the example trace, core Windows components accounted for the largest events:

• FLTMGR.SYS: about 799ms (file system filtering)
• FLTMGR.SYS: about 552ms (file system filtering)
• FLTMGR.SYS / Ntfs.sys ($Mft): about 415ms (file system bookkeeping)
• storport.sys: about 295ms (storage stack)
• pci.sys: about 268ms (hardware bus)

Just like the services, these events overlap, so totaling them won’t produce your boot time. All of the top three sit in the file system stack, and one involves $Mft, the NTFS Master File Table that holds information on every file and folder on the drive. The remaining two relate to the storage stack and the PCI bus.

ACPI.sys, a low-level component responsible for power management and hardware configuration, may also appear. Commonly blamed drivers such as Netwtw08.sys (Wi-Fi), TbtBusDrv.sys (Thunderbolt) and RtsPer.sys (card reader) registered only as far smaller events in the example, and no third-party driver stood out.

Let the trace point to a layer, not a culprit

It’s tempting to hope a single service or driver will jump out so you can disable it and move on. That rarely happens. What you’ll more likely find is service startups, driver events and storage activity overlapping throughout the trace.

A lengthy service interval, a lengthy driver event and a late-starting service are three separate things, and none of them proves that the item held up your desktop. The xperf reports record what occurred and when, but by themselves they can’t tell you which events caused the sluggishness after login.

Treat a large number as a lead worth investigating, not as evidence:

• Don’t switch off a service simply because it tops the list. HNS, for instance, is a Windows networking component that supports features like virtualized and container networking. A long initialization time alone isn’t grounds for disabling it.
• Don’t uninstall or attempt to repair a driver just because a large event appears beside it. A big FLTMGR.SYS event doesn’t indicate that FLTMGR.SYS is faulty.
• Disabling a service because it ranks highly could break a feature you’ll need down the line.

So instead of asking which app is dragging your PC down, ask which layer merits closer inspection: services, storage or hardware. Then dig into that layer before making any changes.

Frequently asked questions

Can I add up the service times to get my total boot time?

No. Because services and driver events overlap, summing their durations won’t give you your boot time. Each figure reflects only how long that single item took.

Should I disable HNS if it has the longest startup time?

Not on the basis of its startup time alone. HNS powers virtualized and container networking, and disabling it could break features you’ll need later.

How is a boot trace different from Autoruns?

Autoruns lists what’s configured to launch with Windows. A boot trace reveals when each service and driver actually started and how their work overlapped.

How big is a boot trace file?

Potentially very large. One boot trace captured on an 8GB Core i5 laptop came to about 1.07 GB.