Windows 10: Tablet BSOD while sleeping

Tablet BSOD while sleeping - Windows 10 Forums

 

Thank you very much for trying to help. The SSD already had the newest firmware. It could still be though, that the SSD still has bugs, Sandisk is a very shitty company actually for SSDs. I installed the driver, because of the first BSOD, before I dont know which was installed, I think the one, which came with the Chipset package, also one from Intel. The first one installed, was the default MS AHCI one I think. I could try to revert back to that maybe? I think the highest chance of the issue though is what I said, related to power state (incompatibilities). The Intel Chipset Device Software on the Dell site is form 2014 though, I had actually doubts if I should install it or not, or just use the default MS noname drivers, but then I wasnt sure if that was the worst decision of the two. I actually hate how bad Intel maintains their drivers, and stops supporting products older than 2 years usually.

 

@BSODHunter Please note the dump_iaStorA.sys is not a problem - this driver is only used to record the crash and not part of normal operation.

 

Yes I know, but in this case hardware_disk could be related to hardware OR driver?! Or not? Normally I dont look at this, but in this case....maybe its worth a try?!

 

I would think it is worth uninstalling the Intel drivers and trying the default MS drivers - I think gorgor has said he intends to try this. Let's see if it helps.

 

I just had to look into the event log myself now... and it is obvious, that the crash happened, like I assumed from the beginning, when Windows tried to switch from sleep to hibernate. The memcompress process actually was already indication for that.

2017-08-04 09:20:07 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
2017-08-04 12:52:29 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
2017-08-04 12:54:09 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
2017-08-05 00:00:59 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
2017-08-05 15:11:15 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
2017-08-05 19:18:15 Warnung: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.

all those events, the system had a few seconds later the log entry:

Das System wird in den Standbymodus versetzt.

Ursache: Vom Standbymodus in den Ruhezustand wechseln

and I guess, the two bsod also happened there. It more looks to me like a Windows bug in combination of power state and driver. Windows wants to switch to hibernate => wants to write to disk from inside sleep, but the SSD is not ready / still in sleep mode.

 

yes Im thinking the same. There a direct connection between the error message and standby/hibernate:

Code: Event[4273]: Log Name: System Source: iaStorA Date: 2017-08-06T03:42:20.725 Event ID: 129 Task: N/A Level: Warnung Opcode: N/A Keyword: Klassisch User: N/A User Name: N/A Computer: mkdr-V11 Description: Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.[/quote] Code: Event[4274]: Log Name: System Source: Microsoft-Windows-Kernel-Power Date: 2017-08-06T03:42:27.927 Event ID: 42 Task: N/A Level: Informationen Opcode: Info Keyword: N/A User: N/A User Name: N/A Computer: mkdr-V11 Description: Das System wird in den Standbymodus versetzt. Ursache: Vom Standbymodus in den Ruhezustand wechseln – vorhergesagte Benutzerabwesenheit[/quote]

 

The question now is, do you see the connection where the bsod happened too? Is there a event for that too at that time index? Or is the "Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben." not related? The bad thing is, I already tried to disable this stupid Windows 10 """feature""" to decide on itself, to switch to hibernate "save energy, when the device notices the user is away" (vorhergesagte Benutzerabwesenheit) or how it is called, but of course, like 90% of the rest of Windows 10, it is buggy, and somehow switches itself always on again. I also dont want to deactivate hibernate completely. Same with the "keep network connected in standby", it is also not working and randomly stays connected sometimes, and then not.

 

no not directly. This is the exact crash timeline, theres no other info between:

Standby at 08:43
Code: Event[4376]: Log Name: System Source: Microsoft-Windows-Kernel-Power Date: 2017-08-06T08:43:20.163 Event ID: 506 Task: N/A Level: Informationen Opcode: Info Keyword: N/A User: S-1-5-18 User Name: NT-AUTORITÄT\SYSTEM Computer: mkdr-V11 Description: Das System wechselt in den verbundenen Standbymodus. Grund: Leerlaufzeitüberschreitung.[/quote]
BSOD at 08:57
Code: 0x00000154: UNEXPECTED_STORE_EXCEPTION (6.08.2017 08:57:43) [Windows 10][/quote]
Reboot at 09:03
Code: Event[4377]: Log Name: System Source: EventLog Date: 2017-08-06T09:03:01.261 Event ID: 6008 Task: N/A Level: Fehler Opcode: N/A Keyword: Klassisch User: N/A User Name: N/A Computer: mkdr-V11 Description: Das System wurde zuvor am ?06.?08.?2017 um 08:47:16 unerwartet heruntergefahren.[/quote]

 

You can also get the time of the crash from the memory dump:

TARGET_TIME: 2017-08-06T06:57:43.000Z

There is 2hr offset but this fits in between event id 4376 and 4377

Also:
Debug session time: Sun Aug 6 07:57:43.092 2017 (UTC + 1:00)

 

I assume Windows wanted to switch to hibernate at 08:57 where the BSOD happened, and didnt log that anymore. Thats just how it looks to me. What else is memcompress? Is it always present or just (mostly) used before hibernate I guess to compress ram and then save it to disk?

 

The problem is we do not know exactly what happened between 08:43 when event 4376 reported that "The system switches to the connected standby mode" and the crash debug at 08:57.

What is your power plan? How long do you have between system going into standby and hibernate etc? Can you provide a power efficiency diagnostic report:

Run the following command in an elevated command prompt:
powercfg -energy -output %USERPROFILE%\Desktop\Power_Efficiency_Diagnostics_Report.html

 

Windows 10 decides on itself, when the "right time is" to switch into hibernate. Isnt that cool? The stupid Windows 10 setting just says "save energy when the device notices the user is away" and doesnt give ANY information actually what this means. I had to google about it and found just in a reddit post, that this actually is a "cool new feature" of Windows 10 (creators update), that Windows 10 does a statistic and then somehow decides the user is away, and goes hibernate. Can be 5 minutes, 10, 20, 1 h, 5h... connected to I guess how much you use the tablet and how much you turn it on/off in the last... whatever hours/days.

I actually wasnt happy with the drain in sleep so far with the tablet, and notices some problems reported by powercfg before. One for example is this:

Funktionen der PlattformenergieverwaltungCI Express-ASPM (Active-State Power Management) deaktiviertPCI Express-ASPM (Active-State Power Management) wurde aufgrund einer bekannten Inkompatibilität mit der Computerhardware deaktiviert.

I had already googled about this before, and it seems "some device" of course it doesnt say what, is "listed" as a "known incompatibility" and prevents PCIE ASPM. It seems to be a wild problem with tablets and Windows 10, even Surface tablets have it, found a reddit post about it.

The other error is:
Energierichtlinie*Biggrinatenträgerleerlauf ist deaktiviert (Netzbetrieb)Der Datenträger ist nicht so konfiguriert, dass er nach einer Zeit der Inaktivität ausgeschaltet wird.

But thats not related or important I guess.

I use balance of course (there is just balance and you cant change anything in there, on devices with connected standby).

 

https://i.imgur.com/GLDCPOX.png

This is the current drain pattern. Which is actually really bad, whatever reason for, of about 1%-1.5% per hour in connected standby (airplane mode active). Normal drain should be actually about 0.33% per hour for a modern standby device. When I turn off the AHCI link power management in the Intel Rapid Store tool, like suggested in other posts I found about sleep bsod, then the tablet drain is horrible in sleep and shows a 0% for HW.

 

I did some more digging in the Memory dump particularly looking at the power management.

First I used a command (!pnptriage) to look for any devnodes causing problems and to dump any threads involved:

Code: 2: kd> !pnptriage ******************************************************************************** Dumping PnP DeviceAction Queue @ 0xfffff800867e0a20 ******************************************************************************** Dumped 0 entries PnP DeviceActionWorker active! ******************************************************************************** Dumping PnP DeviceEvent Queue @ 0xffff8a8951ecad70 ******************************************************************************** List = 0xffff8a8951ecade8, 0xffff8a8951ecade8 Event list is empty ******************************************************************************** Dumping PnP DeviceCompletion Queue @ 0xfffff800867e1dc0 ******************************************************************************** 1 Pnp operation(s) dispatched (IRP pending) currently. Dumping pending asynchronous request list... Dumping pended asynchronous request... !devnode ffff8a895391d010 CompletionState = DeviceNodeEnumerateCompletion (0x30d) Pending !irp ffff8a8952ada960 Dumping completed asynchronous request list... ******************************************************************************** Dumping devnodes with problems... ******************************************************************************** Dumping IopRootDeviceNode (= 0xffff8a8951ec8d30) ******************************************************************************** Dumping PnP locks... ******************************************************************************** Resource @ nt!PiEngineLock (0xfffff800867e1f60) Exclusively owned Contention Count = 59 Threads: ffff8a895336d280-01<*> 1 total locks Resource @ nt!IopDeviceTreeLock (0xfffff800867e1e60) Shared 1 owning threads Contention Count = 5 Threads: ffff8a895336d280-01<*> 1 total locks Resource @ nt!PnpRegistryDeviceResource (0xfffff800867e2080) Available Contention Count = 2200 1 total locks ******************************************************************************** If one or more of above are NOT available, do !thread on the owner thread to find the thread hung in PnP ******************************************************************************** ******************************************************************************** Dumping currently active PnP thread (if any)... ******************************************************************************** Dumping device action thread... THREAD ffff8a895336d280 Cid 0004.0884 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable ffffd8016fcfc1e0 SynchronizationEvent Not impersonating DeviceMap ffffa10ca2417bb0 Owning Process ffff8a8951e87040 Image: System Attached Process N/A Image: N/A Wait Start TickCount 6920053 Ticks: 0 Context Switch Count 883 IdealProcessor: 2 UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address nt!ExpWorkerThread (0xfffff800864babd0) Stack Init ffffd8016fcfcc90 Current ffffd8016fcfbe10 Base ffffd8016fcfd000 Limit ffffd8016fcf7000 Call 0000000000000000 Priority 12 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site ffffd801`6fcfbe50 fffff800`864b0a9a : ffff8a89`5336d280 00000000`00000677 ffffd801`63580180 fffff800`865ecd2a : nt!KiSwapContext+0x76 ffffd801`6fcfbf90 fffff800`864b0461 : ffff8a89`5336d280 ffff8a89`5336d3c0 00000000`00000000 00000000`00000000 : nt!KiSwapThread+0x16a ffffd801`6fcfc040 fffff800`864afd78 : ffff8a89`52f76010 ffffd801`00000000 ffff8a89`52f76000 ffffd801`6fcfc1e0 : nt!KiCommitThreadWait+0x101 ffffd801`6fcfc0e0 fffff804`aa17dfe1 : ffffd801`6fcfc1e0 ffff8a89`00000000 fffff804`aa167100 ffff8a89`52f5ec00 : nt!KeWaitForSingleObject+0x2b8 ffffd801`6fcfc1b0 fffff804`aa0f7e6f : ffff8a89`52f76010 fffff804`aa103400 ffff8a89`52f88a20 00000000`00000300 : ACPI!ACPIBuildFlushQueue+0x6d ffffd801`6fcfc210 fffff804`aa17368d : ffff8a89`530b6240 ffff8a89`562f2180 00000000`00000000 ffff8a89`52f76010 : ACPI!ACPIDetectFilterDevices+0x73 ffffd801`6fcfc2c0 fffff804`aa0f12b9 : ffff8a89`52f76010 ffff8a89`562f2180 ffff8a89`52adaac0 fffff804`ab9158ce : ACPI!ACPIFilterIrpQueryDeviceRelations+0x20d ffffd801`6fcfc370 fffff800`8666fac7 : 00000000`00000007 ffff8a89`5390f1a0 00000000`00000001 ffff8a89`530b6240 : ACPI!ACPIDispatchIrp+0x219 ffffd801`6fcfc3f0 fffff800`8661279d : ffff8a89`5390f1a0 ffffd801`6fcfc4e0 00000000`00000000 00000000`00000000 : nt!IopPerfCallDriver+0xb3 ffffd801`6fcfc420 fffff804`ab9215f7 : 00000000`00000018 ffffd801`6fcfc498 ffff8a89`5390f1a0 00000000`000edde1 : nt!IofCallDriver+0x134f8d ffffd801`6fcfc460 fffff804`ab9212ea : 00000000`00000010 ffff8a89`51e42500 ffff8a89`52ada960 00000000`00000100 : storport!RaidAdapterQueryDeviceRelationsIrp+0x143 ffffd801`6fcfc520 fffff804`ab914e0e : 00000000`00000002 fffff800`864ddb42 ffff8a89`52ada960 fffff804`ab965000 : storport!RaidAdapterPnpIrp+0x1a2 ffffd801`6fcfc5c0 fffff800`8666fac7 : ffff8a89`52ada960 00000000`00000001 ffff8a89`5390f050 ffff8a89`530ce060 : storport!RaDriverPnpIrp+0x8e ffffd801`6fcfc600 fffff800`8661279d : ffff8a89`52ada960 ffffd801`6fcfc750 ffff8a89`5390f050 ffff8a89`5390f004 : nt!IopPerfCallDriver+0xb3 ffffd801`6fcfc630 fffff800`868ec912 : ffff8a89`530ce060 ffff8a89`58ef71e0 ffffd801`63480c00 fffff800`866fc65c : nt!IofCallDriver+0x134f8d ffffd801`6fcfc670 fffff800`864a243c : ffff8a89`530ce060 00000000`00000000 ffff8a89`58ef71e0 00000000`000007ff : nt!PnpAsynchronousCall+0xea ffffd801`6fcfc6b0 fffff800`86965e3d : ffffa10c`af1f77c0 00000000`00000000 ffff8a89`530ce060 fffff800`865f4413 : nt!PnpSendIrp+0x54 ffffd801`6fcfc720 fffff800`86965b74 : ffff8a89`58ef71e0 ffff8a89`5391d038 ffff8a89`5391d010 00000000`00000000 : nt!PnpQueryDeviceRelations+0x51 ffffd801`6fcfc7b0 fffff800`868b37cd : ffff8a89`5391d010 ffffd801`6fcfc8e0 00000000`00000002 00000000`00000000 : nt!PipEnumerateDevice+0xc8 ffffd801`6fcfc7e0 fffff800`8696444f : ffff8a89`56e91a00 fffff800`864e0059 fffff800`86875200 00000000`00000000 : nt!PipProcessDevNodeTree+0x2b1 ffffd801`6fcfca60 fffff800`8654f8f3 : ffff8a01`00000003 00000000`00000000 ffff8a89`56e91a00 ffff8a89`56e91a00 : nt!PiProcessReenumeration+0xab ffffd801`6fcfcab0 fffff800`864baca8 : ffff8a89`5336d280 fffff800`867e0a00 fffff800`86875380 fffff800`868bd620 : nt!PnpDeviceActionWorker+0x1b3 ffffd801`6fcfcb80 fffff800`86559ac7 : 00000000`00000000 00000000`00000080 ffff8a89`51e87040 ffff8a89`5336d280 : nt!ExpWorkerThread+0xd8 ffffd801`6fcfcc10 fffff800`865ee9d6 : fffff800`855b8180 ffff8a89`5336d280 fffff800`86559a80 00000009`00000000 : nt!PspSystemThreadStartup+0x47 ffffd801`6fcfcc60 00000000`00000000 : ffffd801`6fcfd000 ffffd801`6fcf7000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16[/quote]
Looking at the problem devnode:

Code: 2: kd> !devnode ffff8a895391d010 DevNode 0xffff8a895391d010 for PDO 0xffff8a89530ce060 Parent 0xffff8a8953092ac0 Sibling 0xffff8a895391dd30 Child 0xffff8a8951e6d3e0 InstancePath is "PCI\VEN_8086&DEV_9C83&SUBSYS_066B1028&REV_03\3&11583659&0&FA" ServiceName is "iaStorA" State = DeviceNodeEnumeratePending (0x30c) Previous State = DeviceNodeStarted (0x308) StateHistory[00] = DeviceNodeStarted (0x308) StateHistory[19] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[18] = DeviceNodeEnumeratePending (0x30c) StateHistory[17] = DeviceNodeStarted (0x308) StateHistory[16] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[15] = DeviceNodeEnumeratePending (0x30c) StateHistory[14] = DeviceNodeStarted (0x308) StateHistory[13] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[12] = DeviceNodeEnumeratePending (0x30c) StateHistory[11] = DeviceNodeStarted (0x308) StateHistory[10] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[09] = DeviceNodeEnumeratePending (0x30c) StateHistory[08] = DeviceNodeStarted (0x308) StateHistory[07] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[06] = DeviceNodeEnumeratePending (0x30c) StateHistory[05] = DeviceNodeStarted (0x308) StateHistory[04] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[03] = DeviceNodeEnumeratePending (0x30c) StateHistory[02] = DeviceNodeStarted (0x308) StateHistory[01] = DeviceNodeEnumerateCompletion (0x30d) Flags (0x6c0000f0) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED, DNF_NO_LOWER_DEVICE_FILTERS, DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS, DNF_NO_UPPER_CLASS_FILTERS UserFlags (0x00000008) DNUF_NOT_DISABLEABLE DisableableDepends = 2 (including self)[/quote]
and the irp:

Code: 2: kd> !irp ffff8a8952ada960 Irp is active with 4 stacks 3 is current (= 0xffff8a8952adaac0) No Mdl: No System Buffer: Thread ffff8a895336d280: Irp stack trace. cmd flg cl Device File Completion-Context [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)] 0 0 ffff8a89530ce060 00000000 fffff804aa0f1820-ffffd8016fcfc180 \Driver\pci ACPI!ACPIRootIrpCompleteRoutine Args: 00000000 00000000 00000000 00000000 [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)] 0 0 ffff8a89530b6640 00000000 fffff804aa0f1820-ffffd8016fcfc320 \Driver\ACPI ACPI!ACPIRootIrpCompleteRoutine Args: 00000000 00000000 00000000 00000000 >[IRP_MJ_PNP(1b), IRP_MN_QUERY_DEVICE_RELATIONS(7)] 0 0 ffff8a89530b6240 00000000 00000000-00000000 \Driver\ACPI Args: 00000000 00000000 00000000 00000000 [IRP_MJ_PNP(1b), IRP_MN_QUERY_DEVICE_RELATIONS(7)] 0 e0 ffff8a895390f050 00000000 fffff800865502e0-ffff8a8958ef71e0 Success Error Cancel \Driver\iaStorA nt!PnpDeviceCompletionRoutine Args: 00000000 00000000 00000000 00000000[/quote]
iaStorA.sys is the Intel RST (Rapid Storage Technology) driver.

I would be keen to see if the problem is there with other (newer or older) versions of the driver if you can find any to try.