Shutdown longer than usual

About 5 or 6 months ago running the then current Windows 10 ver 1903 my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene

On 11/19/19 11:18 AM, Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903 my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene

When I see things like this, the first thing I do is check for a failing
hard drive. :-)


--
Ken
MacOS 10.14.6
Firefox 70.0.1
Thunderbird 60.9
"My brain is like lightning, a quick flash
and it's gone!"

On 2019-11-19 12:24 p.m., Ken Springer wrote:
On 11/19/19 11:18 AM, Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903Â* my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene

When I see things like this, the first thing I do is check for a failing
hard drive.Â* :-)



Hi Ken, This is booting from and running on a fairly new very fast NVMe
drive, Boot up and all other aspects such as loading programs or doing
backups are all extremely fast.
Reads are about 3500 and writes about 2700 in Crystal Disk6.

Rene

On 11/19/19 12:05 PM, Rene Lamontagne wrote:
On 2019-11-19 12:24 p.m., Ken Springer wrote:
On 11/19/19 11:18 AM, Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903Â* my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene

When I see things like this, the first thing I do is check for a failing
hard drive.Â* :-)



Hi Ken, This is booting from and running on a fairly new very fast NVMe
drive, Boot up and all other aspects such as loading programs or doing
backups are all extremely fast.
Reads are about 3500 and writes about 2700 in Crystal Disk6.

Hi, Rene,

New of anything can fail, and few seem to think about the hard drive.
It's just my first step, and my choice of testing platforms is hard
drive testing software.

Still doing good with the monitor changes from a while back?

--
Ken
MacOS 10.14.6
Firefox 70.0.1
Thunderbird 60.9
"My brain is like lightning, a quick flash
and it's gone!"

Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903 my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.

Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Paul

On 2019-11-19 1:11 p.m., Ken Springer wrote:
On 11/19/19 12:05 PM, Rene Lamontagne wrote:
On 2019-11-19 12:24 p.m., Ken Springer wrote:
On 11/19/19 11:18 AM, Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver
1903Â* my
system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene

When I see things like this, the first thing I do is check for a failing
hard drive.Â* :-)



Hi Ken, This is booting from and running on a fairly new very fast NVMe
drive, Boot up and all other aspects such as loading programs or doing
backups are all extremely fast.
Reads are about 3500 and writes about 2700 in Crystal Disk6.

Hi, Rene,

New of anything can fail, and few seem to think about the hard drive.
It's just my first step, and my choice of testing platforms is hard
drive testing software.

Still doing good with the monitor changes from a while back?


Yep, monitor adjustments working great Thanks.

By the way I shut down Malwarebytes to see if it was the culprit but
same results.

Checked S.M.A.R.T on NVMe SS drive and everything is 100%, So will wait
and see if anyone has more ideas.


Rene

On 2019-11-19 4:01 p.m., Paul wrote:
Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903
my system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled and
so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.


Never really having used ProcMon before I am struggling migthily to
learn how it works, I have set it to store to a disk file and have set
it to capture events which when I shutdown and restart with it running I
do get a file called in my case stop.pml on the desktop which covers
about 2 minutes and about 43,00 files. Is this what I need and what
should I be looking for



Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Â*Â* Paul


Do I need to look for some kind of shutdown event or some specific time
frame in seconds?

Rene

On 2019-11-19 7:04 p.m., Rene Lamontagne wrote:
On 2019-11-19 4:01 p.m., Paul wrote:
Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903
my system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled
and so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.


Never really having used ProcMon before I am struggling migthily to
learn how it works, I have set it to store to a disk file and have set
it to capture events which when I shutdown and restart with it running I
do get a file called in my case stop.pml on the desktop which covers
about 2 minutes and about 43,00 files. Is this what I need and what
should I be looking for



Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Â*Â*Â* Paul


Do I need to look for some kind of shutdown event or some specific time
frame in seconds?

Rene



Should be 143,000 and still counting at 47%!!!

Rene

Rene Lamontagne wrote:
On 2019-11-19 7:04 p.m., Rene Lamontagne wrote:
On 2019-11-19 4:01 p.m., Paul wrote:
Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver 1903
my system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled
and so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.


Never really having used ProcMon before I am struggling migthily to
learn how it works, I have set it to store to a disk file and have set
it to capture events which when I shutdown and restart with it running
I do get a file called in my case stop.pml on the desktop which covers
about 2 minutes and about 43,00 files. Is this what I need and what
should I be looking for



Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Paul


Do I need to look for some kind of shutdown event or some specific
time frame in seconds?

Rene



Should be 143,000 and still counting at 47%!!!

Rene

There should be two separate files.

When you start ProcMon running, after the desktop comes
back up from the reboot, it should prompt for a storage name
for the boot-up trace it has collected.
That would be the second trace. That's my recollection
at least.

Procmon works, by injecting procmon23.dll or similar, into
the System32 folder. So it uses a DLL. It sets the hidden bit
on it, so you aren't supposed to be able to see it. You can probably
use a "dir" command and ask for a listing of hidden items, and then
you might see it in the listing. And the other thing about that,
is it doesn't remove that DLL either :-/ Like, when it's finished.

It also, doesn't always work. Don't ask me why.

I'll have a go in Windows 10 1909 in a minute, and refresh my memory
on how this works.

Paul

Paul wrote:
Rene Lamontagne wrote:
On 2019-11-19 7:04 p.m., Rene Lamontagne wrote:
On 2019-11-19 4:01 p.m., Paul wrote:
Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver
1903 my system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled
and so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no other
programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.


Never really having used ProcMon before I am struggling migthily to
learn how it works, I have set it to store to a disk file and have
set it to capture events which when I shutdown and restart with it
running I do get a file called in my case stop.pml on the desktop
which covers about 2 minutes and about 43,00 files. Is this what I
need and what should I be looking for



Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Paul


Do I need to look for some kind of shutdown event or some specific
time frame in seconds?

Rene



Should be 143,000 and still counting at 47%!!!

Rene

There should be two separate files.

When you start ProcMon running, after the desktop comes
back up from the reboot, it should prompt for a storage name
for the boot-up trace it has collected.
That would be the second trace. That's my recollection
at least.

Procmon works, by injecting procmon23.dll or similar, into
the System32 folder. So it uses a DLL. It sets the hidden bit
on it, so you aren't supposed to be able to see it. You can probably
use a "dir" command and ask for a listing of hidden items, and then
you might see it in the listing. And the other thing about that,
is it doesn't remove that DLL either :-/ Like, when it's finished.

It also, doesn't always work. Don't ask me why.

I'll have a go in Windows 10 1909 in a minute, and refresh my memory
on how this works.

Paul

I placed a copy of procmon.exe in my Downloads folder

I set the backing store to "pocketlink.pml". Then I stopped
and restarted the program.

I then left the procmon trace running while I reached over
to select "Reboot" from the Menu.

This is placed in the drivers folder. They're
using a new version.

C:\Windows\System32\drivers\

dir /ah procmon*

PROCMON23.SYS
PROCMON24.SYS === added now

At startup, I waited roughly two minutes before
starting procmon.exe. It prompts to save bootlog.pml,
which consists of five files (a gigabyte of them).

Now, if I stop Procmon and drag and drop either pocketlint.pml
or bootlog.pml onto the program icon, I get some timestamp ranges.

pocketlint.pml 1:46:51 === shutdown trace, procmon still running
1:47:01 at shutdown. Yours may be longer than this.
Bootlog.pml 1:47:27 === boot trace, capped off by starting
1:50:13 procmon.exe after the system comes
back up.

To return the tool to a benign state, I'd now switch
off the backing file for normal (RAM based) tracing.
I only use the backing file, for long traces.

By changing the name of the file, to pocketlint_keep.pml,
that would prevent future overwrite. Like, before running
ProcMon again in a minute or two. I've already zipped up
the files for safe keeping. They zip up pretty well, and
the whole trace only takes 75MB of storage in a compressed
state.

Paul

On 2019-11-20 1:14 a.m., Paul wrote:
Paul wrote:
Rene Lamontagne wrote:
On 2019-11-19 7:04 p.m., Rene Lamontagne wrote:
On 2019-11-19 4:01 p.m., Paul wrote:
Rene Lamontagne wrote:
About 5 or 6 months ago running the then current Windows 10 ver
1903 my system used to do a shutdown in 6 or 7 seconds.
Now I find it taking about 19 to 26 seconds, Faststart is disabled
and so is hibernation and Hiberfil is uninstalled.
Everything is disabled in Task manager-startup and I have no
other programs running in the background.
Any hints, or as Paul would say breadcrumbs for me to look at.
This is not a great hardship but makes me wonder what is the cause.

Rene


Process Monitor from Sysinternals, can capture both
a shutdown and a startup session.

You could change the backing store to disk rather than RAM.
Select the option to capture the next startup. Leave the
tool running and shut down. Both the shut down and the
startup should be captured. Then have a look at the
ProcMon events, for the problem.


Never really having used ProcMon before I am struggling migthily to
learn how it works, I have set it to store to a disk file and have
set it to capture events which when I shutdown and restart with it
running I do get a file called in my case stop.pml on the desktop
which covers about 2 minutes and about 43,00 files. Is this what I
need and what should I be looking for



Note that some events on a computer, resist debugging.
When I discovered that Windows 10 was initializing RAM
somehow at startup, and taking 20 seconds to do so,
there was a "gap" in the trace. No activity for 20 seconds
in terms of things starting or stopping. I had to surmise
a compute-bound activity was happening (no disk access).
And perhaps, an activity proportional to the size of
the system RAM. A small VM for example, would start a
lot faster.

So while ProcMon can give you a trace, it's not gdb or
Windbg and doesn't trace at that level. And some activities
will remain elusive and require conjecture.

Â*Â*Â* Paul


Do I need to look for some kind of shutdown event or some specific
time frame in seconds?

Rene



Should be 143,000 and still counting at 47%!!!

Rene

There should be two separate files.

When you start ProcMon running, after the desktop comes
back up from the reboot, it should prompt for a storage name
for the boot-up trace it has collected.
That would be the second trace. That's my recollection
at least.

Procmon works, by injecting procmon23.dll or similar, into
the System32 folder. So it uses a DLL. It sets the hidden bit
on it, so you aren't supposed to be able to see it. You can probably
use a "dir" command and ask for a listing of hidden items, and then
you might see it in the listing. And the other thing about that,
is it doesn't remove that DLL either :-/ Like, when it's finished.

It also, doesn't always work. Don't ask me why.

I'll have a go in Windows 10 1909 in a minute, and refresh my memory
on how this works.

Â*Â* Paul

I placed a copy of procmon.exe in my Downloads folder

I set the backing store to "pocketlink.pml". Then I stopped
and restarted the program.

I then left the procmon trace running while I reached over
to select "Reboot" from the Menu.

This is placed in the drivers folder. They're
using a new version.

C:\Windows\System32\drivers\

dir /ah procmon*

Â*Â* PROCMON23.SYS
Â*Â* PROCMON24.SYSÂ* === added now

At startup, I waited roughly two minutes before
starting procmon.exe. It prompts to save bootlog.pml,
which consists of five files (a gigabyte of them).

Now, if I stop Procmon and drag and drop either pocketlint.pml
or bootlog.pml onto the program icon, I get some timestamp ranges.

pocketlint.pml 1:46:51Â* === shutdown trace, procmon still running
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* 1:47:01Â*Â*Â*Â*Â*Â* at shutdown. Yours may be longer than this.
Bootlog.pmlÂ*Â*Â* 1:47:27Â* === boot trace, capped off by starting
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* 1:50:13Â*Â*Â*Â*Â*Â* procmon.exe after the system comes
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â* back up.

To return the tool to a benign state, I'd now switch
off the backing file for normal (RAM based) tracing.
I only use the backing file, for long traces.

By changing the name of the file, to pocketlint_keep.pml,
that would prevent future overwrite. Like, before running
ProcMon again in a minute or two. I've already zipped up
the files for safe keeping. They zip up pretty well, and
the whole trace only takes 75MB of storage in a compressed
state.

Â*Â* Paul

Tried following through with Procmon but did not come up with anything
specific But did notice a lot of Malwarebytes, Macrium reflect and AMD
Radeon entries , so just for kicks I uninstalled all 3 of them and have
my shutdown time to 17 seconds, Reinstalled them and it now is staying
the same at a solid 17 seconds after about 5 or 6 reboots and shutdowns,
so guess I will leave well enough alone.
I don't know what caused the 26 to 28 second shutdowns but I won't lose
too much sleep over it (maybe 10 seconds a night). :-)

Rene

Rene Lamontagne wrote:


Tried following through with Procmon but did not come up with anything
specific But did notice a lot of Malwarebytes, Macrium reflect and AMD
Radeon entries , so just for kicks I uninstalled all 3 of them and have
my shutdown time to 17 seconds, Reinstalled them and it now is staying
the same at a solid 17 seconds after about 5 or 6 reboots and shutdowns,
so guess I will leave well enough alone.
I don't know what caused the 26 to 28 second shutdowns but I won't lose
too much sleep over it (maybe 10 seconds a night). :-)

Rene

The analysis part is the hard part, so
you've had a good result so far. At least
the problem is now leaning in the right
direction :-)

Maybe something had self-updated and got
itself in a mess.

If there were PendMoves being handled at shutdown,
at least you'd see the juggling balls. Some other
sort of shutdown problem, maybe the balls would
be done by then.

Paul

On 2019-11-21 9:25 p.m., Paul wrote:
Rene Lamontagne wrote:


Tried following through with Procmon but did not come up with anything
specific But did notice a lot of Malwarebytes, Macrium reflect and AMD
Radeon entries , so just for kicks I uninstalled all 3 of them and
have my shutdown time to 17 seconds, Reinstalled them and it now is
staying the same at a solid 17 seconds after about 5 or 6 reboots and
shutdowns, so guess I will leave well enough alone.
I don't know what caused the 26 to 28 second shutdowns but I won't
lose too much sleep over itÂ* (maybe 10 seconds a night).Â* :-)

Rene

The analysis part is the hard part, so
you've had a good result so far. At least
the problem is now leaning in the right
direction :-)

Maybe something had self-updated and got
itself in a mess.

If there were PendMoves being handled at shutdown,
at least you'd see the juggling balls. Some other
sort of shutdown problem, maybe the balls would
be done by then.

Â*Â* Paul

My stubbornness prevailed again, I just had to keep nipping at it's
heels and found the following Site.

https://support.microsoft.com/en-us/...status-message

which let me put the shutdown session in a verbose mode then watch it
tell me exactly what was happening.
Great stuff, in my case it is "AsusUpdatecheck.exe" which is hogging
about 13 or 15 seconds of my shutdown time, When I disable it my
shutdown falls back to about 5 seconds, This file resides in System32.

Now the problem I face is that no matter how I stop it, run manually or
disable it in services it comes back to life on a restart, Is there a
way to disable it permanently, I've uninstalled all the Asus stuff I can
find but Windows must keep a copy of it's own somewhere.
What do I need? A wooden stake or a Silver bullet. :-)

Rene

Rene Lamontagne wrote:
On 2019-11-21 9:25 p.m., Paul wrote:
Rene Lamontagne wrote:


Tried following through with Procmon but did not come up with
anything specific But did notice a lot of Malwarebytes, Macrium
reflect and AMD Radeon entries , so just for kicks I uninstalled all
3 of them and have my shutdown time to 17 seconds, Reinstalled them
and it now is staying the same at a solid 17 seconds after about 5 or
6 reboots and shutdowns, so guess I will leave well enough alone.
I don't know what caused the 26 to 28 second shutdowns but I won't
lose too much sleep over it (maybe 10 seconds a night). :-)

Rene

The analysis part is the hard part, so
you've had a good result so far. At least
the problem is now leaning in the right
direction :-)

Maybe something had self-updated and got
itself in a mess.

If there were PendMoves being handled at shutdown,
at least you'd see the juggling balls. Some other
sort of shutdown problem, maybe the balls would
be done by then.

Paul

My stubbornness prevailed again, I just had to keep nipping at it's
heels and found the following Site.

https://support.microsoft.com/en-us/...status-message


which let me put the shutdown session in a verbose mode then watch it
tell me exactly what was happening.
Great stuff, in my case it is "AsusUpdatecheck.exe" which is hogging
about 13 or 15 seconds of my shutdown time, When I disable it my
shutdown falls back to about 5 seconds, This file resides in System32.

Now the problem I face is that no matter how I stop it, run manually or
disable it in services it comes back to life on a restart, Is there a
way to disable it permanently, I've uninstalled all the Asus stuff I can
find but Windows must keep a copy of it's own somewhere.
What do I need? A wooden stake or a Silver bullet. :-)

Rene

A Run key in the registry ?

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run

Something Autoruns lists ?

Something in Scheduled Tasks ?

Is there are Startup Items folder of some sort ?

*******

https://attack.mitre.org/techniques/T1060/

"By default, the multistring BootExecute
value of the registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Session Manager

is set to

autocheck autochk *

This value causes Windows, at startup, to check the file-system
integrity of the hard disks if the system has been shut down
abnormally. Adversaries can add other programs or processes
to this registry value which will automatically launch at boot.
"

At one time, that was a favored attack vector. Asus
wouldn't use that, because it's a place people would
be checking right away. It's like "Hello World" to
put something in there.

Paul

On 2019-11-22 7:29 p.m., Paul wrote:
Rene Lamontagne wrote:
On 2019-11-21 9:25 p.m., Paul wrote:
Rene Lamontagne wrote:


Tried following through with Procmon but did not come up with
anything specific But did notice a lot of Malwarebytes, Macrium
reflect and AMD Radeon entries , so just for kicks I uninstalled all
3 of them and have my shutdown time to 17 seconds, Reinstalled them
and it now is staying the same at a solid 17 seconds after about 5
or 6 reboots and shutdowns, so guess I will leave well enough alone.
I don't know what caused the 26 to 28 second shutdowns but I won't
lose too much sleep over itÂ* (maybe 10 seconds a night).Â* :-)

Rene

The analysis part is the hard part, so
you've had a good result so far. At least
the problem is now leaning in the right
direction :-)

Maybe something had self-updated and got
itself in a mess.

If there were PendMoves being handled at shutdown,
at least you'd see the juggling balls. Some other
sort of shutdown problem, maybe the balls would
be done by then.

Â*Â*Â* Paul

My stubbornness prevailed again, I just had to keep nipping at it's
heels and found the following Site.

https://support.microsoft.com/en-us/...status-message


Â*which let me put the shutdown session in a verbose mode then watch it
tell me exactly what was happening.
Great stuff, in my case it is "AsusUpdatecheck.exe" which is hogging
about 13 or 15 seconds of my shutdown time, When I disable it my
shutdown falls back to about 5 seconds, This file resides in System32.

Now the problem I face is that no matter how I stop it, run manually
or disable it in services it comes back to life on a restart, Is there
a way to disable it permanently, I've uninstalled all the Asus stuff I
can find but Windows must keep a copy of it's own somewhere.
What do I need? A wooden stake or a Silver bullet. :-)

Rene

A Run key in the registry ?

Â*Â* HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run

Nope, only fan control


Something Autoruns lists ?

Yep entries there, deleted all I can find.


Something in Scheduled Tasks ?

Nope, no scheduled tasks.


Is there are Startup Items folder of some sort ?

Startup folder is clean, all items disabled for now.


*******

https://attack.mitre.org/techniques/T1060/

Â*Â* "By default, the multistring BootExecute
Â*Â*Â* value of the registry key

Â*Â*Â*Â*Â*Â* HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Session Manager

Â*Â*Â* is set to

Â*Â*Â*Â*Â*Â* autocheck autochk *

I left as is, Above my payscale.


Â*Â*Â* This value causes Windows, at startup, to check the file-system
Â*Â*Â* integrity of the hard disks if the system has been shut down
Â*Â*Â* abnormally. Adversaries can add other programs or processes
Â*Â*Â* to this registry value which will automatically launch at boot.
Â*Â* "

At one time, that was a favored attack vector. Asus
wouldn't use that, because it's a place people would
be checking right away. It's like "Hello World" to
put something in there.

Â*Â* Paul

After that it still comes back.

Thanks Rene