Diagnose Slow Windows 10 and 11 Startup with Boot Traces, WPA and Xbootmgr

What he found was not one villain. It was a pile of overlapping work. The result is a useful way to think about slow startup, and a reminder to read a trace carefully.

What he captured, and how​

Onyimadu used xbootmgr to record the boot and xperf to pull reports out of the trace. On his 8 GB Core i5 laptop, the trace file was about 1.07 GB. By his account, Windows reached the desktop in roughly 25 seconds, but the trace showed plenty of work continuing after that.

All the numbers below come from his single machine. Nobody has independently reproduced them. Treat them as a case study, not as expected timings for your PC.

The tooling itself is documented by Microsoft. Windows Performance Analyzer (WPA) can open recordings created with Xperf, Xbootmgr, or WPR, as well as recordings from the Assessment Platform. Microsoft's technical reference adds that the toolkit's recorder still supports command-line recordings made with Xperf.exe and Xbootmgr.exe. Microsoft also says Xperfview is no longer supported and that recordings should be opened in WPA.

The service report: long intervals, with a caveat​

The first report listed service initialization intervals. These were the five longest:

The caveat matters more than the table. These intervals overlap, so you can't add them up to get total boot time. An interval also shows how long a service took to initialize. It does not show how long the service held up the desktop.

That is the gap between a trace and a startup list. Autoruns tells you what is configured to launch. A trace tells you when things actually started and how they overlapped.

The driver-delay report: the surprise is the boring stuff​

The second report showed individual driver events, not whole services:

Onyimadu says he also saw ACPI.sys. The drivers he expected to be suspects were only small events. Those were Netwtw08.sys (Wi-Fi), TbtBusDrv.sys (Thunderbolt) and RtsPer.sys (card reader). None of the third-party drivers stood out in his trace.

The same overlap warning applies. A big FLTMGR.SYS event doesn't mean the filter manager is broken. It shows that file system activity was heavy at that moment. Filter drivers, including security software, sit in that path, so this is a layer to investigate, not a component to remove.

Why a long number isn't a verdict​

Onyimadu's main point is that a long interval, a long event and a late appearance in a report are three different things. None of them proves a delayed desktop. Microsoft's own documentation supports that distinction.

• Explorer initialization is its own phase. Microsoft defines it as the time from the end of Winlogon until Explorer reports an initialized Start Screen. That is not a verbatim quote of Microsoft's wording. The same Microsoft page also says this phase covers userinit.exe launching Explorer and RunOnce startup items, and that competing I/O can delay it.
• "Desktop visible" and "machine settled" are different measurements. Microsoft's Fast Startup exercise notes that Explorer initialization and everything after it, known as post on/off, can be affected by processes started at boot.
• Contention shows up in CPU and disk graphs. Microsoft's guidance says high CPU use by one process can delay others. It also says storage contention lengthens activity durations.

So the sensible next step is correlation. Take a suspect service or driver event and check it against the boot phase and the CPU and disk activity during the period that felt slow. Don't act on a ranking of durations alone.

Don't disable HNS just because it's first​

HNS topped the service table, and it's tempting to switch it off. Onyimadu declines to, and he's right. Microsoft's container networking documentation says HNS and the Host Compute Service work together to create containers and attach endpoints to a network. That is a paraphrase of Microsoft's description of the Host Networking Service. HNS also creates Hyper-V virtual switches for networks.

This supports the "virtual networking" label. It does not show that his laptop was using containers during that boot. It also does not show that HNS caused any perceived delay. A long initialization time is a reason to look closer, not a reason to disable the service.

How to run a boot trace yourself​

Here is the general approach, based on Microsoft documentation and Microsoft-hosted guides. I haven't run it for this article, and exact options vary by toolkit version.

1. Install the Windows Performance Toolkit. It comes with the Windows ADK. Microsoft's ADK page currently lists ADK 10.1.26100.9457 (September 2026), which supports Windows 11 versions 26H2, 25H2 and 24H2 plus earlier supported Windows 10 and 11 releases. One Microsoft-hosted older guide says you can deselect everything except the Windows Performance Toolkit during setup.
2. Run an elevated command prompt in a folder with plenty of space. Traces get large. Onyimadu's was over 1 GB.
3. Start the boot trace. Microsoft's legacy quick start documents xbootmgr -trace boot, which initiates the reboot. By default it enables the NT Kernel Logger with a core set of events: process and thread activity, image loads, disk I/O, hard faults, sampled CPU profile, memory information and context switches. Be ready for the machine to restart immediately.
4. Log in and wait. After the reboot, xbootmgr launches and counts down before saving the trace. Older Microsoft blog guides describe a default of about 120 seconds. Microsoft's quick start suggests auto-logon can help boot tracing, so a mistyped password doesn't spoil the run.
5. Open the ETL file in WPA. Don't use the retired Xperfview. Look at the boot phases, especially Explorer Initialization, then at CPU and disk activity.

Microsoft's WPR route is a documented alternative. In the Fast Startup exercise you pick the First Level Triage and CPU Usage profiles, set the scenario to Fast Startup, set iterations to 1, and save. The system reboots to gather the trace. Then you wait about five minutes and open the result in WPA.

Two cautions. Microsoft's xbootmgr page was last updated in 2018, so check xbootmgr -help on your installed version. One forum user on an HDD system reported odd boot behavior after experimenting with the older ReadyBoot training procedure. Create a restore point first.

What to take from it​

Onyimadu's trace didn't hand him a fix. It changed his question from which app is slowing the PC down to which layer deserves a closer look: services, storage or hardware.

There are limits to his report. It covers one machine and doesn't say which Windows build or toolkit version he used. It includes no repeat runs and no before-and-after test. His conclusions are cautious, and that is the sensible stance. A trace gives you evidence about what happened and when. Working out which event made the desktop feel slow takes the extra step of lining up phases, CPU and disk.

If you try this yourself, make one change at a time and re-trace. Keep every change reversible, and don't disable a service or driver because it sits at the top of a table.