Win XP Slowing down boot

Win XP Pro.

Put in an SSD a year ago that helped speed some.
Recently the laptop seemed to significantly slow down on boot.

So I did a cleanup with both CCleaner(free) and Glary's Utilities(free)
then a full boot diskcheck.

Everything speeded up significantly on boot.

But now the laptop slowed way down on boot again.

So I repeated the full cleanup BUT it did not help.

I do not remember adding any new applications but a few did update
recently. Nothing that I think runs in the background at boot but ???

Suggestions on discovering the boot up culprit please.

HastenJason wrote:

Win XP Pro.

Put in an SSD a year ago that helped speed some.
Recently the laptop seemed to significantly slow down on boot.

So I did a cleanup with both CCleaner(free) and Glary's Utilities(free)
then a full boot diskcheck.

Everything speeded up significantly on boot.

But now the laptop slowed way down on boot again.

So I repeated the full cleanup BUT it did not help.

I do not remember adding any new applications but a few did update
recently. Nothing that I think runs in the background at boot but ???

Suggestions on discovering the boot up culprit please.

Windows XP does *NOT* support TRIM. You installed hardware the OS does
not fully support. Windows XP was released way back in 2002 (15 years
ago). SSDs did not start becoming economically viable in the consumer
market until long after that. TRIM is required to keep SSDs from
slowing down over time and with writes.

https://en.wikipedia.org/wiki/Trim_(computing)
http://www.buildcomputers.net/trim-support.html


Check if the SSD manufacturer provides utilities for maintaining their
SSD. They may include a TRIM utility or it might be embedded into some
other support software. It isn't just the boot process that will be
slowed without TRIM. Programs will become erratically slow as they
happen to hit those sectors that were not prepped for quick access after
they had been previously used for a write but then freed from
allocation.

If their utility provides a CLI (command-line interface), you could
schedule a TRIM, like once a week, to prep the sectors for the next
writes to keep speedy the SSD. If they have no CLI, you'll have to set
a reminder to do a manual TRIM at periodic intervals. If they have no
TRIM utility, your SSD will get progressively and increasingly slower.
From what I've seen, you need to get a TRIM tool that is specific to
your brand of SSD. That means you have to get the TRIM tool from the
SSD manufacturer. Their tool knows how to communicate directly with
their firmware in their drive.

Maybe but the SSD is Samsung and I have not seen any slowing other than
boot and I have installed Samsung SSD in other laptops and not seen the
boot slow. Seem related to only this laptop at boot.

Samsung Magician is provided. Running that now.

I do also know that the SSD performance is related to the motherboard
chip set.

Samsung Magician says

Read 142 MBytes/Sec
Write 135 MBytes/Sec

Random Read 25055 IOPS
Random Write 17970 IOPS

Seems pretty good.

So what is slowing the boot ?

HastenJason wrote:

Maybe but the SSD is Samsung and I have not seen any slowing other than
boot and I have installed Samsung SSD in other laptops and not seen the
boot slow. Seem related to only this laptop at boot.

All depends on how many writes have been performed on the SSD. Your
multiple hosts will have differing levels of writes. Even if they were
setup identically, they would have differing write volumes; however, it
is likely that they are not identical. They may have used the same
sysprep image but would require no modification thereafter to remain
identical: no software installs, no tweaking, no differences in config.

Samsung Magician is provided. Running that now.

Be careful. I downloaded version 5 as an upgrade version. Lots of
tools were missing from that new major version. I noticed it right
away: where the hell are all the tools that were in there before.
Luckily I still had version 4.96 stored in a download folder,
uninstalled version 5, and reinstalled 4.96. All the tools were back,
including the TRIM utility. For version 4.96, it is under "Performance
Optimization" in the left panel.

Alas, there is no CLI to Samsung Magician so I cannot schedule it in
Task Scheduler to run periodically to force a TRIM. Instead I added a
reminder to run TRIM every month. Although I'm using Windows 7 which
supports TRIM, I have found that occasionally the OS is too slow to do a
TRIM. The OS waits until the computer is idle but I don't know for how
long the computer must be idle. I'm on my computer most of the day to
do remote work or for most of the rest of the day for my own use at
home. Even when I'm gone, it is running several scheduled tasks. Some
tasks wait until the computer has been idle for awhile, like 10 to 60
minutes. Some tasks are scheduled to run while I am expected to be away
or when asleep. There is probably not much idle time.

I do also know that the SSD performance is related to the motherboard
chip set.

That would't affect slowdown due to lack of TRIMming. That would affect
overall performance. My old home computer only has SATA-2 ports so the
loss of performance for not having SATA-3 is probably my biggest loss
source. For TRIM to work:

- The OS must support TRIM to SSDs (which means they must recognized
SSDs).
- The driver (to interface between OS and hardware) must support TRIM.
Some old drivers do not.
- The drive controller must support a sufficient subset of the SATA
protocol to include support of TRIM. Old controllers may not.
- The SSD must support TRIM. Some ancient ones did not.

Only if ALL those conditions are met will TRIM work. Only takes one to
fail for TRIM to fail.

HastenJason wrote:

Samsung Magician says

Read 142 MBytes/Sec
Write 135 MBytes/Sec

Random Read 25055 IOPS
Random Write 17970 IOPS

Seems pretty good.

So what is slowing the boot ?

That is a generic benchmark. I found it only useful to notice the
difference between RAPID mode being enabled or not. I've used other
benchmarks and the general one seems very fast. The testing method is
to create a file to see how fast it can be written and read. Well, what
if the file were deposited to memory blocks that had not yet been used.
They would still be prep'ed.

As I recall, I used a trial version of HD Tune to perform other tests.
That showed me performance across all memory blocks of the SSD, not just
wherever a test file happened to get written. I noticed some spikes.
Those went away after using Samsung Magician to do a TRIM (aka
Optimize).

Did you run Samsung Magician's "Performance Optimize" yet to see if its
TRIM made the boot any faster?

By the way, did you ever use msconfig.exe to disable all the startup
programs to check if something you installed and which loads on Windows
startup is causing the sluggishness? First try disabling all the
programs listed under the Startup tab. If that doesn't help, boot
Windows in its safe mode (with networking if you need it during test)
and retest the boot time.

HastenJason wrote:
Win XP Pro.

Put in an SSD a year ago that helped speed some.
Recently the laptop seemed to significantly slow down on boot.

So I did a cleanup with both CCleaner(free) and Glary's Utilities(free)
then a full boot diskcheck.

Everything speeded up significantly on boot.

But now the laptop slowed way down on boot again.

So I repeated the full cleanup BUT it did not help.

I do not remember adding any new applications but a few did update
recently. Nothing that I think runs in the background at boot but ???

Suggestions on discovering the boot up culprit please.


There are several tools that could visualize what is
happening during boot.

These use ETW tracing events, which exist early in boot (but
not right at T=0), as well as during the shutdown sequence.

BootVis - version is 1.3.37
- works on WinXP SP3 (I tried it back in the day...)
- provides a graphical output of where time is spent
- rumored by some, to be able to damage the OS when run.
A backup is recommended. I didn't have a problem.

Xbootmgr/Xperf - these are the beginnings of the WPA tools
- lots of command line parameters
- can specify multiple boot cycles for analysis and capture
- Xperf views the output
- various versions available, packaged for a while
with the actual WPA package. Last useful
version was with the Win8 WPA.
- may have .NET dependencies. I probably was running
it on Win7, based on the decorations in the pictures
I took.

WPA - takes two hours to run
- beats the **** out of the OS
- intended for IT staff, the developer obviously intended
to "dazzle" IT people with the options.
- A bit annoying to find all the trace options.
- Not really recommended unless you're being paid to learn
how to use it :-)

And a separate tool, pretty simplistic by comparison to any of
those, is Sysinternals.com Process Monitor.

- Can't really do much with it
- can find "dead spots" in the trace, where the OS is
waiting for something
- could see your AV scanning system files (i.e. overloading
disk with read requests, nothing else will run)
- no pretty graphs

https://technet.microsoft.com/en-us/...processmonitor

Now, I tried that program on this machine, and it actually didn't
work. This copy of WinXP Sp3 has a problem that I've been unable to
trace down. The inability to generate a ETW boot trace is the first
new piece of evidence in a while concerning whatever the problem is.

Version 3.2
https://web-beta.archive.org/web/201...processmonitor

OK, so first problem with the first processmonitor link, is Procmon332
does not run on WinXP. The program throws an error. You can try it
though, because remember, I was testing 332 on my (broken)
WinXP. Version 320 didn't throw errors, but it also did not
collect a trace. Grrr. So you have two versions you can test.

I uncorked a new WinXP virtual machine and collected
a trace on that. Version 320 worked on that.

You run ProcMon, go to the File menu and untick the tickmark
of the currently running trace. That's just to avoid
distraction while you're working. You can then use
Edit : Clear to clear the display of the distraction.

Now, under Options is Enable Boot Monitoring. Set the
tick mark on that one.

Exit the program.

Reboot.

When the system comes up, ETW events will be collected
in bootlog.PML . Wait a minute or two for the desktop
to settle (the trace should still be collecting events
at this point). Now, start ProcMon.exe again by double-clicking
it. The program should notice that Boot Logging was enabled,
and it should be ready to stop the trace, and convert the
trace into a PML file.

Process Monitor will put up this dialog, as proof a boot log
was collected. This is what I saw on my nice clean virtual machine.

"A log of the boot-time activity was created by the previous instance of
Process Monitor. Do you wish to save the collected data now?"

https://i.stack.imgur.com/qIVTG.png

(from https://superuser.com/questions/2614...startup/334111 )

Next, you should see the output. In the menu,
in Filter, select "Enable Advanced Output".

The trace consists of events collected at the microsecond level.

When a machine is behaving badly at boot, you're looking for
long sections of "quiet" with no events. Scroll back, and see
if you can spot an event that kicked off "the silence". Or,
when the events start rolling in again, maybe the first event
is a timeout that triggered, and the associated subsystem
is somehow guilty. Or, in the trace, you can see a million
calls from your AV, as it scans the entire Windows folder.

Since this technique lacks a graph like some of the others,
the output is nothing to write home about. However, the others
are complicated to find, to run properly, to set the graphical
output, and in the end, the output isn't much better.

I also think BootVis is worth trying. There is a version
on majorgeeks.com (1.3.37). But I would also advise a
safety backup, just in case (because of some of the comments
written in the past about it). I had no trouble at all when
I ran it, but that was some time ago on WinXP SP3.

http://www.majorgeeks.com/files/details/bootvis.html

*******

I wanted to include some pictures of my own, but Postimg
is down right now. Oh, well.

Paul