Slow Boot Time

I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

In article , says...

I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

All I can tell you is having USB devices attached and turned on sure
affects me and my 6 external/portables every time I reboot If I turn
them off I then instead have to reassign shares on them as I activate
them, another pita. AND one of them isn't seen during boot that I do
usually (if I remember) turn off as I have to anyway after Windows
starts before it's seen, have no idea why but another pita. That said,
can really tell it adds to boot time between turned off or on.

WayFarer wrote:
I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

In my travels, I've noticed the system collecting this file.

It is bootckcl.etl

First of all, ETW is a tracing system that Windows has now. It's
been around for a while, probably from WinXP days. The sysinternals.com
"Process Monitor" uses ETW, to collect real-time events from all the
running programs. However, Process Monitor does not have any
data mining in it. Process Monitor even has duplicate capabilities
to the bootckcl file, but the Process Monitor implementation has a
few bugs. It's kinda hit and miss, to get any log at all. Process
Monitor injects Procmon23.dll (hidden file) into the system folder,
when it wants to do a boot trace. The 23 is a version number. And
in a shocking lack of hygiene, that DLL is left there after
the session is completed.

When the OS does tracing, it can use more than one file extension.
In this case, it's an Event Tracing Log. So the OS has inherited
the feature from Process Monitor.

I noticed bootckcl.etl, because it kept showing up in a defragmenter log.
But I didn't do a search on the file name until just now.

https://blogs.technet.microsoft.com/...at-every-boot/

Using my disk inventory, I can see that both Windows 8 and Windows 10
still have versions of xperf (it's a separate download, but I
noticed that both Win8 and Win10 kits exist). The xbootmgr also
allows collecting a boot trace, if you want to learn how to use it.
The xperf analyses the output.

I:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xbootmgr.exe
I:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe

N:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\xbootmgr.exe
N:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\xperf.exe

The Technet article says to look for WADK. This is the
stub loader for WADK. You tick the tick box for WPT, and
*only* WPT is downloaded (maybe 50MB or so). If you download
the entire WADK, it's gigabytes in size. All you want, is
a tiny fraction of that. WPT contains WPA and WPR, but all
you'd want is xperf.exe and maybe xbootmgr.exe (if they're not
in there, then you'd have to go back to the Win8 kit, but the
disk information above suggests there is a Win10 version).
WPR and WPA take a couple hours to run their default trace, which
is a special kind of lunacy.

http://download.microsoft.com/downlo...k/adksetup.exe

( https://developer.microsoft.com/en-u...deployment-kit )

This bootckcl.etl is hard to see. It won't show up in a search.
I tried Agent Ransack just now, and it ignored this folder.
However, because I keep a collection of file lists for
all 22 disks here, I could easily consult my index and
get a general idea where to look. Once I knew where to
look, drilling down with File Explorer was easy. This
is on the Win10 machine, running across from me.

C:\Windows\System32\WDI\LogFiles\BootCKCL.etl 31,457,280 bytes

Now, as traces go, that's pretty small, which means it
didn't collect a lot of detail. A larger trace,
with a few more switches, could be on the order of
800MB.

One of the pet peeves with boot traces, is when do they
stop ? Some stop before the "interesting" activity
happens. I've even used the command line, to set
a duration for the damn trace, and the tracing
software ignored me.

The trick with all these tools, is getting numbers
and graphs that humans can use. I've *never* been
satisfied with the above mentioned tools. Only
Bootvis from WinXP days, came even close. And Bootvis
isn't going to be a good candidate for any newer
systems (orphan software).

AFAIK, these tools continue to have the "SVCHOST problem".
When services hide in a SVCHOST, we can't get their
name. We don't know who is doing it. All we know
is on this boot cycle, SVCHOST PID 916 is busy,
then on the next boot, we know SVCHOST PID 1023 is
busy. The process ID is random, and a function of
race conditions in the OS (no two boots are
exactly alike). So we know some SVCHOST of the
umpteen SVCHOSTS did it, but we don't know which one.
The tracing system doesn't allow correlating this.
I haven't found a way yet, but I'm sure Mark
Russinovich knows.

If a Service is holding up your boot, then you'd be
hard pressed to find the necessary info to get
an ID string.

But if I had to figure out a slow boot, the above is
how I'd try to do it.

You can use your intuition of course. If you have
a file share that you automatically mount each time
the system boots, and you happen to be plugged into
a different network, that mount will fail. And that'll
add five minutes to your boot time. Mark Russinovich
wrote an article about using his tool kit to figure
out it was the network mount - when we know he would
have had a suspicion about that, with no tools at all.
Still, it made for an interesting read.

*******

Just for fun, somebody in Japan appears to have used
WPA to analyze a bootckcl.etl.

http://n.mynv.jp/column/windows/287/images/005l.jpg

( http://news.mynavi.jp/column/windows/287/ )

So that tells me, you're not limited to xperf.exe,
you can also try WPA and load that file.

You'll be exposed to all sorts of nonsense, such
as DLLhost, BackgroundTaskHost, a bunch of launchers
with different names that "hide" the executable. Again,
reprehensible practices when you want to get your
job done and get out of Dodge.

Why the **** can't they design an OS which is *traceable* ?
Surely their own staff must run into problems with this.

*******

Good luck with your search,

Paul

On 19-Nov-17 1:29 PM, Paul wrote:
WayFarer wrote:
I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and
'sfc /scannow' revealed nothing. I disabled the fast-boot option
rebooted and then re-enabled fast-boot but the start-up time remains
very slow. I then disabled my two 'high impact' start-up services
(Dropbox and OneDrive but this didn't make any difference either; In
fact I can not detect any notable time difference between fast boot
and 'normal' boot options.
Any suggestions to improve the start-up time are most welcome.

In my travels, I've noticed the system collecting this file.

It is bootckcl.etl

First of all, ETW is a tracing system that Windows has now. It's
been around for a while, probably from WinXP days. The sysinternals.com
"Process Monitor" uses ETW, to collect real-time events from all the
running programs. However, Process Monitor does not have any
data mining in it. Process Monitor even has duplicate capabilities
to the bootckcl file, but the Process Monitor implementation has a
few bugs. It's kinda hit and miss, to get any log at all. Process
Monitor injects Procmon23.dll (hidden file) into the system folder,
when it wants to do a boot trace. The 23 is a version number. And
in a shocking lack of hygiene, that DLL is left there after
the session is completed.

When the OS does tracing, it can use more than one file extension.
In this case, it's an Event Tracing Log. So the OS has inherited
the feature from Process Monitor.

I noticed bootckcl.etl, because it kept showing up in a defragmenter log.
But I didn't do a search on the file name until just now.

https://blogs.technet.microsoft.com/...at-every-boot/


Using my disk inventory, I can see that both Windows 8 and Windows 10
still have versions of xperf (it's a separate download, but I
noticed that both Win8 and Win10 kits exist). The xbootmgr also
allows collecting a boot trace, if you want to learn how to use it.
The xperf analyses the output.

I:\Program Files (x86)\Windows Kits\8.1\Windows Performance
Toolkit\xbootmgr.exe
I:\Program Files (x86)\Windows Kits\8.1\Windows Performance
Toolkit\xperf.exe

N:\Program Files (x86)\Windows Kits\10\Windows Performance
Toolkit\xbootmgr.exe
N:\Program Files (x86)\Windows Kits\10\Windows Performance
Toolkit\xperf.exe

The Technet article says to look for WADK. This is the
stub loader for WADK. You tick the tick box for WPT, and
*only* WPT is downloaded (maybe 50MB or so). If you download
the entire WADK, it's gigabytes in size. All you want, is
a tiny fraction of that. WPT contains WPA and WPR, but all
you'd want is xperf.exe and maybe xbootmgr.exe (if they're not
in there, then you'd have to go back to the Win8 kit, but the
disk information above suggests there is a Win10 version).
WPR and WPA take a couple hours to run their default trace, which
is a special kind of lunacy.

http://download.microsoft.com/downlo...k/adksetup.exe


(
https://developer.microsoft.com/en-u...deployment-kit
)

This bootckcl.etl is hard to see. It won't show up in a search.
I tried Agent Ransack just now, and it ignored this folder.
However, because I keep a collection of file lists for
all 22 disks here, I could easily consult my index and
get a general idea where to look. Once I knew where to
look, drilling down with File Explorer was easy. This
is on the Win10 machine, running across from me.

C:\Windows\System32\WDI\LogFiles\BootCKCL.etlÂ*Â*Â *Â*Â*Â* 31,457,280 bytes

Now, as traces go, that's pretty small, which means it
didn't collect a lot of detail. A larger trace,
with a few more switches, could be on the order of
800MB.

One of the pet peeves with boot traces, is when do they
stop ? Some stop before the "interesting" activity
happens. I've even used the command line, to set
a duration for the damn trace, and the tracing
software ignored me.

The trick with all these tools, is getting numbers
and graphs that humans can use. I've *never* been
satisfied with the above mentioned tools. Only
Bootvis from WinXP days, came even close. And Bootvis
isn't going to be a good candidate for any newer
systems (orphan software).

AFAIK, these tools continue to have the "SVCHOST problem".
When services hide in a SVCHOST, we can't get their
name. We don't know who is doing it. All we know
is on this boot cycle, SVCHOST PID 916 is busy,
then on the next boot, we know SVCHOST PID 1023 is
busy. The process ID is random, and a function of
race conditions in the OS (no two boots are
exactly alike). So we know some SVCHOST of the
umpteen SVCHOSTS did it, but we don't know which one.
The tracing system doesn't allow correlating this.
I haven't found a way yet, but I'm sure Mark
Russinovich knows.

If a Service is holding up your boot, then you'd be
hard pressed to find the necessary info to get
an ID string.

But if I had to figure out a slow boot, the above is
how I'd try to do it.

You can use your intuition of course. If you have
a file share that you automatically mount each time
the system boots, and you happen to be plugged into
a different network, that mount will fail. And that'll
add five minutes to your boot time. Mark Russinovich
wrote an article about using his tool kit to figure
out it was the network mount - when we know he would
have had a suspicion about that, with no tools at all.
Still, it made for an interesting read.

*******

Just for fun, somebody in Japan appears to have used
WPA to analyze a bootckcl.etl.

http://n.mynv.jp/column/windows/287/images/005l.jpg

( http://news.mynavi.jp/column/windows/287/ )

So that tells me, you're not limited to xperf.exe,
you can also try WPA and load that file.

You'll be exposed to all sorts of nonsense, such
as DLLhost, BackgroundTaskHost, a bunch of launchers
with different names that "hide" the executable. Again,
reprehensible practices when you want to get your
job done and get out of Dodge.

Why the **** can't they design an OS which is *traceable* ?
Surely their own staff must run into problems with this.

*******

Good luck with your search,

Â*Â* Paul
Thanks for comprehensive and educational response. This will take time
to research... Aside what I have tried already I've customized the the
size of the paging file to its recommended value which alas didn't speed
up the start-up time either. Maybe one of the future Tuesday patches
will fix the boot time issue. Thanks again...

On 19-Nov-17 12:00 PM, pjp wrote:
In article , says...

I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

All I can tell you is having USB devices attached and turned on sure
affects me and my 6 external/portables every time I reboot If I turn
them off I then instead have to reassign shares on them as I activate
them, another pita. AND one of them isn't seen during boot that I do
usually (if I remember) turn off as I have to anyway after Windows
starts before it's seen, have no idea why but another pita. That said,
can really tell it adds to boot time between turned off or on.
With the exception of the wireless transmitter for mouse/keyboard I
don't have USB devices attached to this pc.

On Sun, 19 Nov 2017 10:59:31 +0700, WayFarer
wrote:


I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins).




Each to his own of course, but 3-4 minutes wouldn't bother me at all.
My personal view is that the attention many people pay to how long it
takes to boot is unwarranted. Assuming that the computer's speed is
otherwise satisfactory, it is not generally worth worrying about. Most
people start their computers once a day or even less frequently. In
the overall scheme of things, even a few minutes to start up isn't
very important. Personally I power on my computer when I get up in the
morning, then go get my coffee. When I come back, it's done booting. I
don't know how long it took to boot and I don't care.

"WayFarer" wrote in message news
I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

By any chance did you make a change in the UEFI or BIOS to enable "Legacy
Boot"?

May want to check that setting.

Bob S.

On 20-Nov-17 7:55 AM, Ken Blake wrote:
On Sun, 19 Nov 2017 10:59:31 +0700, WayFarer
wrote:

I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins).

Each to his own of course, but 3-4 minutes wouldn't bother me at all.

It's not a bother per se rather an 'eyebrow-raising' surprise of
dissimilarity since prior version 1709 the boot time was about less than
30 seconds.

On 20-Nov-17 8:19 AM, Bob_S wrote:


"WayFarer"Â* wrote in message news
I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins). The graphic driver is up-to-date and 'sfc
/scannow' revealed nothing. I disabled the fast-boot option rebooted and
then re-enabled fast-boot but the start-up time remains very slow. I
then disabled my two 'high impact' start-up services (Dropbox and
OneDrive but this didn't make any difference either; In fact I can not
detect any notable time difference between fast boot and 'normal' boot
options.
Any suggestions to improve the start-up time are most welcome.

By any chance did you make a change in the UEFI or BIOS to enable
"Legacy Boot"?

May want to check that setting.

Bob S.
I did not make any changes to the mobo, just a plain, straightforward
implementation of Win update but will double-check on the settings; Thanks.

On Sun, 19 Nov 2017 20:20:52 -0500, Wolf K
wrote:


On 2017-11-19 19:55, Ken Blake wrote:

On Sun, 19 Nov 2017 10:59:31 +0700, WayFarer
wrote:


I just updated to version 1709 (OS Build 16299.64). The process went
slow but luckily uneventful. However the start-up time now has slowed
down considerably (3-4-mins).




Each to his own of course, but 3-4 minutes wouldn't bother me at all.
My personal view is that the attention many people pay to how long it
takes to boot is unwarranted. Assuming that the computer's speed is
otherwise satisfactory, it is not generally worth worrying about. Most
people start their computers once a day or even less frequently. In
the overall scheme of things, even a few minutes to start up isn't
very important. Personally I power on my computer when I get up in the
morning, then go get my coffee. When I come back, it's done booting. I
don't know how long it took to boot and I don't care.


Slow boot time means more "background services" being loaded.



Yes.



These take
up RAM,



They take up virtual memory (in the Microsoft sense of the term: RAM +
page file), not RAM.



and many of them are so rarely in actual use that IMO there's no
point loading them.



If they are not in use, what they take up is page file, not RAM.
There's no penalty for that.




They also steal cycles,


Only if they are in use.



but that almost never
matters. However, some of these services are trackers, and those should
not be permitted.



We agree on that.