How to Diagnose Slow Windows 11 Boot Times with Event Viewer

His timings come from one machine. They show how to read the log, not what a typical Windows PC does.

Where Windows keeps the boot timings​

The data lives in a log called Diagnostics-Performance/Operational. Windows records performance diagnostics events there. In Event Viewer, open Applications and Services Logs, then Microsoft, then Windows, then Diagnostics-Performance, and click Operational.

Here is the procedure the author used, which needs no extra software and no Terminal:

1. Press Win + R, type eventvwr.msc, and press Enter.
2. Expand Applications and Services Logs > Microsoft > Windows > Diagnostics-Performance > Operational.
3. Choose Filter Current Log in the right-hand pane and enter 100-199 in the Event IDs box.
4. Select the most recent Event ID 100 record. The General tab shows the boot duration.
5. Open Details > XML View to see how that time was divided.

The author says the Operational log may be switched off, in which case you have to enable it before it can record your next reboot. His write-up doesn't say how to do that, so I won't guess at steps. He also notes that the history is a rolling one, not a permanent record. If you're chasing a slow boot, check soon after it happens.

What the Event 100 numbers mean​

Event 100 is the boot summary. The event text reads "Windows has started up". A sample record documented by the DFIRHub reference lists these timing fields in the XML:

• BootTime: the total, in milliseconds.
• MainPathBootTime: the part of boot before the desktop is ready. The author describes this as excluding firmware initialization.
• BootPostBootTime: work that continues after the desktop appears.
• BootExplorerInitTime: how long Explorer took to initialize.
• BootNumStartupApps: how many startup apps there were.
• BootIsDegradation: whether Windows flagged the boot as degraded.

The sample record also includes root-cause bits and a degradation delta. That suggests Windows does its own comparison against a baseline. A community reference says that when Event 100 appears with no follow-up warnings, the boot was slow but Windows didn't isolate a specific cause.

The main practical point is to compare the two big phases. If most of the time is in the main path, the delay comes before you can use the desktop. If it is in post-boot, Windows is still busy after the desktop appears. The author's first record was 123,343 ms, about 2 minutes 3 seconds. That split into 71.6 seconds main path and 51.7 seconds post-boot. His Explorer initialization took 43.4 seconds, and a record from two days earlier showed almost the same. That repeat made Explorer a place to start looking, though it did not say what was holding Explorer up.

Reading the warnings next to Event 100​

The nearby warnings are the ones that name a component. Event Log Explorer's older write-up of the log lists them:

• 101: an application took longer than usual to start.
• 102: a driver took longer to initialize.
• 103: a startup service took longer than expected.
• 104: the core system took longer to initialize.

That matches the author's list of 101 for apps, 102 for drivers and 103 for services. A sample Event 101 record in the DFIRHub reference includes a start time, the executable name and path, a TotalTime and a DegradationTime. Its example is svchost.exe.

Some rules for using these warnings:

• Don't add the numbers up. Components can start at the same time, so the figures overlap.
• Look for repeats. The author found Microsoft Defender's engine (MsMpEng.exe) flagged at 21.3 seconds, with 16.3 seconds marked as degradation. An older boot showed a similar 17.1-second delay. Repetition made it a better lead than a one-off.
• Don't disable security software on a hunch. The author chose to leave his antivirus alone. That is sensible.
• Check what happened just before the boot. One of his boots flagged Microsoft Edge at 36.6 seconds, with 31.6 seconds of degradation. It was his slowest, at 148.6 seconds. He had just installed a Windows update, and Edge opened by itself to show what had changed. After another restart the total fell to 114.4 seconds and Edge no longer appeared in the warnings.

That Edge case shows why the context matters. A post-update boot is an unusual boot, and it can send you after the wrong suspect.

Use Restart, not Shut down, for comparisons​

Fast Startup can distort comparisons. Microsoft's documentation says nothing about that, but its Learn article explains the mechanism. Fast Startup saves the kernel session and drivers to the hibernation file instead of closing them at shutdown. Microsoft also states that the setting doesn't apply to Restart, and that Restart continues to perform a full boot cycle. In practice, a restart and a shutdown followed by power-on take different startup paths. If you compare them you are not measuring the same thing, so use Restart every time.

A reversible test that came out inconclusive​

CrossDeviceService.exe, Microsoft's Cross Device Service, showed up in two consecutive restarts. Its degradation was 4.7 seconds and then 7.0 seconds. The author uses Phone Link with a Samsung phone. Under Settings > Bluetooth & devices > Mobile devices, he turned off the option that lets Windows access the phone's content and features. Then he restarted and checked Event 100 again.

The main path dropped by 11.5 seconds and the service left the warnings. Post-boot time rose by 7.3 seconds, so the total improved by only about four seconds. An earlier restart with the feature still enabled had finished in 110.5 seconds, nearly the same as the "after" result. With one restart after the change, he couldn't credit the setting.

My view is that this is the most useful part of the story. It shows the right way to test: change one optional thing, keep it reversible, and repeat the restart before drawing a conclusion. Nobody should read it as evidence that Phone Link slows boots in general.

A practical workflow​

1. Restart (don't shut down) and open the latest Event 100 record.
2. Compare MainPathBootTime with BootPostBootTime to see which phase is longer.
3. Check whether Event 101, 102 or 103 warnings name anything. A community guide suggests a 101 points to an app, so a startup-apps review is a reasonable response, and a 102 points to a driver, where a rollback or an OEM driver update is the usual route. Those are community suggestions, not Microsoft procedures.
4. Look for the same component across several slow boots.
5. Note whether an update, first-run screen or automatic app launch happened before the boot.
6. Change one optional setting at a time and run several restarts before judging.
7. Leave essential services and antivirus alone unless you have stronger evidence.

When Event Viewer isn't enough​

Event Viewer gives summaries. Sometimes it gives an Event 100 and nothing else. The author's escalation path is the Windows Performance Toolkit, which records a full boot trace. Microsoft describes it as part of the Windows Assessment and Deployment Kit. It includes Windows Performance Recorder for capturing traces and Windows Performance Analyzer for analyzing them. The trace shows CPU, disk and process activity that the summary events leave out. It is a more advanced tool, so I'd treat it as the second step, not the first. I haven't listed capture steps because none were verified for this piece.

The bottom line​

Event Viewer won't fix a slow boot. It does turn "it feels slow" into timings you can compare, and sometimes into names worth investigating. Its interface hasn't aged well. It still beats changing settings on a hunch.