Tracing Slow Logons and Battery Drain on Windows, Before the Desktop Appears

September 4, 2026 · InfraScout Team

A laptop takes minutes to reach a usable desktop, its fan runs at idle, and the battery empties by lunchtime. Or a sign-in flow that should work doesn't, and the moment that matters happens at boot, before any tracer can attach. Hand either problem to InfraScout in a chat, and you get a ranked list of causes that separates the real problems from the behavior Windows is expected to show. The capture that produced it is bounded, verified, and cleanly removed afterward.

The scenarios below are a composite of a common pattern: a Windows laptop or VM investigated for performance and battery life, then for boot, logon, and authentication delays.

Start with the symptom

Describe what the user notices, say which path you suspect, and state how much the AI may change.

One of our Windows laptops is slow to sign in and the battery drains fast.
Find out what is causing it. Stay read-only, ask me before any reboot,
and don't change anything without my approval.

The AI first resolves the machine to a registered agent and confirms that the agent is online and supports live tracing, boot capture, and performance counters. If the name you typed matches no agent, it doesn't guess. It proposes a likely match from its memory and waits for you to confirm before arming anything. It then loads the host summary, group membership, and earlier notes so it doesn't repeat a capture someone already ran, and opens a session so every command is recorded against that device.

The live path: performance and battery

For a device that is sluggish right now, the AI measures before it speculates. It takes counter baselines for CPU load, processor frequency, memory, and disk. It reads the battery and power state, and queries the event logs for power, processor-power, and boot-performance events. Then it runs short live traces of process activity and CPU power states, reads them, and stops them.

In this pattern, three findings stood out. The desktop search indexer held a large share of the CPU for a long stretch after a series of restarts. That was real but temporary, and a second measurement later confirmed it had settled on its own. The CPU stayed at a high fraction of its maximum frequency under moderate load, with many background processes keeping it out of its low-power states. That is where the battery went. Storage was healthy apart from a single multi-second stall. Each finding became an insight, and the baseline went into memory for the next comparison.

Where to look for power and battery evidence

Microsoft-Windows-Kernel-Processor-Power records processor performance-state changes, and Microsoft-Windows-Kernel-Power records sleep and resume. powercfg /batteryreport shows capacity and usage history, powercfg /energy flags power-efficiency problems, and on modern-standby devices powercfg /sleepstudy shows what kept the device awake while it was supposed to be asleep.

The boot path: record before anything can attach

Slow boot and logon problems happen in a window that a trace started after sign-in can never reach. Windows solves this with an AutoLogger: a trace session defined in the registry that Windows starts very early in boot, before the logon screen and before any tool can attach. It writes its events to an ETL file, it is bounded by the providers and buffers it is configured with, and it persists across reboots until someone removes it. Removing it is a deliberate step, not something that happens on its own.

InfraScout wraps this in boot profiles. Before arming, the AI describes what it will do: which profile it will arm (logon-focused or authentication-focused), which providers it records, where the output file goes, and what the next boot will capture. It arms only after you confirm. The useful providers for this kind of work cover Winlogon, Group Policy, the User Profile Service, and network-state awareness (was the network actually up when logon needed it?). For cloud sign-in they add the credential and token flows, Kerberos, domain controller discovery, and device registration. Plan for about half an hour from arming to harvest.

Reboot, sign in, harvest, disarm

A person drives the reboot. Usually the AI asks you to restart the device and sign in. It reboots the device itself only when you explicitly tell it to. Either way it confirms the device went offline and came back, with a fresh boot time and a new interactive logon, before it reads anything.

The harvest reports its own integrity: how many events were examined and how many decoded, how many were lost, and which providers contributed. Zero lost events means the capture is complete. A gap between examined and decoded events tells you how much of the trace the summary actually covers. When the combined output is large, the AI reads it one provider at a time. Then it disarms the profile and removes the AutoLogger configuration so the next boot doesn't capture again.

A bounded logon capture took about 10 to 15 minutes. An authentication capture including the reboot took about 45 minutes.

Reading what the boot actually did

The AI cross-checked trace findings against event logs, PowerShell readouts, and network reachability tests, and lined up each failure with the moment the network came up.

Microsoft-Windows-Diagnostics-Performance/Operational was the fastest way to rank boot delays. Event 100 summarizes each boot, and the events numbered 101 and above name the applications, drivers, and services that slowed it down. The same names came up repeatedly: scans by a third-party security agent, the servicing stack finishing cumulative updates, a phone-companion service, and a graphics driver. Several were expected. Servicing after a cumulative update is usually a one-time cost, and modern-standby devices that are rarely fully shut down pay unusual costs on the occasional cold boot.

The logon trace found one real problem: a Group Policy client-side extension failed at every boot. Another failure was expected, because the VM lacked hypervisor features that extension needs. The first sign-in attempt failed, a retry seconds later succeeded, and the profile and shell then loaded normally. The authentication trace showed Cloud Kerberos Trust configured but never used. Name resolution failed early in boot, before the network was ready, and a token-audience mismatch error also appeared.

Check per-user state as the user

On the authentication run, the AI's first conclusion was wrong. It blamed a stalled credential enrollment. The user ran the same status command in their own session and got a different answer. The AI's checks had run under the agent's SYSTEM account, which sees different per-user credential and enrollment state than the signed-in user. The AI withdrew the conclusion, deleted the insights built on it, and saved the lesson to memory. The finding from the trace itself still held.

Verify per-user claims in the user's context

The InfraScout agent runs as SYSTEM, so anything that depends on the signed-in user, such as credential enrollment, token state, or the per-user view of device registration, can look different from where the agent sits. Before you act on a per-user finding, have the user run the same check themselves, for example dsregcmd /status in their own session.

Remediation, with consent at each step

With the causes ranked, the AI asked which background items you wanted changed and applied only the approved ones, verifying and logging each. It checked both autostart entries and auto-start services, because ending a process that a service keeps restarting achieves nothing. When one helper process kept coming back, the AI found the service that owned it and asked again before touching that service. It declined to automate a graphics-driver install and recorded it as a recommendation instead.

The engagement ended with insights and their status, a change log, riskier items recorded as recommendations, and the incorrect findings removed, and the session went to review. In read-only sessions, the AI respected the block on risky calls rather than working around it. The performance investigation spanned a few hours with idle gaps, though active tool time was far shorter.

Next steps

Check which of your agents can run live traces and boot captures under agent capabilities, then read how the live and boot profiles work in Data Collection Sets. For the counters and trace tools behind the live path, see Agent Tools, and to plot a counter series in the chat, see Chart Display.