Skip to content

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

bootlag

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

Why this exists

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.

Safety

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.

Requirements

  • 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.

Quick start

# Right-click PowerShell -> Run as administrator
.\bootlag.ps1

That 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-readable

If PowerShell blocks the script:

powershell -ExecutionPolicy Bypass -File .\bootlag.ps1

Looking at someone else's machine

Have them export their log (this needs admin on their machine, not yours):

wevtutil qe Microsoft-Windows-Diagnostics-Performance/Operational /f:xml > boot.xml

Then read it anywhere, with no admin rights at all:

.\bootlag.ps1 -XmlPath boot.xml -All

-XmlPath also accepts a folder of .xml files.

Options

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.

Real output

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.

How it was tested

96 automated checks, 0 failures, across two suites.

Ground truth: 59 checks

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.

Real-world cross-check: 37 checks

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.

Bugs this testing found

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.

Trust checks

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.

FAQ

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.

See also

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

License

MIT. See LICENSE.

About

See exactly which apps and services slow your PC's boot, in milliseconds. Reads Windows' own boot performance telemetry - the real numbers behind Task Manager's vague High/Medium/Low startup impact. Read-only, zero dependencies.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages