Seriously, Win10, What's with the restart?
-
If you had gone one more entry in the log, you'd see this: "Windows 10 was detected. The system is inherently unstable."
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I was using my laptop then took a break for lunch. Came back and it had restarted. I checked Windows Updates and it said there was one installed successfully on 02/13. Why did my computer suddenly restart? I looked in Event Log (System):
event log:
The previous system shutdown at 12:19:13 PM on 2/17/2018 was unexpected.
Next I find this:
Event log:
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly. (Source is Kernel-Power)
It's a laptop so has battery backup, so probably not a loss of power. Here's another weird one (not sure what bugcheck is):
Quote:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffd4095cacd830, 0xffffee8039c5ac40, 0xffffd40965c8ebd0). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 8d730435-e93f-4b3c-8ffa-bfafe4115fec.
Right before the restart I see:
Event Log:
The local adapter does not support an important Low Energy controller state to support peripheral mode. The minimum required supported state mask is 0x491f7fffff, got 0x1fffffff. Low Energy peripheral role functionality will not be available.
Maybe it went low power, then the device didn't support it so the system crashed? I don't know. :~ EDIT I did find one in the Event Log (Application) that occurred right before the reboot time:
Application Event Log:
SettingSyncHost (11192,G,0) The beta feature EseDiskFlushConsistency is enabled in ESENT due to the beta site mode settings 0x800000.
EDIT Apparently that is a BETA Win 10 1709 feature. :| I found this which mentions this problem does cause CRASHES! EseDiskFlushConsistency - win10 1709[^] X| EDIT 2 I'm wondering if this was the same restart problem
I gotta fix the wife's all-in-one when I get home today...keeps crashing due to a problem with the wireless adapter failing on wake from standby...nice blue screen with a sad face...kinda reminds me of the old mac sad face that I used to see so much of. :laugh: (OS 7.5.x)
"Go forth into the source" - Neal Morse
-
I gotta fix the wife's all-in-one when I get home today...keeps crashing due to a problem with the wireless adapter failing on wake from standby...nice blue screen with a sad face...kinda reminds me of the old mac sad face that I used to see so much of. :laugh: (OS 7.5.x)
"Go forth into the source" - Neal Morse
kmoorevs wrote:
I gotta fix the wife's all-in-one when I get home today
Good luck.
kmoorevs wrote:
old mac sad face that I used to see so much of. :laugh: (OS 7.5.x)
I have a Mac Mini, use it rarely for iOS dev and I know that sad face well. Wonder why. :rolleyes:
-
I was using my laptop then took a break for lunch. Came back and it had restarted. I checked Windows Updates and it said there was one installed successfully on 02/13. Why did my computer suddenly restart? I looked in Event Log (System):
event log:
The previous system shutdown at 12:19:13 PM on 2/17/2018 was unexpected.
Next I find this:
Event log:
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly. (Source is Kernel-Power)
It's a laptop so has battery backup, so probably not a loss of power. Here's another weird one (not sure what bugcheck is):
Quote:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffd4095cacd830, 0xffffee8039c5ac40, 0xffffd40965c8ebd0). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 8d730435-e93f-4b3c-8ffa-bfafe4115fec.
Right before the restart I see:
Event Log:
The local adapter does not support an important Low Energy controller state to support peripheral mode. The minimum required supported state mask is 0x491f7fffff, got 0x1fffffff. Low Energy peripheral role functionality will not be available.
Maybe it went low power, then the device didn't support it so the system crashed? I don't know. :~ EDIT I did find one in the Event Log (Application) that occurred right before the reboot time:
Application Event Log:
SettingSyncHost (11192,G,0) The beta feature EseDiskFlushConsistency is enabled in ESENT due to the beta site mode settings 0x800000.
EDIT Apparently that is a BETA Win 10 1709 feature. :| I found this which mentions this problem does cause CRASHES! EseDiskFlushConsistency - win10 1709[^] X| EDIT 2 I'm wondering if this was the same restart problem
Hi, I *highly* doubt that EseDiskFlushConsistency brought the system down... all this function does is flush database modifications to disk. If you are interested in finding out what brought the system down then download WinDbg and open the minidump. If you setup the symbols... you will get the exact exception and entire callstack... Bugcheck 0x9F is a DRIVER_POWER_STATE_FAILURE meaning that one of the device drivers installed on your laptop improperly handled a power state. Instructions for debugging a device driver power management error is here: How to Debug DRIVER_POWER_STATE_FAILURE[^] Look at your second bugcheck number: 0xffffee8039c5ac40 I think if you open the minidump in WinDbg and do: !devstack 0xffffee8039c5ac40[^] You will find exactly which driver caused the bug check. Always remember that Microsoft Windows allows third-party vendors to write device drivers. Don't be surprised if this is a third-party device driver. Btw, once you learn how to use WinDbg you will probably not ask many questions[^]... because it's faster to just fire up WinDbg and get the answer.
-
Hi, I *highly* doubt that EseDiskFlushConsistency brought the system down... all this function does is flush database modifications to disk. If you are interested in finding out what brought the system down then download WinDbg and open the minidump. If you setup the symbols... you will get the exact exception and entire callstack... Bugcheck 0x9F is a DRIVER_POWER_STATE_FAILURE meaning that one of the device drivers installed on your laptop improperly handled a power state. Instructions for debugging a device driver power management error is here: How to Debug DRIVER_POWER_STATE_FAILURE[^] Look at your second bugcheck number: 0xffffee8039c5ac40 I think if you open the minidump in WinDbg and do: !devstack 0xffffee8039c5ac40[^] You will find exactly which driver caused the bug check. Always remember that Microsoft Windows allows third-party vendors to write device drivers. Don't be surprised if this is a third-party device driver. Btw, once you learn how to use WinDbg you will probably not ask many questions[^]... because it's faster to just fire up WinDbg and get the answer.
I'm feeling quite silly, I have always done this in a hex editor. :-O
Wrong is evil and must be defeated. - Jeff Ello
-
Hi, I *highly* doubt that EseDiskFlushConsistency brought the system down... all this function does is flush database modifications to disk. If you are interested in finding out what brought the system down then download WinDbg and open the minidump. If you setup the symbols... you will get the exact exception and entire callstack... Bugcheck 0x9F is a DRIVER_POWER_STATE_FAILURE meaning that one of the device drivers installed on your laptop improperly handled a power state. Instructions for debugging a device driver power management error is here: How to Debug DRIVER_POWER_STATE_FAILURE[^] Look at your second bugcheck number: 0xffffee8039c5ac40 I think if you open the minidump in WinDbg and do: !devstack 0xffffee8039c5ac40[^] You will find exactly which driver caused the bug check. Always remember that Microsoft Windows allows third-party vendors to write device drivers. Don't be surprised if this is a third-party device driver. Btw, once you learn how to use WinDbg you will probably not ask many questions[^]... because it's faster to just fire up WinDbg and get the answer.
Sheesh. It was meant to be a discussion. Like mechanics getting together and discussing odd things that happen. I downloaded the windbg tool. And here's the thing... I went to the location where I had previously attempted to open the memory.dmp file with Visual Studio's debugger and when I got there I found that the file was gone! My machine has not restarted and I didn't delete the memory.dmp file but now it is gone. Why would Win10 do that? I tried attrib to see if the file was just hidden or something but it wasn't there. I checked Recycle bin to see if the OS deleted it and I don't see it there either. I was very interested in learning the cause of the crash. Oh well. :sigh:
-
Hi, I *highly* doubt that EseDiskFlushConsistency brought the system down... all this function does is flush database modifications to disk. If you are interested in finding out what brought the system down then download WinDbg and open the minidump. If you setup the symbols... you will get the exact exception and entire callstack... Bugcheck 0x9F is a DRIVER_POWER_STATE_FAILURE meaning that one of the device drivers installed on your laptop improperly handled a power state. Instructions for debugging a device driver power management error is here: How to Debug DRIVER_POWER_STATE_FAILURE[^] Look at your second bugcheck number: 0xffffee8039c5ac40 I think if you open the minidump in WinDbg and do: !devstack 0xffffee8039c5ac40[^] You will find exactly which driver caused the bug check. Always remember that Microsoft Windows allows third-party vendors to write device drivers. Don't be surprised if this is a third-party device driver. Btw, once you learn how to use WinDbg you will probably not ask many questions[^]... because it's faster to just fire up WinDbg and get the answer.
I would be very worried that the last thing it did/attempted/was doing was any sort of disk flush, and as OP mentioned above looked for the memory.dmp file that disappeared itself without message/log/warning Boy, that win10 really inspires confidence, not! And yet they still tell people to upgrade to 10 because it's safer than the old [solid] w7 :confused: Have one client using a stock PC running w7 as an app/db server, only been down once in 5 years (2 years ago now) for a scheduled power outage. w10: no thanks; stick with what actually proven works.
Signature ready for installation. Please Reboot now.
-
Sheesh. It was meant to be a discussion. Like mechanics getting together and discussing odd things that happen. I downloaded the windbg tool. And here's the thing... I went to the location where I had previously attempted to open the memory.dmp file with Visual Studio's debugger and when I got there I found that the file was gone! My machine has not restarted and I didn't delete the memory.dmp file but now it is gone. Why would Win10 do that? I tried attrib to see if the file was just hidden or something but it wasn't there. I checked Recycle bin to see if the OS deleted it and I don't see it there either. I was very interested in learning the cause of the crash. Oh well. :sigh:
Well, I've done some more thinking about this. It was most likely a stray cosmic ray... probably a muon that struck one of your sticks of RAM in the state capacitor and flipped a bit. This probably caused notepad (even though it wasn't running) to determine that it needed to flush it's contents to disk. After calling EseDiskFlushConsistency... your hard drives all spun up at the same time... and all of the zero point energy was consumed in your power supply and this resulted in a bugcheck 0x9F - DRIVER_POWER_STATE_FAILURE. This massive consumption of energy opened a miniature black hole and it consumed your minidump... that's why you can't find it. Trust me, that's exactly how it happened. Happens all the time.
-
Sheesh. It was meant to be a discussion. Like mechanics getting together and discussing odd things that happen. I downloaded the windbg tool. And here's the thing... I went to the location where I had previously attempted to open the memory.dmp file with Visual Studio's debugger and when I got there I found that the file was gone! My machine has not restarted and I didn't delete the memory.dmp file but now it is gone. Why would Win10 do that? I tried attrib to see if the file was just hidden or something but it wasn't there. I checked Recycle bin to see if the OS deleted it and I don't see it there either. I was very interested in learning the cause of the crash. Oh well. :sigh:
raddevus wrote:
My machine has not restarted and I didn't delete the memory.dmp file but now it is gone. Why would Win10 do that?
Easy... professional criminals always do it... erase traces, so noone can connect you to the crime ;) :P :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
raddevus wrote:
My machine has not restarted and I didn't delete the memory.dmp file but now it is gone. Why would Win10 do that?
Easy... professional criminals always do it... erase traces, so noone can connect you to the crime ;) :P :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Nelek wrote:
Easy... professional criminals always do it... erase traces, so noone can connect you to the crime
Win10. Microsoft. Pick your criminal. :laugh:
-
Hmmm, Could you execute the following command from powershell as Administrator and paste the output here?
Get-ScheduledTask | ? {$_.Settings.MaintenanceSettings} | Select-String -Pattern "Disk"
Best Wishes, -David Delaune
Sure, thanks... Here's what I saw:
PS C:\WINDOWS\system32> Get-ScheduledTask | ? {$_.Settings.MaintenanceSettings}
| Select-String -Pattern "Disk"MSFT_ScheduledTask (TaskName = "SilentCleanup", TaskPath =
"\Microsoft\Windows\DiskCleanup\")
MSFT_ScheduledTask (TaskName = "Microsoft-Windows-DiskDiagnosticDataCol...,
TaskPath = "\Microsoft\Windows\DiskDiagnostic\")
MSFT_ScheduledTask (TaskName = "Diagnostics", TaskPath =
"\Microsoft\Windows\DiskFootprint\")
MSFT_ScheduledTask (TaskName = "StorageSense", TaskPath =
"\Microsoft\Windows\DiskFootprint\")This is the part where you take over my computer now, right? :-D
-
I gotta fix the wife's all-in-one when I get home today...keeps crashing due to a problem with the wireless adapter failing on wake from standby...nice blue screen with a sad face...kinda reminds me of the old mac sad face that I used to see so much of. :laugh: (OS 7.5.x)
"Go forth into the source" - Neal Morse
If it helps - I recently purchased a non-major brand laptop for development. It ran perfectly until the 1709 update. I did not connect the update with the instability issues that started to occur. Really weird $hit - the touchpad driver causing BSODs, etc. Researching, I think what happened is that Windows decided I needed the latest and freshest drivers for my devices. It appears that this is the continuous stupidity of Microsoft in the OS bullhits. :mad: I downloaded the OEM supplied driver packs, updated with their older (but stable) version and have not had a blue screen in two weeks (I was getting 2-4 a week).
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I would be very worried that the last thing it did/attempted/was doing was any sort of disk flush, and as OP mentioned above looked for the memory.dmp file that disappeared itself without message/log/warning Boy, that win10 really inspires confidence, not! And yet they still tell people to upgrade to 10 because it's safer than the old [solid] w7 :confused: Have one client using a stock PC running w7 as an app/db server, only been down once in 5 years (2 years ago now) for a scheduled power outage. w10: no thanks; stick with what actually proven works.
Signature ready for installation. Please Reboot now.
Win 10 - not in the same league as Windows 7 yet, and it's pretty clear that it's a management problem.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Sure, thanks... Here's what I saw:
PS C:\WINDOWS\system32> Get-ScheduledTask | ? {$_.Settings.MaintenanceSettings}
| Select-String -Pattern "Disk"MSFT_ScheduledTask (TaskName = "SilentCleanup", TaskPath =
"\Microsoft\Windows\DiskCleanup\")
MSFT_ScheduledTask (TaskName = "Microsoft-Windows-DiskDiagnosticDataCol...,
TaskPath = "\Microsoft\Windows\DiskDiagnostic\")
MSFT_ScheduledTask (TaskName = "Diagnostics", TaskPath =
"\Microsoft\Windows\DiskFootprint\")
MSFT_ScheduledTask (TaskName = "StorageSense", TaskPath =
"\Microsoft\Windows\DiskFootprint\")This is the part where you take over my computer now, right? :-D
Hi,
raddevus wrote:
MSFT_ScheduledTask (TaskName = "SilentCleanup", TaskPath = "\Microsoft\Windows\DiskCleanup\")
This scheduled task runs daily and silently and has the ability to delete minidumps.
raddevus wrote:
This is the part where you take over my computer now, right? :-D
Occam's razor[^] Best Wishes, -David Delaune
-
Hi,
raddevus wrote:
MSFT_ScheduledTask (TaskName = "SilentCleanup", TaskPath = "\Microsoft\Windows\DiskCleanup\")
This scheduled task runs daily and silently and has the ability to delete minidumps.
raddevus wrote:
This is the part where you take over my computer now, right? :-D
Occam's razor[^] Best Wishes, -David Delaune
Yeah I figured there was a process that did clean-up automatically. ==> I'm a software developer who writes articles and concentrates on the fun and interesting stuff. Disk clean up after a crash is no fun at all. Seriously boring. I expect the system to do the right thing all the time -- especially in this age of AI / Machine-Learning. :rolleyes: Crash and cleanup is "need to know basis". I don't want to know until I have to know. :laugh: Keep me ignorant and then I can rant about stupid Win10. Far more fun. :rolleyes:
-
Yeah I figured there was a process that did clean-up automatically. ==> I'm a software developer who writes articles and concentrates on the fun and interesting stuff. Disk clean up after a crash is no fun at all. Seriously boring. I expect the system to do the right thing all the time -- especially in this age of AI / Machine-Learning. :rolleyes: Crash and cleanup is "need to know basis". I don't want to know until I have to know. :laugh: Keep me ignorant and then I can rant about stupid Win10. Far more fun. :rolleyes:
Hi,
raddevus wrote:
I expect the system to do the right thing all the time
Yeah, I understand. People have different expectations... 'The right thing' is relative and while you maybe wanted to keep your minidumps... others may want them cleaned up daily so they don't take up any disk space. Best Wishes, -David Delaune
-
Hi,
raddevus wrote:
I expect the system to do the right thing all the time
Yeah, I understand. People have different expectations... 'The right thing' is relative and while you maybe wanted to keep your minidumps... others may want them cleaned up daily so they don't take up any disk space. Best Wishes, -David Delaune
-
I was using my laptop then took a break for lunch. Came back and it had restarted. I checked Windows Updates and it said there was one installed successfully on 02/13. Why did my computer suddenly restart? I looked in Event Log (System):
event log:
The previous system shutdown at 12:19:13 PM on 2/17/2018 was unexpected.
Next I find this:
Event log:
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly. (Source is Kernel-Power)
It's a laptop so has battery backup, so probably not a loss of power. Here's another weird one (not sure what bugcheck is):
Quote:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffd4095cacd830, 0xffffee8039c5ac40, 0xffffd40965c8ebd0). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 8d730435-e93f-4b3c-8ffa-bfafe4115fec.
Right before the restart I see:
Event Log:
The local adapter does not support an important Low Energy controller state to support peripheral mode. The minimum required supported state mask is 0x491f7fffff, got 0x1fffffff. Low Energy peripheral role functionality will not be available.
Maybe it went low power, then the device didn't support it so the system crashed? I don't know. :~ EDIT I did find one in the Event Log (Application) that occurred right before the reboot time:
Application Event Log:
SettingSyncHost (11192,G,0) The beta feature EseDiskFlushConsistency is enabled in ESENT due to the beta site mode settings 0x800000.
EDIT Apparently that is a BETA Win 10 1709 feature. :| I found this which mentions this problem does cause CRASHES! EseDiskFlushConsistency - win10 1709[^] X| EDIT 2 I'm wondering if this was the same restart problem
A reboot just bit me too. I had a dozen+ tabs open in two browsers researching something, 2 instances of VS. I was in the other room eating dinner when I hear the BIOS beep from my computer. Thanks a lot Windows Update KB4074588. That was absolutely not planned or communicated. The process c:\windows\system32\svchost.exe (MYNAMEHERE) has initiated the restart of computer MYNAMEHERE on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Service pack (Planned) Reason Code: 0x80020010 Shutdown Type: restart Comment:
-
If you had gone one more entry in the log, you'd see this: "Windows 10 was detected. The system is inherently unstable."
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Strangely enough, I have been running Windows 10 for a year here at work and on three different machines at home, and haven't experienced a single crash on any of those. About half of the 300 PCs we have at work run W10 (the rest runs W7), and I haven't heard about any instability problems with any of those, in spite of lots of special hardware drivers, updated all the time, and a large number of tools deeply intertwingled with the OS, such as a multitude of debuggers and hardware monitors. But then: These systems are maintained by people who know how to handle Windows systems. They do not try to force the systems to be as Linux lookalikes as possible - that is bound to cause trouble. Just like if you try to manage a Linux box as if it were a Windows machins: Then it turns out that Linux is not quite as stable as rumours seem to suggest... One morning a few weeks ago, a few dozen of our machines at work had restarted at the same time in the middle of the night, while the majority of the machines were unaffected. The restart affected both W10 and W7 machines. We never found a good explanation, and concluded that since it is winter time, with lots of snow breaking down trees that fall over the power lines, the power grid sometimes can't perfectly suppress the spikes caused when switching over to another distribution line, and we experience a small spike in the power outlets. Some PC power supplies handle this well, others are knocked out and cause a restart when stable power is again available. We didn't investigate this further; most of our machines "survived". A couple of nightly builds had to be rerun, but going deeper into it would not be cost effective.