What tools would you use to track down slow startup after 24H2?

I’d start by collecting repeatable measurements rather than trying more fixes at random. Windows Performance Recorder and Windows Performance Analyzer can capture boot activity, CPU use, disk activity, and delays from services. Compare a slow boot with a known-good 23H2 machine of the same model, and capture both connected and disconnected from the network.

For the memory issue, check whether the growth is in a process or in kernel memory. Task Manager and Resource Monitor are a quick first pass, while Process Explorer and RAMMap can help narrow down process usage, drivers, and nonpaged pool. A steadily rising number over time is more suggestive of a leak than a high but stable baseline.

For the long “Please wait” phase, I’d separate local startup from domain processing. Check Group Policy operational logs, the System log, and startup-related events around the delay. Also compare the same device on and off the corporate network, then look for slow policy processing, name resolution, or a service waiting on a network resource. Don’t assume the network is the only cause just because it makes the delay longer.

Process Explorer is good for a live look when the machine is actually misbehaving. Sort by CPU, then check private bytes and commit size for processes that keep growing. If Task Manager looks ordinary despite memory climbing, RAMMap can show whether the usage is in file cache, driver-locked memory, or another category. Note the numbers over time and compare affected and unaffected machines.

For startup entries, Autoruns can help identify third-party items, but I’d disable things only in a controlled test group. Removing startup items indiscriminately can hide the symptom without finding the component behind it.

I’d also verify the rollout path before chasing individual drivers. Was this an in-place upgrade, and are the affected devices running the same security tools, management agents, and firmware versions? If the symptoms line up with a particular model or software combination, testing a small matched group with one variable changed at a time is more useful than rebuilding the whole fleet.

Search-index repair may help a search-specific delay, but it would not explain high CPU, memory growth, and long boot times by itself.

One practical route is to make a small diagnostic package for a few affected machines: boot trace, event logs, process and memory snapshots, plus exact build and driver versions. Keep one unaffected machine as a control. If the issue is a leak, capture the memory breakdown at intervals rather than only after the machine is nearly frozen. That gives you something concrete to compare and share with the team responsible for the update.