After the third “slow login” ticket in a week from one of our managed customers, I went back to Sysinternals boot logging because nothing else was going to give me what I needed. Event Viewer was clean. Performance Monitor showed CPU spikes during winlogon but no process attribution. The only tool that catches what happens before the desktop appears is Procmon’s boot driver, and it has been my go-to for this class of problem for over a decade.
Here is the position I will defend in this post: if you are diagnosing a Windows boot, service initialization, or logoff problem on a production server, Procmon boot logging beats every other free tool by a wide margin. ETW traces collected with WPR are technically more capable, but the analysis curve is steep and the output is opaque to most engineers on a help desk rotation. Procmon’s boot log is something a competent admin can read in an hour.
Why Boot Logging Exists
Procmon’s normal capture mode assumes you are sitting at an interactive desktop. That covers maybe sixty percent of real troubleshooting work. The other forty percent — boot-start drivers, autostart services, the logon sequence, shell initialization, scheduled tasks that run before anyone signs in, shutdown hangs — happens when no user is present to launch a tool.
Boot logging solves this by configuring Procmon’s driver to load as a boot start driver on the next system startup. It loads very early, before most other drivers, and writes activity to %windir%\Procmon.PMB. The log continues through shutdown or until you run Procmon again. If you do not launch Procmon during the session, you capture the entire boot-to-shutdown cycle.
One detail that catches people: it is a one-shot. After the boot driver loads, it reconfigures itself to demand-start for subsequent boots. You have to re-enable boot logging each time you want it. This is a feature, not a bug — you do not want a 1.3 GB trace file generated on every reboot of a production host.
The Workflow I Actually Use
Here is the sequence, no more, no less.
Launch Procmon with Procmon /noconnect so it does not start capturing on the desktop. From the Options menu, choose Enable Boot Logging. The menu shows a check mark when it is on. Reboot. Sign in. Wait for whatever you are diagnosing to actually happen — slow login, hung service, whatever. Run Procmon again. It detects the unsaved boot log and prompts you to save the processed output file somewhere. Choose a path with plenty of free space.
You can also enable it non-interactively with Procmon /EnableBootLogging, which is what I bake into our remote scripts when we cannot sit at the console. We push that out via Group Policy startup script for fleet-wide captures during a known-bad window.
Note: if you do not save the boot log to another location, it will be overwritten the next time you capture a boot-time log. I have lost more than one trace by forgetting this.
A Real Case: The Four-Minute Logon
A regional bank we support had logon times creeping past four minutes on their RDS hosts. Group Policy processing looked normal. UE-V was off. The CIO was asking whether we needed to re-image. We told him to wait twenty-four hours.
We pushed Procmon boot logging to one of the affected hosts overnight. The next morning the captured log was over 1.3 GB and spanned four files. Procmon handles multi-file boot logs gracefully — it stitches them in the UI when you load the first one.
The Process Tree was where the answer lived. We opened it and scrolled through the early-session processes. A cluster of msiexec, regsvr32, and vendor installer EXEs had executed for about four minutes and finished less than a minute before the desktop became responsive. Clicking through the command lines told the story: the endpoint security agent was reinstalling itself on every logon because a prior uninstaller had left a registry marker the installer interpreted as “not present.” Vendor support had been chasing it as a profile problem for three months.
The fix was a single registry key. The diagnosis was Procmon boot logging. Total engineer time on our side was about ninety minutes from log capture to root cause.
What Boot Logging Does Not Capture
This is where I push back on people who treat Procmon as a complete answer. It is not.
Network events are not captured in boot logs. The tracing of network events depends on Event Tracing for Windows, and the Procmon boot driver does not have ETW available that early. If your problem is a hung network drive map or a slow Active Directory query during logon, you will see the process making the call but you will not see the wire-level detail. For that, you still need a packet capture or a separate ETW trace from comparable platform tooling on the server side if the target is a Linux file server.
Process and Thread Profiling events are also not captured during boot logs. If you need stack walks to attribute CPU usage inside a single process, you need WPR or xperf, not Procmon.
Activity from the System process — which is most of what runs in the first few seconds — is filtered by default. You have to choose Advanced Output on the Filter menu to see it. I have watched senior engineers spend twenty minutes wondering why their boot log “starts at fifteen seconds in” when the answer is that they never enabled Advanced Output.
Procmon does not configure its boot logging to run during Safe Mode. If your problem reproduces only in Safe Mode, you are out of luck.
When Boot Logging Saves You From a Hang
The single best property of boot logging is that it is tolerant of hard resets. If the system hangs during boot or shutdown, the log written so far is still on disk and recoverable. This is the only Procmon mode where a brutal power cycle does not lose your data.
If you configure boot logging and the system crashes early enough that you cannot get to the desktop, you can deactivate it by pressing F8 during startup and choosing the Last Known Good option. That reverts the driver registration and lets you boot normally. I have used this exactly once on a customer host and it saved a four-hour drive.
For long-running shutdown traces, boot logging is also the only Procmon option that captures events very late in the shutdown sequence. The driver remains loaded almost until the kernel halts. The downside is that you also capture the entire boot session leading up to it, which is often more data than you want. If you only need post-logoff and not the full boot, there are other ways to keep Procmon running across logoff — but for shutdown specifically, boot logging is the cleanest path.
Where This Fits in a Bigger Toolbox
I do not use Procmon for everything. For autostart inventory, Autoruns is faster. For service-specific timing, the built-in sc commands and Performance Monitor’s Service Control Manager counters are lighter weight. For correlating boot timing across a fleet, we feed structured events into our SIEM — and our approach to that is closer to what we covered in MITRE ATT&CK Mapping in Sentinel Detection Rules than to anything Procmon-shaped.
For the inverse problem — figuring out which PowerShell properties to extract from a captured event set — PowerShell Select-Object is what we hand to junior engineers before we let them touch a Procmon trace.
Procmon boot logging is the right tool when you have one host, one symptom, and you need attribution back to a specific process or driver event with timestamps. That is a narrow but very common need.
Storage and Performance Caveats
The boot log can grow large quickly. The bank case produced 1.3 GB. We have seen 4 GB on busier hosts running endpoint protection, backup agents, and a chatty third-party service stack. Make sure the system drive has enough free space before you enable boot logging, especially on the smaller OS disks we sometimes inherit on legacy VPS instances.
The capture itself adds measurable overhead during boot. On a healthy host this is in the noise. On a host that is already slow to boot, it can add fifteen to thirty seconds. If you are timing the boot for benchmarking, do not benchmark with Procmon enabled.
One more thing — back up the host before you reboot for a capture. Boot-start driver changes are low-risk, but “low-risk” is not “zero,” and a recent restore point or image is cheap insurance. We bake this into every engagement and it is part of how we structure our backup approach for managed customers. Tools like Veeam make application-consistent snapshots before scheduled maintenance windows.
The Counterargument I Hear Most
The pushback on Procmon boot logging from newer engineers is usually some version of “why not just use WPR and the boot scenario in the Windows Performance Toolkit?” It is a fair question. WPR captures more, the analysis tooling in WPA is genuinely powerful, and the SANS Windows forensics curriculum leans heavily on it.
My answer: WPA has a learning curve measured in weeks, not hours. For a help desk team that needs to triage a slow-logon ticket today, Procmon’s Process Tree and filter-by-process workflow is teachable in an afternoon. The right tool is the one your team can actually use under pressure. Industry analysis from Gartner on IT operations tooling consistently lands on the same conclusion — adoption beats capability for most shops.
I keep WPR for the cases where Procmon hits a wall. That is maybe one case in twenty.
Practical Takeaway
If you are not already using Procmon boot logging on production troubleshooting calls, add it to your runbook this week. Enable it with Procmon /EnableBootLogging, reboot, reproduce, save the log to a separate path immediately, and start your analysis in the Process Tree, not the event grid. Turn on Advanced Output before you decide there is a gap in the trace. Re-enable it explicitly for every capture — it does not stick.
If you want help setting this up across a fleet, or you have a slow-boot problem you cannot pin down, our team does this work daily — get in touch. The Sysinternals reference documentation on Microsoft Learn covers the command-line switches and filter options if you want to go deeper.
