On Sat, 5/31/2025 7:54 AM, Ed Cryer wrote:

I was looking at Services. This system has built up a long list over the years, so I went in search of something to cleanse them.

What about Windows Performance Analyser? Has anybody used it beneficially?

Ed

When I tested it some time ago, it booted the computer six times
and collected data over a two hour period. To what purpose,
I could not discern :-/ It gave the appearance of an
"IT Guy tool for studying a model of PC before
buying a thousand of them".

That's WPA if used out of the box.

You can do boot tracing with some of the tools in the kit.
That is more purposeful, but in the post-trace, it is still
hard to figure out where you should be looking, and what
is actually going on. SVCHOST are, as usual, opaque and
poorly handled. You have to keep cheat notes handy,
the "tasklist /svc" list, to note a high user (WUAUSERV)
by noting the PID and translating that back to the service
name. You do a trace, the file is collected, then while the
PC is still running, you do tasklist /svc and collect your
crib notes, then go into the graphical tool to view the
trace with crib note in hand. If you don't record the PIDs,
you'll never figure it out.

Cleansing them, is unnecessary. If you use Process Explorer,
you can see that most of them, do not use cycles until an
application specifically asks them for service. Only a small
number of them, are cycle hogs. And you might barely be
able to see a background load... in Process Explorer from
Sysinternals. Task Manager itself is useless for task
management, by not using enough digits of precision on
the activity of the processes. Task Manager says "2" for
something, as in two percent, Process Explorer says "2.03 percent".

I recommend Process Explorer for your examination, as
Task Manager is a blunt instrument for this work. It's
a kitchen knife with the edge filed off.

https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer

*******

Process Explorer is just to see that the SVCHOST are not all
wasteful.

Doing an actual trace, like a boot up trace, is to look
for delays in various activities, that may be user adjustable
by some means. This creates a visualization of how busy
the machine is underneath, from T=0.

In this example, the first command is going to record the boot
that will start in a few moments. The second command, is the
graphical readout on Performance Kit. I'm giving you this,
as material to feed into a Google. There's a whole other post
I'd have to write, to go with this. Just selecting the right
era of package can be a chore for this work.

xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\TEMP

wpa # Windows software development kit - 10.0.14393.33 Windows Performance Toolkit directory

Tracing is done by the ETW subsystem, and the "additional slowness"
via sampling, is affected by the "things in the plus sign list".
Put the wrong thing in there, it could take 10x longer to boot,
but you could still spot relative slowness in the trace,
like delays that should not be there.

Process Monitor can also collect boot traces, and uses DLL
injection to do it. The DLL has the Hidden bit set on it. I don't
remember right off hand, whether wpa reads one of those traces
or not.

The WinXP era BootVis was the best for users. But the guy who has
made a career out of WPA, is quite insistent that the tool must
look like the control panel on a 747, and that helps "rule out
the little people using my tool". BootVis may not have answered
a lot of questions, but it was easier for casual usage.

Paul

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)