Tablet BSOD while sleeping

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.

BSOD at 08:57

Code:

0x00000154:    UNEXPECTED_STORE_EXCEPTION (6.08.2017 08:57:43) [Windows 10]

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.

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

philc43 said:

What is your power plan? How long do you have between system going into standby and hibernate etc?

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 Plattformenergieverwaltung:PCI 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:
Energierichtlinieatenträ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

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)

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

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.

There is no newer version, typically Intel. They dont care much about driver updates. There is just the Default AHCI MS driver. The above finding is just a result of the SSD hanging so Windows identifies it as the installed AHCI Intel driver, no? It would mostly state any driver which would be in its place, doesnt mean the driver is faulty. So I should maybe just switch back to the default MS driver I guess, and remove the Intel AHCI driver. Wonder if that would make things worse or give other bad results (maybe performance wise).

gorgor said:

There is no newer version, typically Intel. They dont care much about driver updates. There is just the Default AHCI MS driver. The above finding is just a result of the SSD hanging so Windows identifies it as the installed AHCI Intel driver, no? It would mostly state any driver which would be in its place, doesnt mean the driver is faulty.

Yes but in practice this usually points to the driver being the problem. I would try another driver and see if it helps.