See exactly which apps and services slow your PC's boot, in milliseconds.
Windows already measures your boot in forensic detail. Every time you start up it records the length of each phase, and how much time each individual startup app added, then files the whole thing in an event log almost nobody opens.
Task Manager reads a sliver of that data and shows you a shrug: High, Medium, Low. That is not a number. You cannot tell whether "High" means 400 milliseconds or 40 seconds, and you cannot tell whether disabling it will actually help.
bootlag prints the real numbers.
APPS THAT DELAYED YOUR SIGN-IN
name total added where it starts
--------------------------------------------------------------------------
Host Process for Windows Serv. 19.3 s 10.8 s service, driver or scheduled task
Antimalware Service Executable 7.39 s 2.39 s service, driver or scheduled task
NVIDIA Container 4.74 s 2.24 s service, driver or scheduled task
If you record gameplay, stream, or edit video, your PC accumulates launchers, overlays, updaters and helper services. Every one of them asks for a slice of your boot. Individually none of them look guilty. Together they turn a 12-second boot into a 50-second one.
The problem is that nothing tells you the cost. You are invited to guess, disable
things at random, and hope. bootlag replaces the guessing with a measurement that
Windows itself took.
It also separates two numbers that matter, which Task Manager conflates:
- total — how long the item took overall.
- added — how much of that was extra compared with this machine's own baseline.
An app that always takes 4 seconds is predictable. An app that suddenly takes 4 seconds more than it used to is the one that broke your boot last Tuesday.
bootlag is read-only. It opens an event log and reads registry keys to find out where startup entries live. That is all it does.
- It never writes to the registry, disables anything, or deletes a file.
- It cannot break your startup configuration, because it never changes it.
- There is nothing to undo, so there is no undo command. Tools on this profile that change state journal every change first and ship a working undo. This one changes nothing, so it does not need one.
The test suite proves this rather than asserting it: it snapshots every Run key
value before and after a full run and requires them to be byte-identical, and it
greps the source for registry write calls and requires zero.
- Windows 10 or 11, Windows PowerShell 5.1 (the one already on your machine).
- Administrator, because Windows restricts the boot performance log to admins.
- No dependencies. No installer. No modules. One file.
# Right-click PowerShell -> Run as administrator
.\bootlag.ps1That prints the boot timeline and the apps that cost you the most.
.\bootlag.ps1 -All # everything: trend, shutdown, full offender list
.\bootlag.ps1 -Trend # is my boot getting worse over time?
.\bootlag.ps1 -Shutdown # what is holding up shutdown
.\bootlag.ps1 -Top 20 # show more offenders
.\bootlag.ps1 -Json # machine-readableIf PowerShell blocks the script:
powershell -ExecutionPolicy Bypass -File .\bootlag.ps1Have them export their log (this needs admin on their machine, not yours):
wevtutil qe Microsoft-Windows-Diagnostics-Performance/Operational /f:xml > boot.xmlThen read it anywhere, with no admin rights at all:
.\bootlag.ps1 -XmlPath boot.xml -All-XmlPath also accepts a folder of .xml files.
| Option | Meaning |
|---|---|
-Boots <n> |
How many recent boots to analyse. Default 5. |
-Top <n> |
How many offenders to list. Default 10. |
-Trend |
Show boot time across recent boots, with an average. |
-Shutdown |
Include shutdown timings. |
-All |
Trend, shutdown, and the complete offender list. |
-Json |
Emit JSON instead of the human report. |
-XmlPath <path> |
Read an exported XML file or folder instead of the live log. |
Exit codes: 0 clean, 1 problems found, 2 could not run.
From the machine this was developed on. A genuinely unhealthy boot:
bootlag - what is slowing your boot
===================================
BOOT TIMELINE
started 2026-09-08 21:31:37
to desktop 23.8 s ███████████░░░░░░░░░░░░░ 47%
settling 26.9 s █████████████░░░░░░░░░░░ 53%
TOTAL 50.7 s
phases inside "to desktop":
firmware handoff 1.43 s ██░░░░░░░░░░░░░░░░
kernel init 219 ms ░░░░░░░░░░░░░░░░░░
driver init 270 ms ░░░░░░░░░░░░░░░░░░
device init 698 ms █░░░░░░░░░░░░░░░░░
session manager 12.1 s ██████████████████
core services 735 ms █░░░░░░░░░░░░░░░░░
user profile 2.11 s ███░░░░░░░░░░░░░░░
explorer/shell 5.91 s █████████░░░░░░░░░
APPS THAT DELAYED YOUR SIGN-IN
name total added where it starts
--------------------------------------------------------------------------
Host Process for Windows Serv. 19.3 s 10.8 s service, driver or scheduled task
Antimalware Service Executable 7.39 s 2.39 s service, driver or scheduled task
NVIDIA Container 4.74 s 2.24 s service, driver or scheduled task
Windows Explorer 4.22 s 1.72 s service, driver or scheduled task
NVIDIA App 6.45 s 1.45 s service, driver or scheduled task
NVIDIA Container 4.82 s 1.32 s service, driver or scheduled task
Surface Service 1.14 s 138 ms service, driver or scheduled task
[fail] Host Process for Windows Services added 10.8 s to your boot (severe)
[warn] Antimalware Service Executable added 2.39 s to your boot (high)
[warn] NVIDIA Container added 2.24 s to your boot (high)
SERVICES AND SUBSYSTEMS THAT STALLED
name total added where it starts
--------------------------------------------------------------------------
SMSSInit 24.0 s 14.0 s service, driver or scheduled task
[fail] SMSSInit added 14.0 s to your boot (severe)
SHUTDOWN
user session 4.12 s ████████████████████
user profiles 616 ms ███░░░░░░░░░░░░░░░░░
services 1.08 s █████░░░░░░░░░░░░░░░
kernel 2.01 s ██████████░░░░░░░░░░
TOTAL 7.83 s
VERDICT
[warn] 1 app(s) each added 5 seconds or more
[warn] Windows flagged this boot as slower than your baseline
bootlag only reports. To act on this, remove the entry from the
location shown above, or use Task Manager > Startup apps.
Note session manager at 12.1 s — over half the time to desktop, in a phase Task
Manager cannot show you at all.
A healthy boot, for contrast:
VERDICT
[ ok ] Boot looks healthy. Nothing worth changing.
Without administrator rights:
[fail] Administrator required. Windows restricts the boot performance log to
administrators. Close this window, right-click PowerShell, choose
'Run as administrator', and run bootlag again.
96 automated checks, 0 failures, across two suites.
Synthetic boot events are generated with deliberately distinctive planted values, then bootlag's reported numbers are compared against those exact values.
| Planted | Reported |
|---|---|
BootTime 90000 ms |
90000 |
MainPathBootTime 60000 ms |
60000 |
BootPostBootTime 30000 ms |
30000 |
hog.exe total 12345 / added 9999 |
12345 / 9999 |
mid.exe total 5000 / added 1500 |
5000 / 1500 |
tiny.exe total 300 / added 50 |
300 / 50 |
Every app is planted with a different total and added value, so a tool that mixed
those two fields up could not pass. Ranking, severity banding, per-boot scoping and
the trend average (20000, 40000, 30000 → 30.0 s) are all asserted numerically.
It also proves the tool does not cry wolf: a healthy synthetic boot produces
Boot looks healthy, zero warnings, zero failures and exit code 0. A bad one
produces the warnings and exit code 1.
Synthetic fixtures are clean and predictable, which is exactly why they miss things.
So the parser is also run against genuine Windows event XML exported by
wevtutil.exe, and checked against an independent reference parser written with
XPath and a namespace manager rather than bootlag's own technique.
| Check | Result |
|---|---|
| Application log, 60 real events | 60/60 event IDs match, 0 mismatches across 149 real fields |
| System log, 60 real events | 60/60 event IDs match, 0 mismatches across 378 real fields |
Unnamed <Data> elements in real logs |
82 encountered, none crashed or leaked a blank key |
XML entities & < > " ' |
decoded exactly once, not twice |
| Known values planted inside a real System log export | recovered exactly (77777 / 55555 / 22222, 31337 / 27182) |
That last one matters: the planted boot record survives being surrounded by hundreds of unrelated real Windows events, and none of them leak into the results.
Startup locations are cross-checked against Win32_StartupCommand, Microsoft's
own startup enumeration:
Win32_StartupCommand : Discord, MicrosoftEdgeAutoLaunch_..., RtkAudUService,
SecurityHealth, Steam, SurfaceDTX.exe
bootlag index : Discord, MicrosoftEdgeAutoLaunch_..., RtkAudUService,
SecurityHealth, Steam, SurfaceDTX.exe
Exact match, 6 for 6, nothing missed. The matcher then resolves four real
executables (steam.exe, Update.exe, msedge.exe, RtkAudUService64.exe) back to
the precise key they start from, and correctly refuses to invent a match for
programs that are not startup entries.
1. A culture-sensitive string comparison silently corrupted every input file.
The BOM check used .StartsWith([string][char]0xFEFF). In .NET, String.StartsWith(string)
is culture-sensitive by default, and U+FEFF is a zero-weight character — so
"anything".StartsWith(BOM) returns $true for every string. The parser was
chopping the leading < off every file it read. Fixed by comparing the first char
ordinally.
2. bootlag told standard users their boot data did not exist.
Get-WinEvent returns "No events were found that match the specified selection
criteria" for a log the caller has no permission to read — indistinguishable from a
genuinely empty log. So without admin, bootlag cheerfully reported "Windows has not
recorded any boot performance data yet". That is a confidently wrong diagnosis,
which is worse than no diagnosis. It now probes readability first and says
Administrator required. This bug was only reachable without elevation, so a
test run purely in an elevated shell would never have found it.
3. Offenders from previous boots polluted the current one.
Event 101 records carry the StartTime of the boot they belong to. Without filtering
on it, apps from older boots piled into the list and overstated the damage. Now
scoped per boot, and asserted with a three-boot fixture.
The tool refuses to report numbers it cannot verify. Event 100 carries redundant
fields: BootTime must equal MainPathBootTime + BootPostBootTime. If that identity
fails, the record is flagged rather than reported:
[fail] Boot record failed its own consistency check: BootTime 99999 != MainPath 60000 + PostBoot 30000 = 90000
Refusing to report timings from a record that does not add up.
Values that will not parse as numbers become -, never 0, so "unknown" can never
masquerade as "instant". Corrupt XML, a missing path and an empty file each produce a
single clean line and never a red stack trace, in both human and -Json mode.
Do I have to run it as administrator?
For the live log, yes — that is a Windows restriction, not a bootlag one. Use
-XmlPath with an exported file to read data without any elevation.
It says there is no boot performance data. Windows only writes these records on a real boot. If you always sleep or hibernate, or the log was recently cleared, there may be nothing yet. Restart once and try again.
Why is svchost.exe always near the top?
It hosts many Windows services at once, so it accumulates their startup cost. Treat it
as a signal that something inside it is slow, not as something to disable. Never
disable svchost.exe.
Fast Startup is on. Are these numbers real? Yes, but they describe the hybrid resume rather than a cold boot. For a true cold boot measurement, use Restart, which bypasses Fast Startup.
Will this make my PC faster? By itself, no — it changes nothing. It tells you precisely where the time goes so you can make an informed decision instead of a superstitious one.
Why do some entries say "service, driver or scheduled task"?
Because they are not in a Run key or Startup folder. Services and drivers start
through different mechanisms; bootlag reports the cost and is honest that the entry
does not live somewhere it can point you to.
Part of a set of Windows tools for gamers, streamers and creators:
- obs-4k60-recorder — record gameplay at native resolution and 60fps
- gamemode — free your PC for gaming, then put it all back
- miccheck — audit your audio setup before you hit record
- framecheck — diagnose a recording before you edit it
- pathfix — audit and repair your Windows PATH
- diskscout — find what is actually eating your disk
MIT. See LICENSE.