|
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 |
Shutdown longer than usual
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!" |
Shutdown longer than usual
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 |
Shutdown longer than usual
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!" |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
Shutdown longer than usual
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 |
All times are GMT +1. The time now is 04:57 AM. |
|
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 2004 - 2006 PCbanter
Comments are property of their posters