If your Windows PC still feels busy long after the login screen, a startup apps list or Autoruns won’t show you why. Microsoft’s free Windows Performance Toolkit can record a full boot trace that shows when each service and driver started and how their work overlapped. Use it to find which layer to look at: services, storage or hardware. Don’t treat it as a quick way to find one app to blame.
Why startup tools don’t explain a slow boot
Task Manager’s startup list and Autoruns show you what’s configured to start. They don’t tell you when each item started, how long it took or what else was running at the same time.
Windows can reach the desktop and still have a lot of startup work going on in the background. On one 8GB Core i5 laptop, the desktop appeared after about 25 seconds, but the boot trace showed a lot of work carrying on after that. That’s the busy feeling startup lists can’t explain.
A boot trace records what’s going on across several layers at once, so you can see work that normal startup views never time.
Record a full boot trace
The tools you need come with the Windows Performance Toolkit, which is part of the Windows ADK (Assessment and Deployment Kit, Microsoft’s free set of deployment and testing tools).
- Install the Windows Performance Toolkit from the Windows ADK.
- Use
xbootmgrto capture a trace of a complete boot. - Use
xperfto pull reports out of the trace file, including the service initialization report and the driver-delay report. - Open the trace in WPA (Windows Performance Analyzer) if you want boot phase data, which can show when Explorer initializes.
Make sure you have plenty of free disk space first. On that 8GB Core i5 laptop, one boot trace came to about 1.07 GB, which is a lot of data to work through.
Read the service initialization report
This report shows how long each service took to initialize. You may find long intervals on services you’ve never thought about. These were the five longest in the example trace:
- 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)
Don’t add these numbers together to get a total. The intervals overlap, so the sum won’t equal your boot time. Each number shows how long that service took to initialize, not how long it held up your desktop.
The services also won’t show up in one neat group. In the example, BITS was further down the report and DellClientManagementService appeared much later. Windows doesn’t work through one startup list from top to bottom. Different groups of work start and overlap at different points.
Read the driver-delay report
The driver-delay report breaks things down into individual events instead of whole services. Third-party software may not be the biggest item. In the example trace, the largest events came from core Windows components:
- 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)
As with services, these events overlap, so you can’t add them up to get boot time. The top three all belong to the file system stack. One of them involves $Mft, NTFS’s Master File Table, which stores information about every file and folder on the drive. The other two belong to the storage stack and the PCI bus.
You may also see ACPI.sys, a low-level component that handles power management and hardware configuration. Drivers that often get blamed, such as Netwtw08.sys (Wi-Fi), TbtBusDrv.sys (Thunderbolt) and RtsPer.sys (card reader), showed up only as much smaller events in the example. No third-party driver stood out.
Use the trace to pick a layer, not a culprit
You might expect one service or driver to stand out so you can turn it off and be done. Usually that doesn’t happen. You’re more likely to see services starting, plus driver and storage events, overlapping across the whole trace.
A long service interval, a long driver event and a service that appears late are three different things. None of them proves that item delayed your desktop. The xperf reports show what happened and when. On their own, they don’t tell you which events caused the slowdown after login.
Read a big number as a lead to follow up, not as proof:
- Don’t disable a service because it’s at the top of the list. HNS, for example, is a Windows networking component used for features such as virtualized and container networking. A long initialization time isn’t a reason on its own to turn it off.
- Don’t remove or try to fix a driver because a big event sits next to it. A large FLTMGR.SYS event doesn’t mean FLTMGR.SYS is broken.
- If you turn off a service because it ranks high, you could break a feature you need later.
Instead of asking which app is slowing your PC, ask which layer deserves a closer look: services, storage or hardware. Then look into that layer before you change anything.
Frequently asked questions
Can I add up the service times to get my total boot time?
No. Services and driver events overlap, so adding their times together won’t give you your boot time. Each figure only shows how long that one item took.
Should I disable HNS if it has the longest startup time?
Not just because of its startup time. HNS handles virtualized and container networking, and turning it off could break features you need later.
How is a boot trace different from Autoruns?
Autoruns shows what’s set to start with Windows. A boot trace shows when each service and driver actually started and how their work overlapped.
How big is a boot trace file?
It can be large. A single boot trace on an 8GB Core i5 laptop came to about 1.07 GB.
