A trace wouldn't be particularly helpful here unfortunately because your crashes are too inconsistent. It would be worthwhile if it was consistently crashing when you tried to resume from sleep/hibernation. Most bugchecks don't have a straightforward answer unless a driver has a very blatant bug with it. If you wanted to do a trace then you could use xbootmgr from the WPA (Windows Performance Toolkit) but I'm not sure what the configuration settings are for it.
Especially the call to nt!NtSetSystemPowerState+0x4c is a call to *shutdown* the system while it should be resuming. So is this stack trace about entering the BSOD? Am I wrong?
Hmm sort of, the call stack will always lead to the bugcheck, you read it from the bottom up, with the
nt!KeBugCheckEx being the last call.
Rich (BB code):
6: kd> knL
# Child-SP RetAddr Call Site
00 fffff989`99c1f898 fffff800`73da663a nt!KeBugCheckEx << BSOD is issued to the operating system
01 fffff989`99c1f8a0 fffff800`73a0dd25 nt!PopStateTransitionTimeoutDispatch+0xea << Throws a timeout exception
02 fffff989`99c1f940 fffff800`73ab6d67 nt!ExpWorkerThread+0x155
03 fffff989`99c1fb30 fffff800`73c36794 nt!PspSystemThreadStartup+0x57
04 fffff989`99c1fb80 00000000`00000000 nt!KiStartSystemThread+0x34
It would seem to be that way if you look at the
documentation for that function you mentioned, however, looking at the code from
ReactOS it seems that it takes a power action object and then decides the power transition based on that. Additionally, much of the dump file appears to be contrary to a possible shutdown as well.
It looks like the third parameter is actually an enumeration too which describes the checkpoint:
Rich (BB code):
6: kd> dt _POP_SLEEP_CHECKPOINT
nt!_POP_SLEEP_CHECKPOINT
PopSleepCheckpointInvalid = 0n0
PopSleepCheckpointPowerTransitionStart = 0n1
PopSleepCheckpointSuspendAppsBefore = 0n2
PopSleepCheckpointSuspendAppsAfter = 0n3
PopSleepCheckpointSuspendServicesBefore = 0n4
PopSleepCheckpointSuspendServicesAfter = 0n5
PopSleepCheckpointNotifySuperfetchBefore = 0n6
PopSleepCheckpointNotifySuperfetchAfter = 0n7
PopSleepCheckpointNotifyCallbacksBefore = 0n8
PopSleepCheckpointNotifyCallbacksAfter = 0n9
PopSleepCheckpointSleepTransactionCommitted = 0n10
PopSleepCheckpointQueryDriversBefore = 0n11
PopSleepCheckpointQueryDriversAfter = 0n12
PopSleepCheckpointAllocatingHiberContext = 0n13
PopSleepCheckpointSuspendDriversBefore = 0n14
PopSleepCheckpointPreSleepNotification = 0n16
PopSleepCheckpointInterruptsDisabledBegin = 0n17
PopSleepCheckpointInvokeHandlerBefore = 0n18
PopSleepCheckpointSaveHiberContextBegin = 0n19
PopSleepCheckpointInitializeDumpStackFailed = 0n20
PopSleepCheckpointHiberWriteFailed = 0n21
PopSleepCheckpointHiberFileTooSmall = 0n22
PopSleepCheckpointSaveHiberContextFailed = 0n23
PopSleepCheckpointSaveHiberContextEnd = 0n24
PopSleepCheckpointHiberKernelHandoff = 0n25
PopSleepCheckpointInvokeHandlerAfter = 0n26
PopSleepCheckpointReadHiberfileBefore = 0n27
PopSleepCheckpointInitializeDumpStackForReadFailed = 0n28
PopSleepCheckpointHiberReadFailed = 0n29
PopSleepCheckpointChecksumFailure = 0n30
PopSleepCheckpointDecompressionFailed = 0n31
PopSleepCheckpointReadHiberfileAfter = 0n32
PopSleepCheckpointInterruptsDisabledEnd = 0n33
PopSleepCheckpointWakeDriversAfter = 0n36
PopSleepCheckpointResumeAppsBefore = 0n37
PopSleepCheckpointResumeAppsAfter = 0n38
[...]
None of these values are properly documented by Microsoft so it would be difficult to say what exactly it means but presumbly, it suggests that any application threads should be resumed after this checkpoint is reached.
If you look at the power action structure too, then it seems we are certainly waking from hibernation, which does fit with the situation you've described of having a BSOD when resuming from hiberation.
Rich (BB code):
6: kd> dt _POP_POWER_ACTION fffff8007443c9a0
nt!_POP_POWER_ACTION
+0x000 Updates : 0 ''
+0x001 State : 0x3 ''
+0x002 Shutdown : 0 '' << FALSE
+0x004 Action : 2 ( PowerActionSleep )
+0x008 LightestState : 5 ( PowerSystemHibernate )
+0x00c Flags : 0x80000004
+0x010 Status : 0n0
+0x014 DeviceType : 7 ( PolicySystemIdle )
+0x018 DeviceTypeFlags : 0
+0x01c IrpMinor : 0x2 ''
+0x01d Waking : 0x1 ''
+0x020 SystemState : 5 ( PowerSystemHibernate )
+0x024 NextSystemState : 1 ( PowerSystemWorking )
+0x028 EffectiveSystemState : 5 ( PowerSystemHibernate )
+0x02c CurrentSystemState : 5 ( PowerSystemHibernate )
+0x030 ShutdownBugCode : (null)
+0x038 DevState : (null)
+0x040 HiberContext : 0xffffcc04`1e7fdd70 _POP_HIBER_CONTEXT
+0x048 WakeTime : 0x0000002d`abc17024
+0x050 SleepTime : 0x00000025`3a244439
+0x058 WakeFirstUnattendedTime : 0
+0x060 WakeAlarmSignaled : 3 ( PoConditionMaximum )
+0x068 WakeAlarm : [3] <unnamed-tag>
+0x0b0 WakeAlarmPaused : 0x1 ''
+0x0b8 WakeAlarmLastTime : 0
+0x0c0 DozeDeferralStartTime : 0
+0x0c8 FilteredCapabilities : SYSTEM_POWER_CAPABILITIES
+0x118 WatchdogLock : 0
+0x120 WatchdogDpc : _KDPC
+0x160 WatchdogTimer : _KTIMER
+0x1a0 WatchdogInitialized : 0x1 ''
+0x1a4 WatchdogState : 2 ( PopPowerActionWatchdogStateResuming )
+0x1a8 WatchdogStartTime : 0x00000025`3a4475c6
+0x1b0 WatchdogTimeout : 0x12c
+0x1b8 ActionWorkerThread : 0xffffcc04`5cee0040 _KTHREAD
+0x1c0 PromoteActionWorkerThread : (null)
+0x1c8 UnlockAfterSleepWorkerThread : (null)
It might be worth not using the docking station with the mouse and keyboard and see if the issue persists. Unfortunately, these types of bugchecks can be a matter of trial and error but usually
!devpowerstate complete can be useful in examing which power states individual devices were in at the time of the crash.