Bert Coules wrote:
Oh, one mild side effect of all my experimentation: as far as I can
tell, the computer is now in exactly the same configuration as it was
before I started, and runs with exactly the same speed and efficiency as
previously. Except that on boot up, after I enter my password and press
return, I'm now presented with a completely blank blue-grey screen which
lingers for some ten seconds before my desktop is generated.

It's no more than a mild inconvenience but I'd be interested to know
what is causing it. Any thoughts? Thanks.

Process Monitor has a "boot trace" option.

https://docs.microsoft.com/en-us/sys...nloads/procmon

It injects "procmon23.dll" or similar, into System32.
The file is hidden, so you need to adjust your File Explorer
view options to make it visible. (Only if, say, you wanted
to remove it at some future date.)

On the next reboot, Process Monitor collects ETW events from T=0
when the system boots up. After the desktop appears, you can wait a bit
before starting Process Monitor. It will ask you whether you
want to store the file.

You can enter filter events such as

"Operation" "Is" "CreateFile"
"Operation" "Is" "ReadFile"
"Operation" "Is" "WriteFile"

to see what programs are banging on the disk
at bootup. Which may give a hint where the
delay is coming from.

A popular means of messing up the boot, is
asking the OS to "map" a network share, and then
having the network share shut off so the OS
can't reach it. That can cost you five minutes wait.

There's more to using Process Monitor than this, such
as setting the usage of a backing file instead of using
RAM to hold traces. If you reboot while Process Monitor
is collecting a trace, and have also selected Boot Trace,
not only do you get to keep your shutdown trace, you
also get the benefit of a bootup trace. The program
can trace both, in the same session, and you have to
be careful to store both of them when the desktop
appears on the reboot.

ETW events do not have the granularity or depth of
WinDbg or GDB. Instead, it's more similar to strace
or truss on Linux/Unix, giving some I/O calls so you
can say "I see Notepad was busy". That's about
the level of picture it's about to paint. Activity
detection. Since the file calls include full path
and size info and offset, you can even tell what
it's reading :-) Some programs have the most
convoluted patterns.

You will see a ton of registry calls in that trace.
But they're of more interest at non-boot times.
You will find many registry items getting polled
once a second for example. It's a good thing the
registry is efficient.

Russinovich wrote Process Monitor. The MSFT staff
wrote WPA and friends, but that was more a matter
of showing off, than making something useful. You
want xbootmgr if using that stuff.

xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\TEMP
wpa # Windows software development kit - 10.0.14393.33
# Windows Performance Toolkit directory

I like Process Monitor, as it gives you something
to work with, with relatively little mental load.
Yes, it takes a while to get used to it. A long
journey starts with the first step. It won't bite you.
The File Menu has the trace flag, and you toggle
the flag to off, to stop a trace. Edit has a Clear
to clear the screen of a capture trace. The events
in the menus, should be from the "pool" of stuff
in the trace. So if Notepad wasn't running, you
cannot select "Process" "Is" "Notepad", because it
won't be available unless Notepad was running during
the trace.

Paul