The above sequence of calls is trigged by timer expiration as identified by the presence of KiProcessExpiredTimerList().
Finding that culprit will require some more work beyond just running "!analyze -v" S3 power state.įlags.: 80000004 OverrideApps|CriticalĪlthough the crashing thread stack below shows the sequence of calls that led to the call to KeBugCheckEx(), it fails to identify the component that is responsible for the crash. The output shown below indicates that system is going to sleep i.e.
The kernel debugger command "!poaction" displays information about the power state transition in progress. In the above output the description displayed for Arg1 alludes to the situation that led to the crash. The resultant timer DPC routine that runs at the end of this period crashes the system with the following bug-check code and parameters as displayed by the kernel debugger command "!analyze -v".Ī driver is causing an inconsistent power state.Īrg1: 00000003, A device object has been blocking an Irp for too long a timeĪrg2: 86b3e6e8, Physical Device Object of the stackĪrg3: 82d3fae0, Functional Device Object of the stack For every power IRP that is sent to a driver, the power manager starts a watchdog timer that fires if the IRP is not completed within 10 minutes.
In response to these system power state change requests, drivers power down their devices by requesting device power IRPs (D-IRP) and then sending them down to the underlying bus driver.
transitions from a working state (S0) to a lower power state like standby (S3), hibernate (S4) or shutdown (S5) or vice versa, every driver in the system is notified about the transition via a system power IRP (S-IRP). In Windows Vista and later version of Windows, when the system changes power states i.e.